Misplaced Pages

Module talk:Sidebar

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

This is an old revision of this page, as edited by Sardanaphalus (talk | contribs) at 10:40, 18 January 2015 (→contentNclass: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 10:40, 18 January 2015 by Sardanaphalus (talk | contribs) (→contentNclass: new section)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

Archives
Archive 1Archive 2Archive 3
Archive 4Archive 5Archive 6

This page has archives. Sections older than 90 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.

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 Misplaced Pages'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 Misplaced Pages. 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 | ] ] ]}},

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 Suck. 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 hlist 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

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

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 ―Œ 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 ―Œ 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)

margin-right:0.5em to help browsers wrap hlists (more) reliably

Increase left+right padding/margin to help browsers wrap hlists more reliably?

It appears that a margin-right:0.5em  Adding some left+right padding/margin reduces or removes errors when hlists wrap within Sidebars<aside>see e.g. {{History of science sidebar}}'s recent history</aside>so could someone speaking Lua please add the equivalent of the following to this module..? Sardanaphalus (talk) 14:10, 13 August 2014 (UTC)
PS I think this might resolve much in the above.

@Sardanaphalus: I don't quite see what this would fix. Can you post a side-by-side demo of what it would do? Jackmcbarn (talk) 16:29, 13 August 2014 (UTC)
  • I couldn't find where the glitches have been demonstrated before, so here is a quick example of one using part of {{History of science sidebar}}:
Without liststyle=margin-right:0.5em;
Mathematics
With liststyle=margin-right:0.5em;
Mathematics
This kind of glitch can be exacerbated (or, if not already present, caused) if/when a link on the line leading to the faulty linewrap is bold. Sardanaphalus (talk) 21:40, 13 August 2014 (UTC)
That 'glitch' is only what you see; it depends entirely on the fonts being used on your system. When you apparently 'fix' the wrapping behaviour, you will introduce the error you are trying to fix on other people's systems. So please don't go adding margins and paddings in templates to make them look better, because it most likely only works on your system. -- ] {{talk}} 09:03, 14 August 2014 (UTC)
  • Right now, I'm using Palemoon (a Firefox-based browser) in Windows 7 on a PC, with no fonts replaced nor custom font settings for Misplaced Pages, Palemoon or Windows (nor, as far as I'm aware, non-standard zoom settings or the like). How is a slight increase in these areas' right-margins going to introduce this kind of error on other people's systems..? (Don't sidebars and infoboxes already use margin/padding settings that affect the righthand sides of their elements..?) Sardanaphalus (talk) 14:14, 14 August 2014 (UTC)
    • Like I said, it depends on system metrics such as fonts used and rendered size of the elements. Hlist wrapping is not perfect, it never will be. But again, what may look good on your system may look worse on others, therefor you should not 'fix' wrapping issues with margin or padding. Other infoboxes use standard CSS defined in Common.css and very little (if any) inline CSS, and then only if it cannot be done from Common.css. -- ] {{talk}} 19:44, 14 August 2014 (UTC)
I don't see any need for overriding the listtsyle/contentstyle for the Palemoon browser. I checked firefox on Windows 7, chrome on Windows 7, internet explorer on Windows 7, and firefox on Linux, and could see no difference in the two examples. Frietjes (talk) 13:51, 18 August 2014 (UTC)
  • That's interesting to hear. To make sure I'm not misunderstanding anything, you're reporting no difference in how the lists wrap in the "Mathematics" examples above<aside>and neither start a line with a dot rather than a link</aside>? Sardanaphalus (talk) 17:35, 18 August 2014 (UTC)
PS Do you ever see any listwrapping malfunctions such as the above? Sardanaphalus (talk) 09:26, 20 August 2014 (UTC)
I see no malfunction, so, I don't know how to respond to your question. you should upload a screenshot if you want help with fixing your problem. Frietjes (talk) 15:55, 23 August 2014 (UTC)
  • Here's a screenshot of what I see:
