Module talk:Sidebar/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Sidebar start/end/heading

We might look at template:sidebar start/template:sidebar end/template:sidebar heading with an eye to either making them semi-compatible with this, or replacing the few instances where they are used with uses of this template. (And deleting those templates). Zodon (talk) 08:26, 11 November 2008 (UTC)

• I think I'd vote for replacing then deleting/orphaning them. Shall I go ahead and try? Sardanaphalus (talk) 13:10, 12 November 2008 (UTC)

Use of icons in this template

There's some talk about the appropriate use of icons in sidebars such as this one, here. SharkD (talk) 20:19, 17 March 2009 (UTC)

TABLE vs DIV

Is there a particular need for the TABLE element in this template, or can it safely be replaced with nested DIV elements? SharkD (talk) 01:54, 18 March 2009 (UTC)

Merge

Here's another template that could be merged with this one: {{Country history}}. SharkD (talk) 02:04, 18 March 2009 (UTC)

Don't see why it would need merging - could just use sidebar as a meta-template for it (instead of infobox). Zodon (talk) 07:11, 18 March 2009 (UTC)

Because they're both meta-templates. There's no reason to have two layers of indirection here. Chris Cunningham (not at work) - talk 13:09, 18 March 2009 (UTC)

Well, why not simply switch it to use this template? I don't see any need for a merge, either. 「ダイノガイ千？！」^{(Dinoguy1000)} 19:00, 18 March 2009 (UTC)

What's the difference between that and merging? SharkD (talk) 19:20, 18 March 2009 (UTC)

There's a big difference: merging implies that you intend to redirect that template here, which isn't appropriate considering its relatively specialized nature. You might have misunderstood me (reading my comment, it's not so clear); I meant to ask why it couldn't simply be switched from calling {{infobox}} to calling {{sidebar}}. 「ダイノガイ千？！」^{(Dinoguy1000)} 22:05, 18 March 2009 (UTC)

Well, that's what I meant. Maybe 'merging' is specifically not the proper term, but then it's hard to imagine doing something different with something as complex as a template. SharkD (talk) 23:08, 18 March 2009 (UTC)

Okay, good to see we're actually on the same page. =) Even for templates, merging means exactly that - merging any useful content or functionality and then redirecting. {{Country history}} would be described as a template wrapper, I think, and the act of switching the metatemplate it uses definitely wouldn't be called merging. 「ダイノガイ千？！」^{(Dinoguy1000)} 19:41, 19 March 2009 (UTC)

I'm trying to strip all scaling/positional formatting from the existing template so that I can sort of "start from scratch". Here is what I have so far; however, I can't seem to remove the last bit of padding surrounding the list items. I was wondering if anyone could take a look and see what's keeping it from happening. SharkD (talk) 00:27, 27 March 2009 (UTC)

Images in sidebars

There's a discussion going on here regarding whether item-specific images, such as photographs or screenshots, or icons should appear in sidebars. SharkD (talk) 02:40, 29 March 2009 (UTC)

difference from {{infobox}}?

I'm having a hard time seeing why we have both a sidebar and an infobox template. they seem to do almost exactly the same thing. can someone explain? otherwise, it might be time to merge the two (if that can be done without excessive headaches...) --Ludwigs2 21:03, 2 May 2009 (UTC)

They're meant to serve different purposes - infobox templates are primarily key-value for comparative purposes, while sidebars are meant to be list-o-links style things. There's never really been a consensus on exactly how we should treat them, and there are several different designs out there - I'm guilty of starting {{navbox vertical}} for this reason recently. Chris Cunningham (not at work) - talk 11:46, 3 May 2009 (UTC)

ah, ok. is there any centralized discussion about this anywhere. if not, maybe we should pick a place and start one. =}

incidentally, I wrote a template (for a different infobox I was working on) that might be useful here as well: {{do list}} - it creates a text list from the parameters (with a option for changing the delimiter) but controls linebreaks so they don't occur in the middle of phrases. --Ludwigs2 13:08, 3 May 2009 (UTC)

Was at Wikipedia:Series templates. Historical - needs to be revived and coordinate with Wikipedia:Template standardisation. -- Quiddity (talk) 22:07, 3 May 2009 (UTC)

I hate to break it to you, but you're not the first person to try this. See Wikipedia:Templates for deletion/Log/2009 March 29#Template:Vertbox. SharkD (talk) 07:10, 29 June 2009 (UTC)

Wasn't it me who pointed {{sidebar}} out to you when you first wrote that template? Chris Cunningham (not at work) - talk 22:57, 29 June 2009 (UTC)

I can't remember. An admin would have to take a look at the deleted page in order to see. SharkD (talk) 10:29, 3 July 2009 (UTC)

Text making template bigger

{{Sidebar with collapsible lists}} seems to grow and shrink sideways depending on the text contained within. Anyone know how to fix this? Example: {{VG Role-playing}}. SharkD (talk) 07:05, 29 June 2009 (UTC)

Always at top

I've been toying with the idea of suggesting that sidebars always appear at the top of articles. However, I'm hesitant because sidebars don't all share the same styling, and few sidebars use the collapsed version of the template, meaning they're simply too big. SharkD (talk) 11:04, 5 July 2009 (UTC)

They don't always apply to whole articles, though. Chris Cunningham (not at work) - talk 11:06, 6 July 2009 (UTC)

Not to mention the technical difficulties of forcing them to always appear at the top. And what about where an infobox and a sidebar is used on the same article; which one should win out? This type of stuff needs to be decided case-by-case, and if a sidebar needs to appear at the top of an article, it's far easier and simpler to just put its template call at the top of the article's source than to try and force a technical solution from within the template. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:59, 6 July 2009 (UTC)

