Module talk:Sidebar Archive 4

This is an archive of past discussions about Module:Sidebar. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

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 – see e.g. {{History of science sidebar}}'s recent history – ~~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}}:

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. -- [[User:Edokter]] {{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 Wikipedia, 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. -- [[User:Edokter]] {{talk}} 19:44, 14 August 2014 (UTC)

But, like I suggested, don't sidebars and infoboxes etc already use margin/padding settings (from Common.css or elsewhere)..? Sardanaphalus (talk) 21:57, 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 – and neither start a line with a dot rather than a link – ? 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)

Can you recommend what should be messed with in order to prevent that kind of output, please? Sardanaphalus (talk) 14:59, 25 August 2014 (UTC)

You can't, and I explained why. If a horizontal list wraps at that particular point, the bullet may end up on the next line. You can see this behaviour more clearly at User:Edokter/sandbox#Wrap test while resizing your window. -- [[User:Edokter]] {{talk}} 17:02, 25 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 – or can be treated as if they are – 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. -- [[User:Edokter]] {{talk}} 18:46, 27 August 2014 (UTC)

Now I think I'm starting to get some insight into this situation – thank you, with apologies not to've caught the above earlier. Wouldn't increasing the margins/padding result in fewer mis-wrappings, though..? Sardanaphalus (talk) 00:10, 1 September 2014 (UTC)
No. In specific cases, they'd help, but in just as many other cases, they'd be the cause of the problem. Jackmcbarn (talk) 01:32, 1 September 2014 (UTC)

Template-protected edit request on 19 September 2014

This edit request to Template:Sidebar has been answered. Set the |answered= 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 list[N]name to match expanded exactly if list[N] is to be shown expanded. Can someone with the Lua know-how make this requirement case-insensitive, please – not least because a few of these templates I've passed by previously seem to've been set up as if it is – ? 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. -- [[User:Edokter]] {{talk}} 09:09, 16 October 2014 (UTC)

Isn't case-insensitivity a norm (conventional) in at least some of Wikipedia'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. -- [[User:Edokter]] {{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 – and if being "consistent" is that important – 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 – would it be much if any more demanding than another function such as #if:? – 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 to Module:Sidebar has been answered. Set the |answered= 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^talk 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. -- [[User:Edokter]] {{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^talk 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. -- [[User:Edokter]] {{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^talk 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... -- [[User:Edokter]] {{talk}} 19:42, 14 November 2014 (UTC)

We shouldn't implement this obsolete tags, since Wikipedia 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. -- [[User:Edokter]] {{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. -- [[User:Edokter]] {{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^talk 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[1] 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. -- [[User:Edokter]] {{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)
(i.e. so code such as below left rather than below right may be used:)

   {{Sidebar
   | name = ......
   | class = plainlist

   ............

   | heading1 = ......
   | content1class = hlist
   | content1 = ......

   | heading2 = ......
   | content2 = ......

   | heading3 = ......
   | content3 = ......

   | heading4 = ......
   | content4class = hlist
   | content4 = ......

   | heading5 = ......
   | content5 = ......

   (etc)

   }}

  {{Sidebar
  | name = ......
  | class = plainlist

  ............

  | heading1 = ......
  | content1 = {{startflatlist}}
  ......
  {{endflatlist}}

  | heading2 = ......
  | content2 = ......

  | heading3 = ......
  | content3 = ......

  | heading4 = ......
  | content4 = {{startflatlist}}
  ......
  {{endflatlist}}

  | heading5 = ......
  | content5 = ......

  (etc)

  }}

I've just realised that listNclass is available for {{Sidebar with collapsible lists}}, yet, as above, the corresponding contentNclass doesn't appear to be available for {{Sidebar}}. Can the latter be tweaked accordingly, please..? Sardanaphalus (talk) 23:21, 26 January 2015 (UTC)

header padding is inconsistent

See the Discrimination sidebar at Genocide for example. The first header is noticeably smaller than the second header, at least in regard to the part that is colored. Could someone fix this? Kaldari (talk) 18:40, 29 April 2016 (UTC)

Kaldari, the problem is that one is a collapsible list title and the other is a header. the collapsible list titles have an inner collapsible div which includes the colouring, where the headers just use standard table headers. I added a hack to correct for the difference, but it would be better if the collapsible div containers filled the entire table cell. Frietjes (talk) 18:58, 29 April 2016 (UTC)

something like this would also fix it by removing the left/right padding from the table cell container. Frietjes (talk) 19:17, 29 April 2016 (UTC)

Either solution is fine with me. Thanks! Kaldari (talk) 22:11, 29 April 2016 (UTC)

Latest edits screwed up many sidebars

for example, the sidebar in Politics of Angola has bad margins and the embedded content is the wrong size. Frietjes (talk) 00:17, 3 June 2017 (UTC)

Stripped-tag errors

Code like

{{sidebar
| title = Top level title
| content1 = {{sidebar
  | child = yes
  | title = First subsection
  | heading1 = Heading 1.1
  | content1 = Content 1.1
}}
| content2 = {{sidebar
  | child = yes
  | title = Second subsection
  | heading1 = Heading 2.1
  | content1 = Content 2.1
}}
|belowstyle = 
|below = Below text
}}

produces stripped-tag errors <th>. Maybe this is caused by a line in Module:Sidebar like

:wikitext('</th></tr>') -- @todo replace this with unclosed again once mw.html gets it

--RolandUnger (talk) 05:55, 25 July 2017 (UTC)

Module:InfoboxImage tracking

I'm wondering if there is a way to import some of the logic from Module:InfoboxImage into this module. Specifically the tracking that is done with Category:Pages using infoboxes with thumbnail images. Would be awesome to get a Category:Pages using sidebars with thumbnail images. Anyone have thoughts on the matter? --Zackmann08 (^{Talk to me}/_{What I been doing}) 16:41, 19 September 2017 (UTC)

Module talk:Sidebar/Archive 4