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.
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.
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)
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)
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)
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 – 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)
.jpg?lang=en)
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)