That's what I meant: place the template at the top of the page source. Also, I'd think that the infobox would come first since it is more important/relevant. Images, however, I think should come after since should always apply to a specific section (I think it's sloppy when this isn't the case). SharkD (talk) 06:44, 7 July 2009 (UTC)

That's not what the Manual of Style says (point 1). Chris Cunningham (not at work) - talk 08:21, 8 July 2009 (UTC)

No kidding. Hence the proposal. SharkD (talk) 08:26, 8 July 2009 (UTC)

The small v-d-e links at the bottom

The small v and d links at the bottom of this template don't seem to work when the template appears in an article. I think it's because they try to link to Template:ArticleName rather than Template:TemplateName. I noticed this while browsing the articles on Watergate, i.e. that use the "Watergate" template. 212.84.108.77 (talk) 17:02, 3 October 2009 (UTC)

Long links?

I decided to be bold and change the documentation here to refer to {{normalwraplink}} rather than {{longlink}}, since the latter doesn't actually work. Since that page may not be as heavily watched, I'm dropping notice here in case anyone wants to discuss it. Anomie⚔ 12:54, 13 November 2009 (UTC)

Is the nowrap default behavior even necessary? Could you cite some examples where deprecating it would cause problems? SharkD  Talk  00:58, 20 November 2009 (UTC)

If it is necessary, I'd prefer a means of turning it off on a per-template basis, instead of having to adjust each individual link. SharkD  Talk  01:00, 20 November 2009 (UTC)

I have no idea. Anomie⚔ 02:55, 20 November 2009 (UTC)

Just as a pointer, {{Navbox}} has used the "nowraplinks" class for a long time now. Other than that, I have no opinion on whether it's really necessary here. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 04:15, 20 November 2009 (UTC)

I went ahead and modified the template so that the behavior can be disabled if needed. It is still enabled by default. SharkD  Talk  05:30, 20 November 2009 (UTC)

The dots between the "v", "d" and "e" links in bottom rh corner

These dots are tiny and can look like dead pixels. Can they be made larger, please? 213.246.94.47 (talk) 23:34, 4 April 2011 (UTC)

Problem with width

Something recently caused Template:Violence against women to broaden, and it wasn't edits to the template itself. It uses this sidebar template, but reverting a recent edit to this made no difference. Can anyone think what might have caused it? SlimVirgin ^{TALK|CONTRIBS} 04:06, 7 September 2011 (UTC)

The culprit appears to be the inclusion of "width:22em". I added "width:auto" to the Template:Violence against women, which overrides this statement. Frietjes (talk) 15:30, 7 September 2011 (UTC)

Thanks for doing that, Frietjes. SlimVirgin ^{TALK|CONTRIBS} 21:59, 7 September 2011 (UTC)

Question on "sidebar with collapsible lists" template

I've posed a question at Template talk:Sidebar with collapsible lists regarding appearance of that template. Any help would be appreciated. --Noleander (talk) 17:08, 22 September 2011 (UTC)

Naming RfC

moved to Wikipedia talk:WikiProject Templates#RfC re template naming

navbaroptions and tnavbaroptions

do these parameters work at all? I checked {{navbar}} and it doesn't have a {{{2}}} parameter. I had to add navbarfontstyle to get the font colouring to work in Template:Azerbaijanis. if this parameter doesn't work at all, we should just remove it. Frietjes (talk) 16:21, 6 March 2012 (UTC)

They do work but you have to pass named parameters in with {{=}} and separated with {{!}}. I also felt such was rather dubious and hard to make work. Instead of chasing {{navbar}} and exporting all its parameters into {{sidebar}} and friends, for flexibility I would rather see an option that just lets one totally override the navbar so people can call it directly (or make their own). 50.53.15.51 (talk) 11:37, 4 April 2012 (UTC)

it's better to have the parameter names for the options here, rather than in every single call to this template. that way if there are changes to {{navbar}}, we can fix them here, rather than having to track them down in every single call to this template. Frietjes (talk) 16:08, 4 April 2012 (UTC)

Recent changes

Recent changes have disturbed the widths of templates {{Hinduism}} (width became smaller) and {{Vaishnavism}} (width increased suddenly). I am unsure about the exact problem or which edits caused it. --Redtigerxyz ^Talk 17:26, 11 March 2012 (UTC)

I think Frietjes fixed it. — Edokter (talk) — 17:33, 11 March 2012 (UTC)

The problem still exists. I observed when loading Hinduism, template Hinduism appears 100 % width and on completion of loading, it suddenly becomes small width. What has changed? Should I add any parameters to the Hinduism et al templates? --Redtigerxyz ^Talk 17:37, 11 March 2012 (UTC)

The second edit solved the problem. Thanks Frietjes. --Redtigerxyz ^Talk 17:39, 11 March 2012 (UTC)

yes, I almost had it in the first edit, but missed an extra }. looks like it works now. I also improved the logic for the new float option (now works if float exists but is blank). Frietjes (talk) 17:41, 11 March 2012 (UTC)

multiple images?

is it impossible to get multiple images in a sidebar? -- 99.7.156.121 (talk) 06:00, 8 April 2012 (UTC)

yes, just add them both to the |image= field. Frietjes (talk) 16:46, 15 April 2012 (UTC)

Floating left broken? And, how to line up horizontally?

I'm trying

1. to get 4 helpboxes (sidebars) to line up in a horizontal row.
2. to understand what I'm doing wrong!

See This sandbox edit. I do eventually want all 4 to line up, but even that (diff) simple experiment isn't working! (I assumed it would create 3 in a row, and 1 underneath. But it persists in making a right-floating column of all 4.). What obvious thing am I missing? Ta :) -- Quiddity (talk) 07:13, 13 August 2012 (UTC)