Sardanaphalus (talk) 10:06, 24 August 2014 (UTC)
Is the problem that one line starts with a dot for you? If so, messing with padding/margin is absolutely the wrong way to fix it. Jackmcbarn (talk) 15:19, 24 August 2014 (UTC)
  • Words always seem to be wrapped correctly (i.e. each as a single, unbreakable unit – not, for example, as "Mathem
    atics"), so the explanation seems to be that the browser isn't being directed to treat the combination of word+nbsp+(bold?)dot as if it were still a word (i.e. a single, unbreakable unit). So far as I'm aware, however, the nbsp and (bold)dot are<aside>or can be treated as if they are</aside>characters like the letters in the word before them, so, if a string-of-characters is a word, I'm wondering why a string-of-characters-plus-two-more-characters can't be a word (which may then wrapped correctly)..? (If the dot does have styling such as bold applied to it, would that prevent it from being treated as a character?) Sardanaphalus (talk) 17:23, 27 August 2014 (UTC)
  • When horizontal lists (hlist) was introduced, list items were indeed non-wrapping, including the bullet. However, this resulted in unwanted behaviour in Internet Explorer which could not be fixed without introducing other bugs in other browsers... believe me, I spent months trying to solve it. In the end, the non-wrapping list items were abandoned and left to the browsers native wrapping behaviour. There is not going to be a solution for this, because hlist is not really a standard concept for browsers; we're basically trying to trick browsers to display regular lists as if the were regular text. The next iteration of HTML does have a specification for a native form of horizontal lists, but I have no idea how it handles wrapping. Until then, we will have to make due with our own imperfect version. -- ] {{talk}} 18:46, 27 August 2014 (UTC)

Template-protected edit request on 19 September 2014

This edit request to Template:Sidebar has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Siddrth.reddy (talk) 14:00, 19 September 2014 (UTC)

Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. Jackmcbarn (talk) 14:17, 19 September 2014 (UTC)

Edit request (affecting Template:Sidebar with collapsible lists)

Currently, I think {{Sidebar with collapsible lists}} requires a listname to match expanded exactly if list is to be shown expanded. Can someone with the Lua know-how make this requirement case-insensitive, please<aside>not least because a few of these templates I've passed by previously seem to've been set up as if it is</aside>? Sardanaphalus (talk) 18:15, 15 October 2014 (UTC)

This would make it inconsistent with all the other collapsible boxes which use lowercase expanded exclusively. There is also collapsed - both of these are used as class names for the styling of the page, and in style sheets the class names are case-sensitive. Except probably in Internet Explorer. --Redrose64 (talk) 19:50, 15 October 2014 (UTC)
Redrose64 I think you misread the question. basically, the request is equivalent to this change (which is impossible to read, but search for 'lc:'). Frietjes (talk) 21:36, 15 October 2014 (UTC)
a change like this should do it. Frietjes (talk) 21:44, 15 October 2014 (UTC)
@Sardanaphalus: What would the benefit of such a change be? We want to make wikitext be more consistent, not less. (I also think we should undo that part of the navbar change for the same reason.) Jackmcbarn (talk) 00:51, 16 October 2014 (UTC)
I agree; consistent parameter conventions are preferred, and where ambiguity exists, those should not be propagated. -- ] {{talk}} 09:09, 16 October 2014 (UTC)
Isn't case-insensitivity a norm (conventional) in at least some of Misplaced Pages's other aspects/functions..? Sardanaphalus (talk) 10:13, 16 October 2014 (UTC)
No, it isn't. Template/module parameters have always been case-sensitive. The only case where parameters are made case-insensitive is where backward compatibility is (temporarily) required. -- ] {{talk}} 11:59, 16 October 2014 (UTC)
An immediate benefit would be that the list-expanding feature in those templates set up as if list-naming is case-insensitive would then work. More significantly, though (I think), it'd be some flexibility/accommodation for people trying to use the feature. After all, if I've understood their purpose correctly, list names are used to implement the feature because list titles could over-complicate and/or break it..? Sardanaphalus (talk) 10:13, 16 October 2014 (UTC)
looks like there is no consensus for this change, or for the corresponding change to {{navbox with collapsible groups}} so I will change that one back to match this one for consistency, as suggested above by Jackmcbarn. Frietjes (talk) 14:51, 29 October 2014 (UTC)
Where is the consensus against this change..? Above, there appears to be a misunderstanding and a suggestion without response. Perhaps it's not clear that there's nothing more to this than allowing both e.g. {{templatename |Sectionname}} and {{Templatename |sectionname}} achieve the same result – a flexibility not without precedent..? Sardanaphalus (talk) 16:43, 30 October 2014 (UTC)
The problem is that there's no clear benefit to that, but it makes the code bigger, more complicated, and (slightly) slower. Edokter, Frietjes, and I all mentioned that. Jackmcbarn (talk) 20:35, 30 October 2014 (UTC)
The clear benefit is to people trying to use the feature; people who should not be assumed to have a programmer-like mind-set. If it's such a problem<aside>and if being "consistent" is that important</aside> then the use of templates' names, articles' names etc should also be required to be case-sensitive (names, not labels). Sardanaphalus (talk) 00:04, 31 October 2014 (UTC)
They are, except for the first character. Jackmcbarn (talk) 02:27, 31 October 2014 (UTC)
But the same not okay for these section names..? Sardanaphalus (talk) 09:16, 31 October 2014 (UTC)
The MediaWiki software is case-sensitive except on first letter for all pagenames, whether they be articles, templates or anything else; to introduce case-insensitivity for these involves the creation of redirects, and there is no speed penalty for these.
The software cares little about the casing of section headings when these form part of a link, because that aspect is handled by the browser. Most browsers are case-sensitive with links to sections, but Internet Explorer is not.
The MediaWiki software is fully case-sensitive for the names of template parameters; to introduce case-insensitivity for these involves the creation of aliases, which slows down template processing, particularly for longer parameter names, since every possible permutation needs to be coded. For example, if the parameter passed to a template is called |ab=, which is coded inside the template as {{{ab|}}}, to make that case-insensitive would need code like {{{ab|{{{aB|{{{Ab|{{{AB|}}}}}}}}}}}} and every extra letter doubles the length of the test.
The software is also fully case-sensitive for the values of template parameters, but in such cases it is relatively easy to add code to make the value case-insensitive - parser functions like {{lc:}} may be used; but again, these add to the processing time. This is not always a good idea to implement: when several different templates have similarly-named parameters with identical purpose, it is good practice for them to recogise the same values as each other, in order to avoid the confusion that will result if one behaves differently from the rest. --Redrose64 (talk) 15:08, 31 October 2014 (UTC)
  • "...parser functions like {{lc:}} may be used; but again, these add to the processing time..."
