Jump to content

Module talk:Sidebar/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 6

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

           -->width:{{#if:{{{width|}}} |{{{width}}} |22.0em}};<!--

near the top of the code with

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

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

Which makes it not stack properly with {{infobox}}. This is an ill-thought-out request, as evidenced by your fairly ridiculous assertion of censorship the last time it was declined. Rather than coming up with cherry-picked examples ("this group of sidebars sets the width, therefore it'll work for all sidebars") or vague instructions for other people to do lots of work ("{{infobox}} should be updated as well"), come up with a more convincing argument than a vague assertion of crowding on low resolutions (which less than 10% of our desktop PC users are on these days; factor in laptops, which are widescreen, and mobile devices where sidebars don't float, and that's a tiny percentage of the user base). Declining again: please do not reenable unless there is a clear consensus to make this change. Chris Cunningham (user:thumperward) (talk) 12:11, 27 February 2013 (UTC)
There are two arguments in the initial message that I think you may've missed. As regards consensus, does this mean I need to start asking people to come to here to post some words of support? How about the "Be Bold (i.e. make the change), Revert, Discuss" method I've seen acknowledged in various places..? CsDix (talk) 18:56, 27 February 2013 (UTC)
"Be bold" has its limits. One of those limits is that if you're going to propose a change which is going to affect 66828 pages simultaneously, it's best to ensure that it's not going to have unforeseen consequences first. Put it this way: had this template not been fully protected, A width change would have been reverted immediately: in the WP:BRD cycle, that takes us to "discuss". So, to address your points:
  1. Only a very small number of readers, getting smaller, use low-width displays;
  2. The assertion that a 2em reduction in width will significantly help in that case is disputable anyway;
  3. ... As is the assertion that readers will be inconvenienced when viewing Wikipedia in a non-maximised window
  4. In the 18 months since a default width was added, templates have relied on this width for their presentation, and densely-worded sidebars using hlists will have their output significantly altered by additional line breaks forced by a lower width. In the common case where a sidebar runs alongside the TOC at the top of an article, this will increase the amount of dead whitespace on a reader's display (particularly on less tall displays such as laptops) for no advantage.
  5. {{infobox}} has defaulted to 22em for very nearly five years, and altering the width here will result in sidebars no longer naturally stacking with infoboxes (which is extremely common).
Given all of that, the width should not be changed lightly. Two editors have already declined it. If you'd like to propose the change in a more central location, I'd advise you to start an RFC. Chris Cunningham (user:thumperward) (talk) 10:31, 28 February 2013 (UTC)
  • Thanks for your advice. I'm not that invested in the situation, so I'll the inertia of the status quo prevail. I'd've like to've seen, though, if and how any readers rather than administrators would've responded to the change. You dispute whether any assistance would be given to people viewing the encyclopedia in a window rather than full-screen (i.e. this remains moot) but I remain unsure whether you've recognis/zed any value in the other observation – I don't think any of us are getting any younger. CsDix (talk) 00:53, 1 March 2013 (UTC)

Edit request on 27 February 2013

Please replace the current "below" line (near the end of the code) ... 

 -->{{#if: {{{below|}}}
     |<tr><td class="{{{belowclass|}}}" style="padding:0.3em 0.4em 0.3em;font-weight:bold;{{{belowstyle|}}}">
{{{below}}}</td>
     </tr>
    }}<!--

...with the following version, where the top padding has been halved to 0.15em... 

 -->{{#if:{{{below|}}}
     |<tr><td class="{{{belowclass|}}}" style="padding:0.15em 0.4em 0.3em;font-weight:bold;{{{belowstyle|}}}">
{{{below}}}</td>
     </tr>
    }}<!--

...because when border lines above and below the "below" line have been specified, I keep finding the need to set this padding in order to position the line halfway between them (i.e. in a balanced fashion).

CsDix (talk) 05:11, 27 February 2013 (UTC)

Examples? Have you checked that this doesn't have an adverse effect on other sidebars? Declining for now. Chris Cunningham (user:thumperward) (talk) 12:16, 27 February 2013 (UTC)
...I've provided a link to links that include examples, so please don't deactivate the edit request. CsDix (talk) 00:57, 1 March 2013 (UTC)
What you've done is link to your contibutions history, which contains a wide assortment of recent sidebar edits, some of which are being openly disputed on your talk. If you're not able to provide concrete examples of the problem, it's unlikely that a passing admin will decide to take you up and make a change that will alter the appearance of up to 66,000 articles. So this will sit in the CAT:EP queue (already backlogged and under-monitored) indefinitely. It's your call. Chris Cunningham (user:thumperward) (talk) 10:09, 1 March 2013 (UTC)
Here's one (via looking at template edits whose summaries included "below"). Feels like too small a tweak to bother with now, though. CsDix (talk) 18:36, 1 March 2013 (UTC)

More sophisticated default width setting?

Hello again. Is it possible to set a default width that's more sophisticated than simply "width:Xunits"? What I have in mind is "width:18.0em" combined with "width:auto" – in other words, "18.0em but a bit more if Wikipedia's automatic link-bolding means that 18.0em is exceeded slightly".

18.0em is less than the current "non-bolding-sensitive" 22.0em, as 22.0em is a bit wide on smaller screens (e.g. 1024 by 768 resolution) or in smaller windows, so that reduction would also form part of my edit request. (Why 18.0em? It seems to work satisfactorily in said resolution and I've seen it's also used as the default width for sets of Sidebars, e.g. on political topics.)

CsDix (talk) 18:13, 16 February 2013 (UTC)

the default should probably be the same as {{infobox}}, don't worry about "hanging dots", and let the content naturally fill the box, since the precise appearance is browser dependent anyway. Frietjes (talk) 18:10, 17 February 2013 (UTC)
It looks like Infobox's default width is also 22.0em, so I'd suggest that drops to 18.0em as well. (If not, perhaps 20.0em is the compromise to use..?)
As regards the hanging dots, pages' precise appearance may ultimately depend on each browser and its set-up, but I don't feel that's good (enough) reason not to try to avoid them. It's a pity when (well-designed) vertically-orientated things such as sidebars are marred by horizontal things (such as the dots in hlists) that have been left unmanaged.
CsDix (talk) 23:02, 17 February 2013 (UTC)
by removing the "hanging dots" you split one list into two, when semantically it should be one list. you don't like the hanging dots, but if there is a dot between A and B, but no dot between B and C, then basically says that A and B are part of a group, but B and C is not. this is the set equivalent of saying { {A, B}, {C} } when you mean { A, B, C } . Frietjes (talk) 16:40, 18 February 2013 (UTC)
Okay, so is there a way to make the hanging dots invisible but still there for the sake of the semantics..? – or, rather, I can sense there should be one or more ways to accommodate this, but don't have the know-how (or clearance) to implement. Assistance, please..? CsDix (talk) 17:15, 18 February 2013 (UTC)
Alternatively, yes, {{A, B}, {C, D}...} isn't identical to {A, B, C, D,...}, but both form single sets with A, B, C, D,... in the correct order. What problem – presumably as regards accessibility? – does {{A, B}, {C, D}...} cause..? CsDix (talk) 17:23, 19 February 2013 (UTC)
they are part of a single list, by creating these subgroups, it indicates that there is a stronger connection between A,B than there is between B,C, which is simply incorrect (see your talk page). lists can be broken into sublists, but there has to be a reason for the subgrouping (e.g., subgrouped by decade). in addition, it has been pointed out that there are problems with forcing a particular location for the list break, since it is entirely browser dependent. as far as a personal solution for your browser, I would suggest asking at MediaWiki talk:Common.css or WP:VPT. it may be possible to do so with javascript, but I'm no expert in that area. Frietjes (talk) 17:39, 19 February 2013 (UTC)
What you are asking for is min-width and max-width 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:
{{ sidebar| name = Economics sidebar}}
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 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):

* {{hlist | [[Behavioral economics|Behavioral]] [[Cultural economics|Cultural]] [[Evolutionary economics|Evolutionary]]}},

which (with other sidebar formatting) would look like this:

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
<ul>
<li>item 1</li>
<li>item 2</li>
<li>item 3</li>
<li>item 4</li>
</ul>
all is well. if you see
<ul>
<li>item 1</li>
<li>item 2</li>
</ul>
<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 {{hlist}}s 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 |child=yes, in the same way that {{infobox}} supports |child=yes. the code is in sandbox2 (it looked like the main sandbox was in use). an example is presented in Template:Sidebar/testcases#Embedding. 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 {{infobox}} (i.e., have it not output the leading <tr> and <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 ―Œ(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#Embedding. Frietjes (talk) 13:58, 25 May 2013 (UTC)
Done! Plastikspork ―Œ(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":

> <div class="noprint">blub noprint</div>

As an example Template:Navbar is constructed with <div class="noprint"> 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#Full blank syntax for all supported parameters. — Edokter (talk) — 09:49, 9 June 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Sidebar/Archive_3&oldid=711975598"