Examination of the HTML source for that sandbox shows that the four boxes are tables; and each one has the CSS styling float: right; Examination of the wikicode for the templates {{MiniAWFP}} {{Infoboxwatch}} {{Dabnav}} {{Glossaries}} shows that none of them recognise a |float= parameter. That is, an examination of the template code does not reveal any instances of {{{float --Redrose64 (talk) 14:07, 13 August 2012 (UTC)

But, they're all using {{Helpbox}}, which is directly built with {{Sidebar}}, which includes floats!

[Stab poke prod test]. Ah! Ok, so I still have to explicitly add the "|float={{{float|right}}}" line into each of the templates. (It's been a while, but is slowly coming back to me now... the pain!) Thanks.

I solved the other part, too. I had tried embedding them all in columns of a table, but this failed. Strangely, if linebreaks are added, it works. A mystery for another day (or more coffee). -- Quiddity (talk) 23:18, 13 August 2012 (UTC)

Edit request on 29 August 2012

please change "{{content33style" to "{{{content33style" (note the three braces instead of two). Once this is changed Special:WhatLinksHere/Template:Content33style should drop to zero.

Frietjes (talk) 15:15, 29 August 2012 (UTC)

 Fixed. — Edokter (talk) — 16:57, 29 August 2012 (UTC)

Obsolete markup

• cellspacing
• cellpadding

---— Gadget850 (Ed) ^talk 23:20, 23 September 2012 (UTC)

There are many templates with these; {{navbox}} and {{infobox}} to name a few complicated examples. They need some CSS restructuring, including Common.css. Currently looking into it. — Edokter (talk) — 17:45, 24 September 2012 (UTC)

This template sure uses some convulted parameter structure for these attributes, while overriding those same settings with CSS. So I recommend removing those parameters to start with. — Edokter (talk) — 19:36, 8 October 2012 (UTC)

Edit request on 4 December 2012

Hi. I've noticed that if backgrounds are added to the headings in this template, the headings don't appear vertically aligned within them (see example below left). If, however, the padding in the heading styles is changed to padding:0.1em;, i.e. an all-round 0.1em padding, the headings now appear vertically aligned (below middle). A tweak to the content styles (bottom padding of 0.4em) ensures each heading-content pair remains grouped when no heading background is in use (below right). So, I've amended a copy of the current template code in the sandbox to include these tweaks (15:46, 4 December 2012‎ CsDix (talk | contribs)‎ . . (14,077 bytes) (-420)‎ . . (re-retweaked (to reduce gap between headings and contents when no heading background)) [1]).

CsDix (talk) 03:53, 4 December 2012 (UTC)

The alignment is looking fine to me. Maybe the problem went away with the introduction of new MediaWiki software yesterday? Let me know if you're still seeing issues. (A screenshot might help clarify things as well.) — Mr. Stradivarius ^{(have a chat)} 10:05, 5 December 2012 (UTC)

Here are a couple of screenshots of a couple of Sidebars as they appear on the Firefox-based browser ("Palemoon") I'm currently using:

Here, the space above each heading looks more than that below (especially e.g. in the Anthropology sidebar's first heading "Fields"). Small in the overall scheme of things, but noticeable. CsDix (talk) 16:50, 5 December 2012 (UTC)

PS I've just edited Template:Anthropology, so the screenshot above left was of this version of the template. CsDix (talk) 17:13, 5 December 2012 (UTC)

This looks better, but I am wondering about the condition padding in the first two fields. In particular, the part that changes the padding for the first heading if there is an image, and the part that changes the padding for the first contents if there is a first heading. The ordering on these statements appears to be important, and it's not clear exactly what is going on there. Otherwise, this looks very reasonable. Plastikspork _―Œ^(talk) 06:02, 8 December 2012 (UTC)

That's a good point; thanks. I've toyed with the sandbox code a little, left it with no special padding for the first heading/content (this version) and added another row of examples (that include images/captions) to those above. Maybe no special padding is required, as they seem okay here – how about there? (Perhaps I'm missing some circumstance/s where the special padding would still be required?) CsDix (talk) 06:25, 9 December 2012 (UTC)

Not clear what should be done right now, if anything, so I've declined the request. I've asked both of you to come back here and clarify what should be done. Nyttend (talk) 13:40, 18 December 2012 (UTC)

Okay, I think I got it. Let me know if there is a problem. Thanks! Plastikspork _―Œ^(talk) 05:43, 19 December 2012 (UTC)

How to lower or override the minimum line-width default?

Currently the minimum line-width default, in the content sections for example, equals about 33 Xs. But in the current Template: Economics sidebar, this results in at least 6 characters' worth of redundant white space in the content sections. Lowering the default width by 6 characters would fix the problem. Does anyone know how this could be done or whether there is a parameter-override function for the default that would shrink the minimum width of that (or potentially any) sidebar? Thank you. --Thomasmeeks (talk) 04:08, 29 November 2012 (UTC)

you can override the line-height for the contents using |contentstyle=line-height:90% or whatever, for the heading section, |headingstyle=line-height:90%, etc. to change the width of the template, use |width=20em or whatever. Frietjes (talk) 18:33, 29 November 2012 (UTC)

Thank you, F, for some other questions answered as well, which I think will be also be useful. I tried inserting |width= 20em and |width=0em to no effect, but |width=100em definitely widened the template! The |width=auto also left things unchanged. So, apparently the template is already at the lower bound as to width.§ It's not as though there's no way to get the content text closer to the edges, but that only works with more characters per line, not fewer, as this earlier version illustrates. There auto padding allows 2 to spaces to the right. Looks |width=auto like it is trying to leave at least 2 spaces of padding on each side of the line, but that seems to work only beyond the width currently at Template: Economics sidebar. If you agree, is there any way of fixing that asymmetry as to smaller vs. larger template widths? I have seen several sidebars with the same problem of undue width, spectacularly so in some cases. Would you have any suggestions on how to proceed?

§ Could a change transcluded parameter fix things? You'd be in a better position to know. --Thomasmeeks (talk) 21:54, 29 November 2012 (UTC)

how about this (using border-collapse:collapse). Frietjes (talk) 22:13, 29 November 2012 (UTC)

Well, your edit of the above into Template:Economics sidebar moved it in the right direction alright, reducing end blank spaced to a ratio of 5.5/8 from 8/8 (in cm. on my screen). My further attempt at 0.0em had no further effect. But the asymmetry is still there, just smaller, thus treating narrower text lines differently from broader text lines: about 3 (corrected from 5) extra ems per line. Maybe the software simply does not currently permit fixing the default.

Thank you for your excellent efforts. It appears that that is an irremediable default limit. Would you suggest requesting a global fix? If so, where? --Thomasmeeks (talk) 23:33, 29 November 2012 (UTC) (Correction bolded.) 05:13, 30 November 2012 (UTC)

to make it more narrow, you will have to shorten the "The economy: concept and history" line. this is the limiting factor, since it won't shrink any lower than that. I added some padding to the left and right of the headings (currently 0.3em), which could also be reduced, but might look a bit odd. if you add |wraplinks=true and change the "width:auto" to say "width:19em" you will see that the heading at the bottom will then line wrap, and make the template even more narrow. however, without the |wraplinks=true it will refuse to wrap that line. I personally think it looks better without the headings wrapped. Frietjes (talk) 00:55, 30 November 2012 (UTC)

Well, I earlier tested shortening a different line and later deleted the line you mentioned, to [have] no effect, that is, just as wide as before for the earlier template (closest on the right). Your current improvement of http://wiki.riteme.site/w/index.php?title=Template:Economics_sidebar&oldid=525604094 is still about 3 spaces wider than the earlier one that preceded the current "Template: Sidebar" formatting):

I did try tweaking the current fix but could not narrow it more (despite going to 0 ems). So, there's still a notable difference in white-space padding between the 2 versions.§ Proportionate to the line length, the current fix has a lot more space than say the space between your top (un-indented) paragraph and the left-margin edge. The problem addressed by this section-heading subject applies of course not just to the sidebar in question but to most sidebars using only 2 or 3 links to a line that employ "Template: Sidebar" formatting among the Category:"Part of a series on" templates, for example Template:Anglicanism and Template:Economic systems sidebar. The current default in each case imposes wide margins on them, whereas sidebars with more than 2 or 3 links are not saddled with wide margins. This asymmetry IMO still remains a problem. Any other thoughts are welcome.

§ I tried adding 3 X's to your fix at "The economy: concept and history" line. It gave just as tight a fit as the earlier template (left-most here) without widening your fix. So the earlier template (copied here) does not have overly-narrow default padding. Rather, the current sidebar, even with your fix, is broader than what earlier non-packaged formatting (later esp. of the estimable User:Morphh) permits. --Thomasmeeks (talk) 05:13, 30 November 2012 (UTC)

I made some minor changes to the sidebar in your example to achieve something very similar to the "previous" version. basically, removing the left-right padding and slightly reducing the heading and title size. whether or not it looks exactly the same (or how close) will be browser dependent, since various browsers quantize the font-sizes at different levels. Frietjes (talk) 19:47, 30 November 2012 (UTC)

Excellent outcome, F. Your adds, including explicit adjustable parameters (for example for the title font size, padding, collapsibility, etc.), & clean-up simplifications at Template:Economics sidebar will definitely help now and in the future allowing the good features of the earlier template to continue. It turns out that the limit on the width of the "current" sidebar is the larger picture size of the current sidebar, whose coding is this: [[file:GDP PPP Per Capita IMF 2008.svg|frameless]]. When that is replaced by [[Image:GDP PPP Per Capita IMF 2008.svg|200px]] from the earlier sidebar, the sidebar width shrinks to the size of the earlier version and without the excess white space. I'll acknowledge your resolving a big impasse on the appropriate Talk page.

One remaining question for now that still I have is whether there is any practical way of incorporating some variant of:

at the bottom of the sidebar for the current default of: V T E. Thank you for your help. --Thomasmeeks (talk) 17:16, 1 December 2012 (UTC)

there are two ways to change the navbar at the bottom: (1) make a request to add this feature to this template, (2) use |navbar=off with |below={{nobold|{{navbar|Economics sidebar|text= This sidebar:}}}}. the later would be the easiest, since it would take time to code it up and gain consensus. I personally like the default VTE links. Frietjes (talk) 17:55, 1 December 2012 (UTC)

A reasonable default alright, but I think there's argument for the transparency of the alternative to attract more potential editors for the case at hand anyhow. Ah, it worked (per above, bottom line + coloring). At the risk of exhausting your patience, 2 more questions. Is there also a way of:

(1) coloring the 2nd to last line like that of the earlier version

(2) right-floating the text of the new bottom line? Thank you. --Thomasmeeks (talk) 21:12, 1 December 2012 (UTC)

for the colouring of the second to last line, you can use |heading7style=background:#ccccdd and for right floating the new bottom line, you can use |belowstyle=text-align:right or |belowstyle=font-weight:normal; text-align:right; and then change the {{nobold|{{navbar|Economics sidebar|text= This sidebar:}}}} to {{navbar|Economics sidebar|text= This sidebar:}}. Frietjes (talk) 15:27, 3 December 2012 (UTC)

Ah, beautiful and elegantly simple. Thank you. --Thomasmeeks (talk) 23:23, 3 December 2012 (UTC)

no problem. we generally try to reduce the number of style statements per wp:deviations, but this shows that it can be done. Frietjes (talk) 00:01, 4 December 2012 (UTC)

... in more ways than one, such as the much-simpler hierarchical coding that that you have shown how to apply, which benefits editors as well.

IMO it should be possible to state good reasons for deviation from a navbox default, if it is challenged. For the benefit of others, let me also cite this relevant WP:NAVBOX guideline, which is listed first among advantages of navboxes:

Provides a consistent look and navigation system for related articles (though not between different topics — there is no single format across all navigation templates). (Italics added.)

I believe that what I've proposed above and below meets relevant guidelines (interpreted with good sense of course). (But I'd welcome comment if that seems doubtful in any given instance.)

I have tweaked the "current" (right) sidebar above including:

(a) re-sizing the top (Econ) box closer to the left sidebar (the rationale for which is to distinguish clearly its size from the section headings that follow but not to distract from them)

(b) aligning the caption of the map at the top of the sidebar from the center to the left, to distinguish it with the (centered) headings that follow

(c) matching the color of the top (Econ) box with the bottom 2 boxes to indicate qualitative differences of those respective boxes from the in-between boxes (also reflected in the left sidebar).

My thanks. --Thomasmeeks (talk) 18:22, 7 December 2012 (UTC)

Impressive... but dot size?

Just passing by and noticed this impressive template -- except that the dots within are a bit on the tiny side. Can they be boosted to what seems their usual size, e.g. as given by the "dot template" {{·}} at Wikipedia's standard font-size..? CsDix (talk) 04:00, 4 December 2012 (UTC)

Not sure what you're referring to - {{sidebar}} doesn't generate any dots, those are specified at point of use. Please note that that the documentation for {{·}} shows that it is deprecated, and it is preferred to use the WP:HLIST technique for generating the dots. However, dots generated by the {{·}} template are the · entity, boldfaced; i.e. · - and dots generated using WP:HLIST are Unicode Character 'MIDDLE DOT' (U+00B7), boldfaced: i.e. ·. Since · (·) and · (·) are exactly the same character, just specified in different ways, there will be no visual difference between them. --Redrose64 (talk) 14:50, 4 December 2012 (UTC)

You beat me to it, RR. But for the record let me add this in-transit comment.

I could be wrong about this, but possibly the link separators of the both sidebars above would better described as bullets rather than dots (at least on my non-big screen) relative to the smaller size of the fonts in which they are embedded. They use different formats but are similar in appearance (at least on my monitor) with the left one doing what you suggested ({{·}} and in the direction you wanted:  · vs. ·) and the right one using Template:Sidebar markup using the default of * to separate links in a line. Before Frietjes cleaned up the Econ sidebar, the right one looked like this. So, his Edits definitely moved the right sidebar in the right direction! --Thomasmeeks (talk) 15:16, 4 December 2012 (UTC)

Apologies, Thomasmeeks: it was my oversight. I hadn't noticed that the examples above included a custom font-size reduction (unlike the live {{Economics sidebar}} template). Thanks for the dot explanations, Redrose. CsDix (talk) 15:22, 4 December 2012 (UTC)

PS I suggest either retaining hanging dots throught the template (i.e. no blank lines between links in the code) or having none at all (e.g. by using the plainlist class and perhaps switching the template to a collapsible-lists format).

On your PS, I agree & believe the editor may have re-added the "wraps" merely to show their effect (I could of course be wrong here). The right sidebar above is implicitly an argument that bullets are unnecessary at the end of a line (possibly when accompanied by <br/> to defeat the default). It is (partly implicitly) supported by Template talk:Economics sidebar#Recurrence of edit with multiple disputed format changes: wide, fragmented link lines etc., points (1T) and (3T --there called a dot, but better called a bullet), which were accepted in the brief comment that followed there. --Thomasmeeks (talk) 16:34, 4 December 2012 (UTC)

I don't like hanging dots either, but I've learned that using <br/>s or blanklines to avoid them (or the "dot/bullet templates" like {{·}} to customize listings) compromises accessibility when people use screen-readers, etc. So, for now, I'm going with "all or none" as regards dots, with a strong preference for none in sidebars / sideboxes when feasible. Thanks for your feedback. CsDix (talk) 17:42, 4 December 2012 (UTC)

Well, this may be only a semantic (rather than substantive) distinction, but more strictly speaking, there is no "{{·}}" or "·" link separator in the right template above, only * link separators that end up looking like bullets. So I'm not sure that the above applies. But, suppose that someone asserts otherwise, presenting a replicable basis of verification. That would be of interest, especially with a description of what the compromise in accessibility looks like to the affected person from use of <br/>. My thanks. --Thomasmeeks (talk) 20:26, 4 December 2012 (UTC)

I don't know how much you know about cascading style sheets, but MediaWiki:Common.css contains a number of stylings specific to the class hlist. The two chunks to particularly observe are this:

/* Display list items inline and make them nowrap */
.hlist dd,
.hlist dt,
.hlist li {
    margin: 0;
    display: inline;
    white-space: nowrap;
}

and this:

.hlist dd:after,
.hlist li:after {
    content: " ·";
    font-weight: bold;
}

Essentially, when the hlist class is applied to a bulleted list, the first chunk of code above eliminates the newlines which normally occur between list items; and the second chunk alters the bullets that would have appeared at the start of the line so that they are displayed them as a boldface · We can demonstrate that quite simply - if I put the following wikicode:

<div class=hlist>
*First item
*Second item
*Third item
</div>

it displays as follows

• First item
• Second item
• Third item

--Redrose64 (talk) 20:57, 4 December 2012 (UTC)

Well, I was in the neighborhood, RR, but I sure didn't expect to be visiting so soon (;-). I was trying to ask a somewhat different question above (as to what alleged replicable bad results look like from using <br/>. That also goes to what is displayed. But your answer is of course of independent interest. Are you suggesting that irrespective of what problems <br/> might or might not have as to hindering accessibility:

<nowiki>/* Display list items inline and make them nowrap */ ... <div> * ... * ...</div></nowiki> might be an alternate way of avoiding <br/>? My thanks. --Thomasmeeks (talk) 22:06, 4 December 2012 (UTC) --Thomasmeeks (talk) 21:52, 4 December 2012 (UTC)

Not sure what you're trying to do. The <br /> tag forces a line break into the rendered page, and no amount of styling will eliminate it again. I presented the two chunks of CSS as examples of what is already set up for you - you do not need to put any of that into a page in order to use the WP:HLIST feature. The <div>...</div> example was a demonstration of one method of utilising a HLIST, it's usually easier to use the relevant parameters in existing templates. For example, in the first {{sidebar}} example (that of 05:13, 30 November 2012), the parameter |class=hlist is present. That switches on the HLIST feature for the whole sidebar. --Redrose64 (talk) 22:25, 4 December 2012 (UTC)

My writing above is very condensed and relies on a close reading of the previous section. There, I was asking whether the width of the sidebar could be narrowed to eliminate lots of white space in the right sidebar and without use of end-of-line * but substituting <br/> instead. The imposition of Template:Sidebar unvarnished mark-up conventions + end-of-line *, it was argued at Template talk:Economics sidebar#Recurrence of edit with multiple disputed format changes: wide, fragmented link lines etc. created more problems than it solved. Anyhow my monitor shows the <br/> (in place of end-of-line *s in the Edit mode of right sidebar of the previous section) doing exactly what your mark-up protocols do: move to the next line for another string of usually 2-3 links. There's no downside that I can see from that as compared with your mark-up protocols. But I read into CsDix's PS above his belief that end-of-line <br/> compromises accessibility. I can't see evidence of any difficulty at my end. I thought that you were proposing an alternative to both end-of-line <br/> and to end-of-line * to start a new line. My thanks. --Thomasmeeks (talk) 01:32, 5 December 2012 (UTC)

I have to confess I haven't learned anything particular yet about accessibility here, but I do know there's the Wikipedia:Accessibility page I've yet to read and I think I saw User:Frietjes mention somewhere that he's partially-sighted. If that accessibility page doesn't clarify matters, I imagine he'd be happy to do so instead. CsDix (talk) 02:29, 5 December 2012 (UTC)

Well, very forthright of you IMO. --Thomasmeeks (talk) 04:00, 5 December 2012 (UTC)

OK, accessibility. I don't want to restate what it says at WP:LISTGAP, but consider the following two examples, both formatted with hlist. The first eliminates two trailing bullets by introducing two blank lines:

• White rose
• Yellow rose

• Pink rose

• Red rose

The second eliminates two trailing bullets by using explicit line breaks (by means of <br /> tags) to append two items onto another:

• White rose
• Yellow rose
  Pink rose
  Red rose

To a sighted person, they look exactly the same. However, whether we've used the normal bulleted list, or formatted it with WP:HLIST, the second one is described differently from the first - the first might be "List of 2 items: (bullet) White rose, (bullet) Yellow rose, list end. List of 1 items: (bullet) Pink rose, list end. List of 1 items: (bullet) Red rose, list end." whilst the second might be "List of 2 items: (bullet) White rose, (bullet) Yellow rose (line break) pink rose (line break) red rose, list end." The "cleaner" visual appearance of eliminating a trailing bullet has caused screen reader software to generate a description that is somewhat less "clean". The correct action would be to have it as just one list, constrained inside an explicit width and let the trailing bullets appear as normal:

• White rose
• Yellow rose
• Pink rose
• Red rose

At Template talk:Infobox London station#Formatting snafu? you'll find a discussion about harmonising the style of what was intended to be two bulleted lists, but was in fact three for the aesthetic appeal of eliminating one bullet. By making the small sacrifice of permitting that trailing bullet, we've improved the infobox for accessibility.

An edit like this which introduces blank lines also has the effect of splitting up the discussion into several essentially separate discussions. When we use colons to indent posts, what we're actually doing is setting up a description list, essentially the same as the "definition list" mentioned at WP:LISTGAP. If there are no blank lines, you get one list (with sub-lists), but if you add blank lines, you get lots of lists. Screen reader software announces the beginning and end of each list, so when there are blank lines, you get aural clutter. --Redrose64 (talk) 09:07, 5 December 2012 (UTC)

As regards your last point, that's something else I didn't know: that blank lines between incremental (or decremental) indents can also upset screen-readers etc. But why did I add those blank lines? To reduce the visual density (visual clutter) of the code and facilitate (make more accessible) my locating previous comments while I typed my reply. In this particular case, I'd hope it's possible for screen-readers etc to keep count or have it indicated. (But I'm guessing that would start opening another can of worms!) CsDix (talk) 16:35, 5 December 2012 (UTC)

It's not a problem with the screen reader. When you put a blank line into any list, the Mediawiki software closes all open lists, and then opens a fresh set to the specified depth. Let's assume that you have some wikicode like this:

::::Fourth posting
:::::Fifth posting

The HTML for that is

<dl><dd><dl><dd><dl><dd><dl><dd>Fourth posting<dl><dd>Fifth posting</dd></dl></dd></dl></dd></dl></dd></dl></dd></dl>

Each <dl> is a list (or sub-list) being opened; each <dd> is the start of an entry in that list; each </dd> is the end of an entry; and each </dl> is a list being closed. You can see that between the fourth and fifth posting, all that happens is a sub-list is opened, containing one entry. Now lets assume that a blank line is inserted. The HTML becomes

<dl><dd><dl><dd><dl><dd><dl><dd>Fourth posting</dd></dl></dd></dl></dd></dl></dd></dl>
<dl><dd><dl><dd><dl><dd><dl><dd><dl><dd>Fifth posting</dd></dl></dd></dl></dd></dl></dd></dl></dd></dl>

It can be seen that between "Fourth posting" and "Fifth posting" we have four lists being closed, and five lists being opened. A screen reader cannot know that the intention was for the fifth posting to be a follow-on from the fourth. --Redrose64 (talk) 17:33, 5 December 2012 (UTC)

RR, my apologies for neglecting details in User:Frietjes elegantly simple series of Edits culminating in http://wiki.riteme.site/w/index.php?title=Template:Economics_sidebar&oldid=525604094 (reproduced in the section above) that in combination makes a line-skip space in Edit mode avoid an end-of-line bullet, without <br/>, and many of the features objected to in Template talk:Economics sidebar#Recurrence of edit with multiple disputed format changes: wide, fragmented link lines etc.. Your patience and clear exposition above are appreciated. Best wishes to you and to CD. --Thomasmeeks (talk) 18:45, 5 December 2012 (UTC)

How to have a heading box appear before the top figure in the sidebar?

So far so good on the sidebar at the top of this section, reproduced [below] and relabelled from (final) to (A.1).§ It is easy enough to move the 3rd-from-bottom box ("The Economy...") to just before the "General categories" heading (namely renumber it from 'heading6' to 'heading1'). Is there any easy way to have it appear before the figure instead?* Thank you.

§ It is the same label as at the bottom of Template talk:Economics sidebar#Recurrence of edit with multiple disputed format changes: wide, fragmented link lines etc., the source from this whole section first arose. I have here narrowed to the final version of the top section by reducing the figure to 200px per the discussion in the top section.

* An argument for doing that is the conceptual link of "The economy..." between Economics and the figure of "Economies by country". --Thomasmeeks (talk) 23:11, 14 December 2012 (UTC) TM 12:52, 15 December 2012 (UTC)

I modified your example to move the heading above the image. Frietjes (talk) 17:40, 16 December 2012 (UTC)

OK. I've labelled your revision as (A.3) & added back the original (A.1). (A.3) is of interest in in itself, but I had something a little different in mind, which your comments on my & your talk pages allowed me to complete. Much thanks for those. The other sidebar is labelled (A.2) at http://wiki.riteme.site/w/index.php?title=User:Thomasmeeks/Rough_draft2&oldid=528378105. I'd like to add it here, since it might be of independent interest.

But first, may I ask if there is an easy way of right-floating the [sidebars] so they are parallel (not stacked) to allow comments to the the left of the templates. Thank you. --Thomasmeeks (talk) 23:10, 16 December 2012 (UTC)

Sidebar (A.2), mentioned above, has been inserted below between (A.1) & (A.3).

For the record, and in case anyone would attempt a similar change on some other sidebar, the sidebar-markup wp:differences in going from (A.1) to (A.2) are at http://wiki.riteme.site/w/index.php?title=Template_talk:Sidebar&diff=528508255&oldid=528507653. #

The format diffs in going from (A.1) to (A.3) are at http://wiki.riteme.site/w/index.php?title=Template_talk:Sidebar&diff=528506300&oldid=528505671.

# Not all such efforts to move a later "heading" up seem so simple. This change did not even require renumbering later heading and content numbers, despite moving a later "heading" up to heading1, because there were no heading1 and content1 lines in (A.1), only in (A.2) at the top for the new formatting of the map and its heading.

Let me here reiterate my appreciation to Frietjes for his patient efforts to make seem easy what had eluded me. --Thomasmeeks (talk) 19:31, 17 December 2012 (UTC)

Line-break inconsistency between view version of sidebar & sidebar line in article links

In the view version Template:Economics sidebar, one content line of the first section looks like this:

Methodology • Heterodox approaches

with links to Economic methodology and Heterodox economics.

But at Economic methodology, the sidebar display looks like this:

Methodology •

Heterodox approaches.

And similarly for Heterodox economics, it looks like this:

Methodology •

Heterodox approaches.

I haven't found any other Econ sidebar articles with the same display problem. That is, the sidebar works fine for all lines elsewhere (e.g., History of economic thought). Given the long length of the original line, are any of the following sidebar parameters suggested for change to fix the problem?

| bodystyle = border-collapse:collapse; width:auto

| headingstyle = padding:0.1em 0.0em; background-color: #dde; border: 1px solid #bebebe; font-size:97%

Thank you. --Thomasmeeks (talk) 17:42, 19 December 2012 (UTC)

if you set the width to auto, it should not wrap any lines, but should set the width of the sidebar to be the minimum width necessary for each line. the current version of the template has "width:18em", which is enforcing a width of 18em. if you do use "width:auto", you need to make sure you specify all the line breaks manually, which is a pain. Frietjes (talk) 18:59, 19 December 2012 (UTC)

Right again, sir!

I made this Edit at http://wiki.riteme.site/w/index.php?title=Template:Economics_sidebar&curid=19081399&diff=528850514&oldid=527739446Template:Economics sidebar:

FROM: | bodystyle = width:18em;border-collapse:collapse

TO: | bodystyle = width:auto; border-collapse:collapse

Within a few minutes, the problems mentioned above for the Econ sidebars displayed at Economic methodology and Heterodox economics were corrected.

The blank line in Edit mode between each each view-mode ContentX line were already in Template:Economics sidebar. So the edit above required no added individual line formatting to fix the problem. Thank you so. --Thomasmeeks (talk) 20:56, 19 December 2012 (UTC)

Edit request on 16 January 2013

The repeated bits of styling code for this Sidebar template prompted me to wonder whether Sidebar had a "basestyle" parameter in the same vein as Template:Navbox. As it didn't, I've added one to this sandbox version and it appears to work correctly with the test I added at the start of the testcases page. So, if it does look legitimate, please replace the current Sidebar code accordingly and I'll update the documentation. CsDix (talk) 02:28, 16 January 2013 (UTC)

As loathe as I am to make this any more customisable, this actually helps to reduce the amount of code required to style sidebars in most cases and so I've synced. Thanks. Chris Cunningham (user:thumperward) (talk) 10:08, 23 January 2013 (UTC)

• Thank you for making the edit. I don't think it makes the template any more customisable, but, as you say, can streamline it. And, no need, I feel, to loathe customisation – I can see that "one size doesn't fit all", especially given the scope to which Wikipedia aspires. Thanks again, CsDix (talk) 02:50, 25 January 2013 (UTC)

Edit request on 21 February 2013

At present, the default / fall-back width for this template is 22.0em (line 6). But, on smaller screens / windows / resolutions, e.g. 1024 by 768, this is on the large side. Meanwhile, many Sidebars seem to have their widths set at or around 18.0em – see, for instance, those Category:Political ideology templates using Sidebar. May, therefore, Sidebar's default width be decreased to a compromise 20.0em, please? (To do so, replace line 6 of the present code with the following:)

           -->width:{{#if:{{{width|}}} |{{{width}}} |20.0em<!--default/fallback width no greater than 20.0em, please, for the sake of smaller screens/windows-->}};<!--

CsDix (talk) 01:58, 21 February 2013 (UTC)

I've deactivated procedurally, since this is a rather innocuous but large change which would need consensus. I personally don't agree that this is an issue; the average screen size today is larger than 1024px.[2] --Izno (talk) 03:10, 21 February 2013 (UTC)

That said, I personally do not understand why we are hard-declaring the width here rather than adding that to the CSS using the vertical-navbox class. I would say the same for the cellspacing and cellpadding, which are deprecated attributes on top of that. And why are we providing all these custom parameters style parameters when the simple use of bodystyle would suffice? *sigh* --Izno (talk) 03:15, 21 February 2013 (UTC)

• Why deactivate? Why not make the change, then see if people come running to have it undone or modified – in other words, prompt them to express a consensus – ? Right now, I must say your action seems to me to smack of something like censorship.

As regards width not being an issue, I'm afraid there are plenty of places where 1024 by 768 is the highest decent resolution available. Let's not lose sight of how well-equipped many of us might be. Meanwhile, on the other hand, how about Wikipedia in windows that aren't full-screen?

And, as regards custom parameters, who says one size (bodystyle, defaults) should fit all..?

CsDix (talk) 03:32, 21 February 2013 (UTC)

Hardly censorship. The template you used should only be used for uncontroversial changes. This is controversial. Therefore, the template should not have been used. QED.

Those places are steadily becoming fewer. Should we limit everyone for the sake of the few (less than 10% now!)? In general though, the pages which use this template fail gracefully.

I'm simply saying on the point of the custom parameters that one parameter would fit all: "style" or "bodystyle" (whichever we want to call it). --Izno (talk) 03:41, 21 February 2013 (UTC)

It smacks of censorship. Imagine a different point of view for a moment.

I don't know whether or not changing the default width will be controversial. How do you know it will be – beyond yourself and anyone you know who shares your point of view – ?

Why should a reduction of 2.0em be regarded as if only a limitation? Another point of view is that 22.0em rather than 20.0em is a greater limitation on the amount of text that can be displayed beside the sidebar, regardless of resolution etc.

As regards style/bodystyle, then, I'm not sure what point you're making – apologies if I'm missing something obvious.

CsDix (talk) 04:00, 21 February 2013 (UTC)

Edit request on 24 February 2013

Hello. I noticed that a means to specify the class for any particular heading and content section (e.g. in order to switch, temporarily, from hlist to plainlist) hasn't yet been implemented, so this version of the template in the sandbox should now provide this possibility (look for {{{headingNclass}}}es and {{{contentNclass}}}es). If all looks okay, please make it the live version.

CsDix (talk) 05:00, 24 February 2013 (UTC)

Adding even more customisation here rather belies the point of standardising it in the first place (one key reason for doing so was to attempt to increase the overall consistency of different sidebars). Is there a specific case where there is a consensus that this is necessary? Chris Cunningham (user:thumperward) (talk) 12:14, 27 February 2013 (UTC)

I fear you may be missing the point (hint: the parenthesis). Thanks, though, for your attention. CsDix (talk) 18:51, 27 February 2013 (UTC)

Again, is there a concrete example here? Do we really want to have a mix of different list types in a single sidebar? Please don't continue to re-enable editprotected requests while they're disputed. Chris Cunningham (user:thumperward) (talk) 10:13, 28 February 2013 (UTC)

Template:Thermodynamics, were it to be converted to use semantic lists while preserving the current format, would. However, I'm not sure whether I would support this request. It does seem to me that we're losing the opportunity for microformats (which I'm not sure we want in a sidebar). That said, I think this request would add more complexity than is worthwhile, and so I think on the few cases where we might want to do it, we can just change the classes ourselves. Just musing here. --Izno (talk) 17:03, 28 February 2013 (UTC)

Never mind. As Izno indicates, it's something that can be done manually (i.e. less elegantly) anyway. Don't see why a mix would be a problem and the circumstance I had in mind was an hlist of links each of whose length meant they were rendered one per line, i.e. as if a plainlist. Just thought it was an oversight worth correcting, but I guess not. CsDix (talk) 00:39, 1 March 2013 (UTC)