If something like {{lc:}} would demand too much time or resources<aside>would it be much if any more demanding than another function such as #if:?</aside> then perhaps {{Sidebar with collapsible lists}} (and {{Navbox with collapsible groups}}, etc)'s instructions could direct people to use lowercase only for list/group names? I think that might reduce the chances of people who try to use these templates' feature thinking that it's a good idea to use names that duplicate titles (and perhaps draw attention to why names are used rather than the lists/groups' titles). Or maybe there is a different approach to managing these collapsible lists/groups/etc that is more robust..?
Thanks for your feedback, Sardanaphalus (talk) 22:10, 1 November 2014 (UTC)
Really lc is very cheap. It makes for forgiving templates. All the best: Rich Farmbrough, 03:11, 10 November 2014 (UTC).
Approx a millionth of a second at render time. Which is very much more than it should be, but still negligible. All the best: Rich Farmbrough, 04:03, 10 November 2014 (UTC).
In perl, on my 5 year old PC, it is approx. 150 times faster... All the best: Rich Farmbrough, 04:21, 10 November 2014 (UTC).

Template-protected edit request on 31 October 2014

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please replace the cellspacing attribute on the table with an appropriate CSS. There're still some obsolete atributes, including cellspacing. See the error list, thank you in advance! See Template_talk:Infobox#Protected_edit_request_on_30_October_2014 for more info. Rezonansowy (talk | contribs) 21:17, 31 October 2014 (UTC)

