Module talk:Sidebar/Archive 3

Edit request on 24 February 2013
I'm reissuing the request from 21 February – to reduce the template's default width from 22.0em to 20.0em for the sake of smaller screens/windows – as I don't believe its first outing was given, so to speak, enough light of day. Screen resolutions of 1024 by 768 or less may be ever more uncommon nowadays, although I know older people who (e.g.) browse using 1024 by 768 on a widescreen as they find it easier on their eyes. Furthermore, though, this template's present default width also seems to assume Wikipedia will be viewed full-screen, which I know is not always the case. I'm therefore suggesting 20.0em as a compromise between the present 22.0em and the 18.0em specified by quite a few Sidebars I've seen (see above).

The change may be made by replacing the line

and  CSS, which is not yet supported by all major browsers (yours might support it for your own CSS). Whether we care if there is support may be a different question. Otherwise, I support what Frietjes has said. --Izno (talk) 17:46, 19 February 2013 (UTC)


 * As regards everything above, I can see I'm getting ahead of what's possible generally (as well as what I'm able to do), so, for the time being at least, I'll accept the hanging dots and work elsewhere. Thanks to all for your explanations etc. CsDix (talk) 23:48, 19 February 2013 (UTC)

Informative discussion above IMO. Let me ask some questions first, which anyone(s) can answer.

Q1T. Does browser dependence of "hanging dots" mean that a blank line before • Link F • Link G may, depending on the browser, move the • before Link F to the previous text line?

Q2T. Do "unmanaged hlists" refer to those that have that have not used blank lines to avert end-of-line hanging dots? If yes, are hanging dots in that case also browser dependent?

If there any other points my questions may be missing, feel free to elaborate. P.S. 2 sidebars here IMO opinion show the advantage of the above proposal (in template A). Thank you. --Thomasmeeks (talk) 19:37, 21 March 2013 (UTC)


 * A1T: A blank line between entries in an hlist means that no dot is placed after the first of the entries and the second then begins on a new line. (Hope that addresses what you're asking.)
 * A2T: "Unmanaged" lists in the above means those hlists that are continuous, i.e. without workarounds such as the blank line (and thus with hanging dots).
 * Of the sidebars linked, I too prefer sidebar A (but with a few tweaks), although the separate V • T • E bar below it looks a little odd..?
 * CsDix (talk) 01:26, 22 March 2013 (UTC)
 * I'm addressing your last line, which is germane but a digression for present purposes, in a footnote.§
 * I relabelled your answers above as A1T & A2T. They are as I expected. I think that they fix the problem of hanging end dots.  Indeed, the blank line between text lines seems designed to do just that. (Otherwise it would be quite a coincidence that they happened to fix it.)  Whether editors know how to fix hanging end dots  (or think that they are problematic) is another question.  I might be missing something here, but I'd welcome comment(s) before proceeding.  Thank you.
 * § The odd V • T • E box (under but not part of template (A) in my here link) is indeed extraneous for present purposes. Its width proved to me that:
 * which by itself produces:
 * which by itself produces:


 * for the default width of sidebar (B) in my here link above, is sufficient to produce a 20% wider sidebar than (A).
 * So, the wider (B) template as the default width is present from the first coded line of (B). --Thomasmeeks (talk) 03:34, 22 March 2013 (UTC)


 * Thanks for explaining the V • T • E box. Yes, inserting blank lines prevents hanging dots, but you'll find doing so will eventually be undone as it also breaks up the hlists and thereby contravenes accessibility. Unfortunately, I don't have the know-how to produce an acceptable solution (e.g. make the hanging dot invisible) and I've yet to see any interest or motivation in those I've met who might be able to do so. CsDix (talk) 09:18, 22 March 2013 (UTC)

Well, if a blank coding line would present an accessibility problem, one possible solution (as in the Template:Politics sidebar)) would be to replace the coded blank line with a coded line of:



instead. That's not a blank line as coded at the WP:LISTGAP guideline. Comments welcome. --Thomasmeeks (talk) 13:06, 22 March 2013 (UTC)
 * I've been told that (sadly) this makes no difference and an hlist articulated this way would still not be interpreted as a single hlist. So, assuming that's correct (I've no reason to think not), it looks like removing hanging dots in an accessibility-friendly way requires something more "low-level". CsDix (talk) 01:32, 23 March 2013 (UTC)
 * Thank you for more than due diligence (at which link BTW is a more extreme example of text-line-length disparity in the sidebar than because of its greater width.

Q3T. OK, so does a "low-level" fix for hanging end-line dots mean such list vs. hlist formatting as you introduced [http://en.wikipedia.org/w/index.php?title=Template:Libertarianism_sidebar&diff=543632383&oldid=542930290? here] (ingeniously IMO)? --Thomasmeeks (talk) 16:35, 23 March 2013 (UTC)
 * Again, unfortunately, using hlist within a "plainlist" also doesn't "cut the mustard" as it has the effect (so I've been told) of breaking up the plainlist. So, yes, by "low-level" I mean beyond the reach of us mere mortals, i.e. something somewhere in the bowels of the software that runs Wikipedia. CsDix (talk) 02:26, 24 March 2013 (UTC)
 * Very patient of you (& your teller[s}). Which leads to another question.

Q4T. As an illustration, wouldn't using your hlist formatting (per Q3T here example):
 * * Behavioral Cultural Evolutionary ,

which (with other sidebar formatting) would look like this:
 * Behavioral • Cultural • Evolutionary

throughout a contents section of the sidebar allow for customized text-line length without use of list statements and without end-of-line dots? --Thomasmeeks (talk) 12:06, 24 March 2013 (UTC)
 * if you want to check to see if any of these options are in conflict with WP:LISTGAP, simply view the HTML source for the particular list. if you see

 item 1 item 2 item 3 item 4 
 * all is well. if you see

 item 1 item 2  <ul> <li>item 3</li> <li>item 4</li> </ul> or <ul> <li><ul> <li>item 1</li> <li>item 2</li> </ul></li> <li><ul> <li>item 3</li> <li>item 4</li> </ul></li> </ul>
 * you have a split what should be one list into two lists. if you see any • symbols, you have broken the list entirely. adding a newline gap or a : gap between bulleted items does the exact same thing, since the preprocessor trims empty list markup.  using a combination of a plainlist with hlist sublists also splits the list. Frietjes (talk) 17:17, 24 March 2013 (UTC)


 * Yes, though hlists without asterisks might be another way to avoid the hanging dots, they too would break accessibility in the way Frietjes indicates. In short, it seems the systems as they currently stand don't allow hanging dots to be avoided without breaking accessibility, which is why I imagine something more low-level is needed. Unfortunately, as above, it also seems that those folk with the access and know-how required don't see these dots as blemishes when they appear in templates such as sidebars. CsDix (talk) 06:35, 25 March 2013 (UTC)
 * I think "it also seems that those folk with the access and know-how required don't see these dots as blemishes when they appear in templates such as sidebars." is unnecessary. For the most part, we agree that hlists in vertical templates SuckTM. There's just nothing we can do about it. --Izno (talk) 12:54, 25 March 2013 (UTC)
 * Apologies, Izno – I must've missed where you shared my disappointment with this feature. I don't believe for a moment, though, that there's nothing (within reason) that can be done about it. In a rendering routine somewhere: "IF linewrap required before next item (AND e.g. no-hanging-dots set in user's preferences) THEN render dot with visibility:hidden (or even simply omit it)", so to speak. CsDix (talk) 14:40, 25 March 2013 (UTC)
 * "In a rendering routine somewhere" really is beyond our reach, as I'm pretty sure Javascript can't detect that the line has broken (and CSS certainly cannot), and that would mean actually being able to tinker with what's going on in your browser (in other words, being a Firefox developer). And what Firefox (browser) developer would implement such a small thing for one site? Maybe JS can, but I'm guessing that would require manipulation of the browser particulars. We shouldn't introduce browser dependencies, ever, otherwise we go down the route of the browser wars.... --Izno (talk) 15:22, 25 March 2013 (UTC)
 * If it goes that deep, i.e. becomes browser-dependent, then, yes, I guess that's too deep – but my instinct is that it isn't (or shouldn't) reach that far. I admit, though, that it's not a well-informed instinct. (There should be a way, though, to know when any browser on any machine is about to linewrap, no..?) CsDix (talk) 15:51, 25 March 2013 (UTC)
 * A lot to digest above. Let me express appreciation for detailed & complementary comments above pertinent to my last questions. I number the following for ease of reference

1T. The advice at WP:LISTGAP of no blank line between successive links seems entirely appropriate for bulleted vertical lists, because a blank line is seen only in WP:Markup but read as "end-of-list" by screen readers (per Frietjes comment above), hence either unseen or worse. So, Advantage: No blank lines for bulleted vertical lists.

2T. The advantage as to WP:Accessibility arguably shifts toward favoring use  of a blank lines when they preserve a useful h[orizontal]list relationship among links on a given line or between successive lines. That is consistent with WP:SIDEBAR, paragraphs 4-6 from bottom as to reflecting that links are related to each other, in this case by placement of a given set of links on a given sidebar line. That also makes each line a horizontal list, like a line in a poem, & meant to be read not only as to individual links but in relation to each other. Successive lines then are similar to successive lines in a poem.

The screenreader appropriately picks up on that at each such line (read as "end of list"). That explains why use of a blank line suppresses a end-of-line dots. The remaining dots on that line are meant only to separate links there. End-of-line dots are redundant for that purpose. The fact that all links are in a content section arguably also makes end-of-line dots redundant. It's already apparent that all links in a given content section should be related to each other without the need for end-of-line dots. (Of course end-of-line dots could be retained with the list default but at the cost of end-of-line dots, which also may widen slightly text lines.)

3T. A link that shows the differences from using (or not) blank lines between links to generate successive sidebar lines is a reworking of the Template:Economics sidebar here. In it, template (A) uses blank lines between some links to generate lines closer to the Journal Economic Literature JEL classification codes, For example:
 * Health • Education • Welfare.

(B) there uses no blank lines between links, which results in listing that moves up by a line & by default (unintentionally) the first link on all lines from Public & Welfare econ & after. This breaks the narrative of (B), compared to the JEL-code-friendly (A). For example the last line of the previous paragraph in (B) becomes:
 * Health • Education • Welfare • Population,

which is not a JEL code. That's comparable to moving up the first word in successive lines in a poem to the previous line (not good). --Thomasmeeks (talk) 20:54, 8 April 2013 (UTC)

4T. The proposal at the top is for a 18em sidebar vs. the 22em default (about 20% wider). That complements the 2 preceding points. Given the difficulty of finding complementary links per line and resulting narrower text-line lengths, the narrower sidebar width wastes less horizontal line space and thereby makes the sidebar less obtrusive. --Thomasmeeks (talk) 19:24, 2 May 2013 (UTC)

Embedding
I mocked up a version that supports yes, in the same way that supports yes. the code is in sandbox2 (it looked like the main sandbox was in use). an example is presented in Template:Sidebar/testcases. I made it not render the navbar, and ignore any outertitle, pretitle, or preimage in the child. I could make it still support pretitle and preimage, but outertitle won't work since it's part of the table caption. the reason for ignoring the others was to make title work in the child in the same way that it work in (i.e., have it not output the leading &lt;tr> and &lt;td> for that row to avoid blank rows). if there are no problems with the code, I will make an edit request, and see about merging it with the lua module as well. Frietjes (talk) 20:12, 24 May 2013 (UTC)
 * Looks good to me. Thanks for coding it up! Plastikspork <sub style="font-size: 60%">―Œ <sup style="margin-left:-3ex">(talk)  01:07, 25 May 2013 (UTC)
 * great, enabling the edit request. please update the template to use the version in Template:sidebar/sandbox2 (note sandbox2, not sandbox).  the test cases for the embedding can be seen in Template:Sidebar/testcases. Frietjes (talk) 13:58, 25 May 2013 (UTC)
 * Done! Plastikspork <sub style="font-size: 60%">―Œ <sup style="margin-left:-3ex">(talk) 22:16, 27 May 2013 (UTC)

Exclude from print functionality currently broken, workaround?
Many Sidebars are in Category:Exclude in print so they are not rendered in the Books created from Extension:Collection. Unfortunately the underlying functionality is currently broken. As noted in a related bug report there is a workaround,

Content that is not supposed to be included in the PDF can already be marked with the css class "noprint":

> blub noprint As an example Template:Navbar is constructed with so navigation bars are not included in Books. Would it be feasible to change the template to include this change rather than requiring each sidebar using the template to be changed? --Peculiar Investor (talk) 13:56, 1 November 2013 (UTC)
 * this template includes vertical-navbox, which is listed in MediaWiki:Print.css, so this is not being parsed? Frietjes (talk) 17:52, 1 November 2013 (UTC)
 * Unfortunately Extension:Collection uses the MediaWiki API and doesn't appear to utilize MediaWiki:Print.css. --Peculiar Investor (talk) 19:48, 3 November 2013 (UTC)

Switching to Lua module
I was going to play around with creating a Lua version of this template, but then I noticed that Toohool created one about a year ago (Template:Sidebar/sandbox). Would anyone object if I finish it up and switch us over to it? Kaldari (talk) 22:52, 30 January 2014 (UTC)

headingNclass?
Are parameters such as heading1class heading2class etc meant to work here? Sardanaphalus (talk) 09:41, 9 June 2014 (UTC)
 * No, enumeration only works with styles (heading1style etc.) There is only headingclass. See Template:Sidebar for all supported parameters. — Edokter  ( talk ) — 09:49, 9 June 2014 (UTC)
 * Thanks. Sardanaphalus (talk) 19:46, 9 June 2014 (UTC)