@Mr. Stradivarius: Could you fix this, please? --Rezonansowy (talk | contribs) 11:32, 11 November 2014 (UTC)
There are two obsolete attributes:
  • .attr('cellspacing', args.cellspacing or 5)
  • .attr('cellpadding', args.cellpadding or 0
--  Gadget850 15:16, 14 November 2014 (UTC)
Note that any CSS should go in Common.css (if not already there); generic inline CSS should be avoided. -- ] {{talk}} 15:42, 14 November 2014 (UTC)
@Gadget850 and Edokter: Should we implement this same like in Template:Infobox? --Rezonansowy (talk | contribs) 16:10, 14 November 2014 (UTC)
I have a similar request at Template talk:Navbox#HTML. I would like to understand what Edokter is proposing. I have noted some similar fixes, but if we should be doing this differently... --  Gadget850 18:24, 14 November 2014 (UTC)
The obsolete attributes do not need replacing per se; they were there to support older browsers. I think the necessary CSS is already in place. The only thing I wanted to point out is that the removed attributes should not be replaced by inline CSS. -- ] {{talk}} 19:00, 14 November 2014 (UTC)
Which older browsers? I believe support for older versions of IE has been dropped in MediaWiki recently. --  Gadget850 19:10, 14 November 2014 (UTC)
Probably IE6/7 that did not understand 'advanced' table CSS. We didn't necessarily 'drop support'; we did disable JavaScript for these browsers. But that is pretty much the same... -- ] {{talk}} 19:42, 14 November 2014 (UTC)
We shouldn't implement this obsolete tags, since Misplaced Pages switched to HTML5, some tags are obsolete and incorrect. See our discussion on Village pump. We're going to fix this. --Rezonansowy (talk | contribs) 22:47, 14 November 2014 (UTC)
Just had a look... all CSS is inline! That should be remedied soon. In the mean time, I've removed the obsolete attributes. -- ] {{talk}} 19:47, 14 November 2014 (UTC)
@Edokter: Note that currently, template editors can change the CSS that this uses. If it were all in common.css, only admins could. I think we'd need to give that some serious consideration before dumping it all into common.css. Jackmcbarn (talk) 21:31, 14 November 2014 (UTC)
That is not much of an argument. It is common practice to put common CSS in Common.css. Module-generated CSS is unmanagable and very hard to test. Inline CSS may also present problems in Mobile, so all in all, inline = bad. -- ] {{talk}} 21:40, 14 November 2014 (UTC)
Now that I see how this works (I'm still figuring out Lua), I agree with Edokter. It is not that difficult to get Common.css updated. --  Gadget850 22:13, 14 November 2014 (UTC)

"child" handling

Hello – could the code be amended, please, so that it can handle {{Sidebar |child as {{Navbox}} handles {{Navbox |child?
I suspect a line such as border = trim(args.border or args or '') (from Module:Navbox) will be needed somewhere, but, in lieu-a of learning Lua, that's about as far as my guessing extends.
Sardanaphalus (talk) 12:31, 13 January 2015 (UTC)

PS The same modification for {{Infobox}} as well..?

{{infobox}} already does this, with the |child=yes parameter. --Redrose64 (talk) 14:27, 13 January 2015 (UTC)
But can it handle {{Infobox |child ..? Sardanaphalus (talk) 00:26, 14 January 2015 (UTC)
No, it does not support unnamed parameters. -- ] {{talk}} 01:14, 14 January 2015 (UTC)

contentNclass

There's content1style, content2style etc, but not (so far as I can see) content1class, content2class, etc. Since, for example, the lists supplied as a Sidebar's contents are not necessarily all "hlist" or all "plainlist" in nature, could these parameters be included, please? Sardanaphalus (talk) 10:40, 18 January 2015 (UTC)