MediaWiki talk:Common.css/Archive 13

This is an archive of past discussions. 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 10

Archive 11

Archive 12

→

Teletype style fix for Chrome (redux)

As a continuation of the above linked discussion, I would like to make a small change to the code in Common.css and Geshi.css. As the current code (font-family: monospace, sans-serif;) is sematically incorrect (sans-serif is not monospaced), and could possibly result in the wrong font being displayed (not likely, but still), I would like to replace it with font-family: monospace, "Courier New";. As the 'trick' works with any font specified as the second parameters, this would make more sense. They have this fix working on the German Wikipedia. I also requested this be implemented in Bugzilla:20706, where the old code is already committed, but is still opened. — Edokter • Talk • 15:49, 8 November 2010 (UTC)

It seems the fonts have already been swapped in a later revision (see Bugzilla). I'll adapt the temporary fixes. — Edokter • Talk • 16:38, 8 November 2010 (UTC)

Zebra striping, again

Sensing that the discussion of background-color is not quite over, I'd like to raise the related issue of optionally zebra striping tables. This has been on-offer before:

.wikitable.zebra tr:nth-child(odd) {
  background-color: #f5f5f5;
}

The above #f5f5f5 is half-way between the data-cell-#f9f9f9 and the header-cell-#f2f2f2. This is, admittedly, a narrow range, but it's driven by the bedrock wikitable-colours. I'd be open to another styling for the zebra-rows, such as a dotted border or background, which DGG suggested, recently. Also, for some tables there will be no header-row, so they'll have data in row-one, not header-cells. There's a mock-up of this in the archive 12 example. I'd also be open to keying-off 'even' instead of 'odd'. Please do note that the stripping goes all-off if rowspans are used to omit some of the data cells. Cheers, Jack Merridew 23:10, 9 November 2010 (UTC)

Cool, but limited in its application. If there were some mechanism that would allow editor to choose the colors, I'd be all for it. But now, there is only one option: what this CSS tells it (unless we provide several classes for different color schemes). Also, I would not choose an intermediate color between the two current grays, but just make the odd rows plain white, which makes it blend in more with the page. — Edokter • Talk • 23:34, 9 November 2010 (UTC)

.wikitable.zebra tr:nth-child(odd) {
  background-color: #ffffff;
}

There are a fair number of tables out there doing this sort of thing with inline-css and there's also some disabled javascript out there that adds class="even" and class="odd" to table-rows and if it can be re-enabled, we could key-off that rather than using CSS3 (but I am *fine* with not supporting dead browsers).

I'm not in favour of canned colours for the tv-fans to pick from; that's all about gratuitous ornamentation. The white's a good idea, and I've just previewed a test via my user css. It is of limited use, and we'd need some guidance on appropriate use, but think it a good alternative to all the inline code trying to achieve the same sort of effect. Cheers, Jack Merridew 00:55, 10 November 2010 (UTC)

I'm testing Wikipedia editing with my new IPad, apart from a scrollbar bug, everthing is fine :-)

I support the zebra proposal. And I agree with Jack, allowing several color would result in a chrtistmas tree design (lots of fancy colors used in a way that would not be consistent and makes it look messy). Edokter's white odd rows proposal looks really good, seems like a sensible design choice. Dodoïste (talk) 22:58, 10 November 2010 (UTC)

Hide rollback link from watchlist

Should we add:

.page-Special_Watchlist .mw-rollback-link {display:none;}

to this page, which will hide rollback links from the watchlist? I can hardly imagine anyone actually wanting to rollback something from their watchlist, and people very often accidentally use this feature. See User talk:SandyGeorgia#Eyeglass fund. Ucucha 21:41, 7 November 2010 (UTC)

Support totally. I can't think of any reason one would ever want to revert an edit direct from their watchlist without looking to see what it was, and I know from experience it's very easy accidentally to hit that button, a problem which will only get worse with the spread of touchscreen devices. – iridescent 21:48, 7 November 2010 (UTC)

(ec) If people really want the rollback link, they will be able to reinstate it using

.page-Special_Watchlist .mw-rollback-link {display:inline; !important}

in their personal CSS. Ucucha 21:49, 7 November 2010 (UTC)

Weak oppose. I frequently rollback from my watchlist and I'm sure I'm not the only one, so I feel it should be up to those who want rid of it to change their personal settings rather than change the status quo. HJ Mitchell | Penny for your thoughts? 22:02, 7 November 2010 (UTC)

Oppose. What HJ said... Although I rarely use it, there are editors who do. — Edokter • Talk • 22:14, 7 November 2010 (UTC)

Strong oppose Use it all the time, for blanking (obvious) and trolling (disruptive edit summaries are a telltale sign) Access Denied – talk to me 22:30, 7 November 2010 (UTC)

Oppose. I don't recall ever using this feature intentionally (and two instances of accidental use led me to remove it via the above code), but others do (and it's easier to seek out a means of removal than it is to add something that one might not even realize is an option).

I would, however, support making the code's availability more obvious (for the benefit of those who choose to remove the feature). Would it be feasible to add it to the list of "user interface gadgets" (despite the fact that it applies only to accounts with the rollback function enabled)? —David Levy 16:58, 8 November 2010 (UTC)

I think it would be possible. We can make MediaWiki:Gadget-hiderollbackfromwatchlist.js with text importStylesheet("MediaWiki:Hiderollbackfromwatchlist.css"); and put the line of CSS I gave above in that .css file. Ucucha 23:03, 10 November 2010 (UTC)

increase default font-size to 10.5 pt

I would suggest increasing the standard font size to 10.5 pt. The current font size strains my eyes a little. The 12 pt suggested by the usability project is too big IMHO but I think 10.5pt is a good middle ground. Access Denied – talk to me 00:29, 14 November 2010 (UTC)

I don't think 10.5pt is a legal CSS value (pt must be integer?). Besides, the base font size is set per skin and not in Common.css. For Monobook, it is x-small times 127% (don't ask), and for Vector it is simply 0.8em, which is 80% of 16pt (browser default for sans-serif), which equals 12.8pt. 10(.5)pt or 11pt would make it even smaller. I would have to say no to this proposal. — Edokter • Talk • 00:47, 14 November 2010 (UTC)

Oh, just realized that my browser settings are the problem. Never mind. Access Denied – talk to me 00:53, 14 November 2010 (UTC)

So when I argue over at WT:DISCOGSTYLE that 75% is too small for a column heading (because it's 25% smaller than a user's preferred font size), and that 90% would be better (despite the "fact" that it's 10% smaller than the user's preferred size), I'm really arguing that Vector skin users will still see it as 90% of 80% of their preferred (or at least default, expected) size? So it's still really 72% of the default size for standard text, and that's for a <th> column heading. Sheesh.

There appears to be no restriction about real numbers (with fractional parts, I mean) for length units in CSS2 or CSS3. That doesn't mean the difference is actually detectable, though, since some de facto rounding occurs to match the equipment's display capabilities. — JohnFromPinckney (talk) 11:50, 14 November 2010 (UTC)

Note that there is no CSS that chanegs font size in tabels or headers, so I am curious as to what this debate is about. But yes, you are correct that 90% in CSS means 90% of 0.8em (0.8em having the same effect as 80%). When using smaller font sizes, we should never go below 85% in CSS. — Edokter • Talk • 13:24, 14 November 2010 (UTC)

Vertical alignment in wikitables

To me, it seems most tables on Wikipedia would look better if they had style="vertical-align:top" by default on all table rows. I'll concede that some would look nicer with the current default middle-alignment (especially if any of the cells have center-alignment horizontally), but it would IMO be an improvement for most tables, especially ones where emphasis on making the table look nice has not been a priority. Further, this should improve legibility. Take for example this table, where the bottom table row that fits in my browser window until I scroll is the entry for Rachel Getting Married, except that I cannot see this text until I scroll, although I can see almost eight lines of text in another column. It seems to me that the accessibility would be improved if the first content in each column in a row was visible at the same vertical height in the article, as people tend to read articles vertically. I tried to search for previous discussion on this, but came up empty, surprisingly. Does everyone else think the current default vertical alignment is great? --Mepolypse (talk) 01:12, 5 December 2010 (UTC)

Fundraising page addition

Hey guys,

Just a quick note to explain this addition . The Fundraising team is doing a small scale test on Wikipedia:Keep It Free. One of the things we're testing is the effect of hiding the sidebar and interface (other places you could click). At the moment this is a very small scale test (that isn't live yet). Jalexander--WMF 01:15, 11 December 2010 (UTC)

Requesting the addition of a class "transborder"

/* Pie chart test: Transparent borders */
.transborder {
    border-color: transparent;
    border-style: solid;
}
* html .transborder {  /* IE 6 */
    border-color: #000001;
    border-style: solid;
    filter: chroma(color=#000001);
}

I have created the template {{Pie chart}} for use in articles. (Check what links here for some discussions about other possible other options.) As far as I can tell, I have managed to get the template working in all major browsers, except one: IE 6 lags behind the others in CSS support, namely that transparent borders do not work in that browser. Here's a fix I came up with and tested; although it's not 100% valid CSS because of the filter: line, that is likely the only possible workaround. Could we apply this to Common.css so that this new template can be used in articles soon? PleaseStand ^(talk) 04:03, 11 December 2010 (UTC)

Done. Let's see where this goes. — Edokter • Talk • 14:24, 11 December 2010 (UTC)

Autowrap in preformatted text boxes

From my monobook.css:

pre {
 white-space: pre-wrap;       /* css-3 */
 white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
 white-space: -pre-wrap;      /* Opera 4-6 */
 white-space: -webkit-pre-wrap;      /* WebKit browsers */
 white-space: -o-pre-wrap;    /* Opera 7 */
 word-wrap: break-word;       /* Internet Explorer 5.5+ */
}

This covers all major web browser and would stop the annoying situation of scrolling horizontally back and forth to read complex lines of code. Can't see any problems coming out of it. access_denied (talk) 03:16, 16 December 2010 (UTC)

I agree that preformatted text should allow linebreaks to prevent the horizontal scrolling (but other might disagree). Sidenote: only white-space: { pre-wrap; } is needed; it's CSS1 and all browsers support it. Also, word-wrap only works when white-space is set to normal; it has no effect in your code. — Edokter • Talk • 11:59, 16 December 2010 (UTC)

I do disagree, or at least don't think that this should be applied to GeSHi code snippets, where odd linebreaks can be extremely confusing. I do agree that the extend-a-whole-paragraph-onto-one-incredibly-long-line-because-someone-added-a-leading-space phenomenon is irritating, but if we can target that scenario specifically, that would be much better. Happy‑melon 18:07, 18 December 2010 (UTC)

We have in the past considered setting overflow:auto on pre's right? There are some issues with IE, which draw the bars at the inside of the content div. Adding a bit more padding on IE to make sure there is enough space for the scrollbar, might be an idea. bugzilla:414 and bugzilla:22060. I dislike setting wrapping, because pre is behaving like it does for a reason. Linebreaks are not always appreciated if you are using pre. —TheDJ (talk • contribs) 12:15, 19 December 2010 (UTC)

Light blue coloring of click-accessed <References /> items

The light blue coloring of click-accessed <References /> items has APPARENTLY recently stopped working. Wtmitchell (talk) (earlier Boracay Bill) 22:53, 22 December 2010 (UTC)

Yes— just saw a comment at Template talk:Reflist and came here to check. ---— Gadget850 (Ed) ^talk 00:55, 23 December 2010 (UTC)

Fixed here. — Edokter • Talk — 01:07, 23 December 2010 (UTC)

Side question for CSS geeks: Wouldn't simply li:target suffice in this case? I cannot imagine any other list items on articles actually being linked to. — Edokter • Talk — 01:14, 23 December 2010 (UTC)

I've seen weirder coincidences occur. Better be on the safe side. :D —TheDJ (talk • contribs) 10:32, 25 December 2010 (UTC)

Navbar font size

Copied from Template talk:Navbar#Font size (again)

The v-d-e links are too small; they push the limit on how small the letters can be. They are inelligable and require a steady hand to click on. This has been a pet peeve of mine for a long time. It doesn't help that the fontsize is defined inline, and then even further reduced when used in a template such as {{navbox}}. I have been experimenting in the sandbox and need input. My proposal is to use a font-size of 88% (same size as used in navbox) and ensuring it stays that way by putting the following code in common.css, and removing the hardcoded font sizes from the template:

.navbar {             /* Navbox template links */
    font-size: 88%;   /* Default font-size */
    font-weight: normal;
}
.navbox .navbar {
    font-size: 100%;  /* When nested within navbox */
}

At the same time, I changed the <small> bullets to <bold> middots and condensed the whole by reducing their letter-spacing by .1em. I also changed all the divs to spans, as I cannot see the advantage of using divs and have not seen any breakage where spans are used. This means we can eliminate nodiv=1 as well.

I have already put the code in Common.css; since the font size is hardcoded in the template, this code has no effect on the live template, but does work for the sandbox version. The effects are viewable in Template:Navbox/testcases. This should give us enough time to discuss, and possibly make it live in 30 days. — Edokter • Talk • 17:21, 7 December 2010 (UTC)

No objections from me. Seems like a sane idea. Kinda surprised it wasn't in Common.css before. —TheDJ (talk • contribs) 22:24, 7 December 2010 (UTC)

Any reason more styles couldn't be moved out of the template and into Common.css? Other than that, this looks pretty good. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 02:18, 8 December 2010 (UTC)

Good point... no reason at all. I'll move it. — Edokter • Talk • 02:56, 8 December 2010 (UTC)

Cleaned up some redundant code in the process, not much left to move but font-weight. — Edokter • Talk • 03:10, 8 December 2010 (UTC)

These are welcome changes.

Making "nodiv=1" superfluous is appreciated; it was a long journey to discover that nodiv-switch.
Do I understand correctly (could not find it in code) that within the v-d-e text you swith style re the bullet/middot? I'd say negative. In general: if you use a fontstyle, don't change style halfway, please. That is for the ease of my eye, and readability.
in code I saw the error-message "ERROR: No name!". Could that be more helpful (and less alarming!!!) like "Error using {{navbox}}: no template name entered".
In the sandbox testcases, today, I seem to miss some space between bullet--e (Firefox on XP). Probably a visual effect, not the facts?

-DePiep (talk) 22:21, 27 December 2010 (UTC) Corrected my text, saved one check too early -DePiep (talk) 22:26, 27 December 2010 (UTC)

2. No, there is no style change; the middots are wrapped in their own span that reduces their spacing by .1em, in addition to the regular styling passed with {{{fontstyle}}}.

3. That is too long. The message is constrained by space. Besides, the name is essential, so the error should be alarming. :)

4. There is space, but perhaps slightly unbalanced, which is always a problem with small fonts. — Edokter • Talk — 22:46, 27 December 2010 (UTC)

2. Well, reducing their spacing is a style change, innit? And didn't you write above: "I changed the <small> bullets to <bold> middots and ...". Imo, if one needs a font-style-construction to get a readable result, the general goal should be reconsidered (probably a bigger font-size here. Even width-in-pixels was an argument in an old t-versus-d talk here).

3. By writing "alarming!!!" I meant to say that when using an exclamation mark, the user is not helped at all. An alarmed user (editor) wants to know what to do, or where to look (for). Is what I call usefull error-messages. Of course a wikilink is very good, in limited space. But I must say, no big deal of trouble for me. -DePiep (talk) 23:09, 27 December 2010 (UTC)

(←) In the current template, the big bullets have their font-size reduced by 80%. In the new template, I have replaced the bullets with bold middots and actually removed the font-size reduction, to get the same size dots as before. So that should be an improvement using less styling. The middots do have their spacing reduced, but not the links that surround them. The net result is that the links are one pixel closer to the middots, as you can see on the testcases page. I also tweaked the error a bit, so it should be more clear. — Edokter • Talk — 23:27, 27 December 2010 (UTC)

Header lines

I'm considering adding h2 { overflow:hidden }, so that the header lines will observe the margin of the thumbnails and we will have visual detachment between header lines and infoboxes/thumbs again. Anyone see any issues with doing that ? If successful, the change will go into the actual MediaWiki code. —TheDJ (talk • contribs) 13:18, 27 December 2010 (UTC)

Support!, and not because I couldn't care less about the lines touching the boxes, but it fixes the bunching problem! It should be applied to H1 through H6. In fact, I think I will file a bugzilla report for that. — Edokter • Talk — 15:00, 27 December 2010 (UTC)

Hmm, interesting side effect. Not that surprising actually, if you consider that the bunching problem is caused by the vertical starting height of the drawing boxes of both elements. It seems so logical in retrospect. The creds are all for Fomafix however :D. Tested on Opera, FF, Webkit, and by you on IE6 according to the bugreport. I'm adding this and let's hope it really does work as well as first results seem to indicate. —TheDJ (talk • contribs) 19:44, 27 December 2010 (UTC)

hid banners on contribution landing pages

Hey all, Just wanted to leave a quick note to let you know I added some code to hide the banner we're about to turn on (which ask anonymous editors to make their first edit) on the landing page that they go to. It was getting to confusing to have the banners they just clicked on also on top. diff. Jalexander--WMF 18:19, 7 January 2011 (UTC)

Would it make sense to just hide the banners on all project pages (Wikipedia: and Wikipedia_talk:)? After all they are technically internal pages. — Dispenser 19:22, 7 January 2011 (UTC)

Also added some code for our new landing pages. Sorry for the delay in responding Dispenser. I don't think they generally want to do that because some of the banners are explicitly directed at both internal and external people (for example the wikimania scholarships and wiki10 banners for logged in users) but I'll talk with the others. Jalexander--WMF 20:18, 11 January 2011 (UTC)

And removed Jalexander--WMF 20:39, 14 January 2011 (UTC)

Tranparent tables

For a long time, the plain table background was white, but this has changed to transparent in the upcoming 1.17 release of MediaWiki. Since there may be templates that rely on a white background, I'm putting the following code in, in order to spot any glitches that may pop up before 1.17 is deployed. I'm also posting this in WP:VPT. — Edokter (talk) — 21:05, 30 January 2011 (UTC)

/* Transparent table background. Remove when 1.17 is deployed */
table {
    background-color: transparent;
}

Pre-formatted (and GeShi) text finally fixed properly

I decided to sort out the whole mess regarding the preformatted text, after I was unsuccessfull in trying to assign a different monospace font in my skin CSS. The better part of the problem was an incorrect font declaration in Geshi.css, causing any custom CSS on <pre>...</pre> tags to fail; Geshi.css is loaded after all other CSS files, and was marked !important. Those declaration are now corrected (it now targets only the relevant GeShi elements) and have been moved to Common.css. It has become possible again to choose your own monospace font for <pre>...</pre>. Skinning the GeShi text requires an additional line, still requiring the !important; flag (see example).

Hunting down the root of the problem reveals that the GeShi extension is injecting unnecessary, hard-coded, inline font-family: monospace; tags into the HTML, necessitating the use of !important; in the first place. If that were to be fixed, the GeShi fix can be safely removed. Shall I file a big report? — Edokter (talk) — 19:59, 3 February 2011 (UTC)

Yes, make it really big.

Thanks for figuring this out. ---— Gadget850 (Ed) ^talk 20:05, 3 February 2011 (UTC)

Done: ~~Bugzilla:27145~~ Bugzilla:26204. — Edokter (talk) — 21:00, 3 February 2011 (UTC)

Ever since these changes, the tiny font problem is back for me on Firefox. – Acdx (talk) 11:15, 7 February 2011 (UTC)

I officially hate Firefox now. It should be fixed now. — Edokter (talk) — 12:48, 7 February 2011 (UTC)

Perfect, thanks! – Acdx (talk) 04:24, 9 February 2011 (UTC)

References again

Can the small font for references be removed. This is an accessibility issues. There is no need to use a small font, except to emulate paper, which WP is not. And yes I know I can fix my personal css (and have done so) but accessibility issues are not about me, users who have the ability or desire to modify .css files, or even registered users. They are about the millions of readers who struggle with smaller text. Rich Farmbrough, 16:03, 4 February 2011 (UTC).

You are most probably aware of these two discussions, which had overwhelming support for the smaller fontsize. I think this is best brought up on Wikipedia:Village pump (proposals). — Edokter (talk) — 16:42, 4 February 2011 (UTC)

And we now have Special:Preferences → Gadgets → Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists, whcih resolves the issue for a number of elements. ---— Gadget850 (Ed) ^talk 04:54, 5 February 2011 (UTC)

Gadgets ARE NOT THE POINT. Unregistered users with disabilities are the point! Rich Farmbrough, 22:23, 8 February 2011 (UTC).

Isn't it presumptuous to think that unregistered users with disabilities don't know how to press "command-shift-+" to increase the font size on their browser window? Sasata (talk) 20:55, 11 February 2011 (UTC)

Salsata, isn't it presumptuous to make presumptions about details of the sort of access environment from which users are accessing Wikipedia (e.g., that their keyboards include a "command" key, and that pressing that key in conjunction with the "shift" and "+" keys increases their displayed font size)?

Rich, the fact that people do tend to presume (always incorrectly) that the whole world is using whatever access environment they are personally accustomed to and to presume (usually incorrectly) that they know everything they need to know about operating in/from/with that environment does not place an obligation on others (WP in this case) to take special measures to deal with that.

The point is to decide what common-denominator-user to target the defaults for -- to decide where to draw the line in catering to special needs by imposing special-needs solutions on everyone (while being aware that the special-needs accommodations made will impact all non-special-needs anons using WP, and will not benefit special-needs anons elsewhere than in WP).

Personally, I think that it's reasonable to expect that most special-needs persons for whom this is an issue will have learned to cope with this if it is an issue for them (by using e.g., command-shift-+, or control-+, or control-and-mousewheel, or (clickpress)View->Zoom->Zoom-In(clickrelease), or (press Alt)VZI(release Alt), or whatever works with their individual access environment). I know that some won't have learned how to do that; I've taken the time to show a number of people about that sort of stuff myself, sometimes being thanked for my helpfulness and sometimes being told in no uncertain terms that my bothersomeness was distinctly unappreciated.

Gadget, thanks for the info about that Preferences gadget -- learn something every day. Wtmitchell (talk) (earlier Boracay Bill) 05:04, 13 February 2011 (UTC)

That is a fairly recent, added after <references /> was styled. ---— Gadget850 (Ed) ^talk 14:48, 16 February 2011 (UTC)

Would someone please give some sources that explain the problem with accessibility and a small font size? Wikipedia:Manual of Style (accessibility) is mute on font size as an issue and even mentions the use of <small>. I have skimmed through the Section 508 and Web Content Accessibility Guidelines and don't see this. I have used some online accessibility tools to check several articles and don't see a font problem. Note: This is the third time I have asked the same question. ---— Gadget850 (Ed) ^talk 14:48, 16 February 2011 (UTC)

MW 1.17 now live, juicy style/script excitingness for all

It looks (fingers crossed) like MW1.17 is here to stay, which means we now have full access to ResourceLoader and all the exciting things it brings. Most notably, that changes to these stylesheets are now live to everyone within five minutes. No more waiting for 30 days' decaching time!! :D Happy‑melon 11:51, 16 February 2011 (UTC)

The message should probably be updated to reflect the faster update time. See also: Wikipedia:Village pump (technical)#Blue new message bars?!. They should probably be changed back to orange. –xeno^talk 19:45, 16 February 2011 (UTC)

People know orange. They are used to orange. Orange is very obvious if you are not used to orange. The new ice blue may be all sexy but I'd like some fruit please. Pedro : Chat 20:16, 16 February 2011 (UTC)

Wait-what? Stylesheets should take effect immediately? I have the opposite problem, here: Wikipedia:Village_pump_(technical)#Wiki_loads_older_CSS_version. Gary King (talk · scripts) 20:18, 16 February 2011 (UTC)

Change it back. This bar must be eye-catching or it's worthless. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 20:19, 16 February 2011 (UTC)

Indeed. The notice is supposed to clash with most color schemes, that's how you know it's there. — Gavia immer (talk) 20:41, 16 February 2011 (UTC)

Regarding references

In preparation of the outcome of the discussion at Wikipedia:Village pump (proposals)#styling <references /> like Reflist, I have added (non-active) code to replace:

/* Make the list of references in [[Template:Reflist]] smaller */
.references-small { 
    font-size: 90%;
}

with:

/* Make the list of references smaller */
ol.references,             /* <references /> and {{reflist}}  */
div.references-small > dl, /* {{refbegin}} with indented list */
div.references-small ul {  /* {{refbegin}} with bulleted list */
    font-size: 90%;
}

This wil ensure that reference lists generated by <references />, {{reflist}} and {{refbegin}} will be styled the same. The styling is applied to any lists within the divs, instead of the divs of the templates themselves, to avoid applying the style twice, in case someone applies a style to eihter .references or .references-small. I choose to maintain the classname .references-small to avoind a conflict with .references, and avoid having to edit the templates.

Alternatilvely, to allow more flexibility for custom skinning, the classes for the templates could be renamed .references-reflist and .references-refbegin. Since {{reflist}} does not needs additional styling (as it embeds <references />), the code would look like this:

/* Make the list of references smaller */
ol.references,                /* <references /> and {{reflist}}  */
div.references-refbegin > dl, /* {{refbegin}} with indented list */
div.references-refbegin ul {  /* {{refbegin}} with bulleted list */
    font-size: 90%;
}

Comments welcome. — Edokter • Talk — 18:51, 18 December 2010 (UTC)

Seems like a sane idea, if the support is there. Why rename the classes though? It can be confusing, and we should avoid it if possible. Alternatively, just add additional classes to the template itself. That's the big advantage of using classes, you can use more than one. —TheDJ (talk • contribs) 12:23, 19 December 2010 (UTC)

Or potentially simply deprecate "references-small". Refbegin and Reflist would have: class="references refbegin" , and the CSS could simply become:

/* Make the list of references smaller */
ol.references,       /* <references /> and {{reflist}}  */
div.references > dl, /* {{refbegin}} with indented list */
div.references ul {  /* {{refbegin}} with bulleted list */
    font-size: 90%;
}

I think that would be the most logical. This change might break some screenscraping tools though... Mobile website, and some user gadgets perhaps ? Anyone know of candidates that could be affected by this ? —TheDJ (talk • contribs) 12:31, 19 December 2010 (UTC)

That was my first idea as well, but if someone assigns a fontsize to .references in his skin CSS, it would cause the fontsize of both the ol.reference class, and the personal CSS to be applied on {{reflist}}; However, giving the templates two classnames is a way around that. (There simply would be no one-class solution to style all refs at once anymore.) I would give {{reflist}} the classnames reflist references, and {{refbegin}} the classnames refbegin references, so both templates can be skinned seperately. — Edokter • Talk — 21:06, 19 December 2010 (UTC)

Discussion has been going on for 8 days, with overwhelming support as a result. Since there is no easy transition (unles we had stuck with references-small), I'll just go ahead and make the change here and to the templates, and update the Wikipedia:catalogue of CSS classes. Worst case is that references may have normal fontsize for up to 30 days. — Edokter • Talk — 00:00, 21 December 2010 (UTC)

Addendum: I found 26 articles that pass class=references-small to templates like {{col-begin}}. How should we handle this? Leave in references-small, or ignore the 'abuse' of this class? — Edokter • Talk — 00:16, 21 December 2010 (UTC)

Addendum 2: I'll update those articles hwere needed. — Edokter • Talk — 12:10, 21 December 2010 (UTC)

This is, AFAIK, broken in two different ways. First, the child selector > doesn't work on IE, certainly earlier versions of IE. And IIRC, adding comments within a selector block breaks several old browsers (it came up with one of the mbox styles, it'll be somewhere in the archives...). Happy‑melon 16:31, 21 December 2010 (UTC)

Checking... (I can only test IE6 on my old box). — Edokter • Talk — 17:21, 21 December 2010 (UTC)

Indeed, does not work on IE6. I can fix that inline in {{refbegin}}, but I prefer my solution below, which will have no such complication. — Edokter • Talk — 17:37, 21 December 2010 (UTC)

Bulleted text in reflist footnotes has suddenly become excessively small. Will that be repaired or is is it better to simulate bullets in footnotes? The Tetrast (talk) 16:49, 21 December 2010 (UTC).

Please provide a page where this is visible. — Edokter • Talk — 17:21, 21 December 2010 (UTC)

http://en.wikipedia.org/w/index.php?title=Charles_Sanders_Peirce&oldid=403425354
(Inserted note: Mediawiki CSS has been changed such that these examples and tests no longer show the problem, since it has been resolved. The Tetrast (talk) 18:42, 21 December 2010 (UTC)). Even better, one can show it right here^[1]

^
See:
- Test test

Also note the following effect on sub-bulleted text with refbegin:

Test test
- Test test

The Tetrast (talk) 17:28, 21 December 2010 (UTC). Edited The Tetrast (talk) 17:31, 21 December 2010 (UTC).

I did not expect refs being used with nested bulleted lists; same problem as above; I'd have to use the > selector, or ignore IE6 users, or go with the whack solution below. — Edokter • Talk — 17:37, 21 December 2010 (UTC)

I have workarounds for the articles (very few) where I've put bullets in footnotes, so I wouldn't have you change things just on account of those few articles. Bullets are probably rare in footnotes. Bullets and sub-bullets might be not so rare in refbegin situations, but I don't know. The Tetrast (talk) 17:44, 21 December 2010 (UTC)

There were bullets in footnote 79 at the Scientific method wiki http://en.wikipedia.org/w/index.php?title=Scientific_method&oldid=401252169#Notes but they were by my hand originally (when I combined four footnotes that I found there into one for obvious reasons), and I've done a workaround there now, too. The Tetrast (talk) 18:03, 21 December 2010 (UTC).

Wow, that was fast. Cool. The Tetrast (talk) 18:42, 21 December 2010 (UTC).

Whack?

I just discovered MediaWiki:Cite references prefix (and MediaWiki:Cite references suffix). We could simply wrap the ol in a <div class="references">, and be done with defining div.references. But we would have to remove the 'references' class from the reflist template. — Edokter • Talk — 12:28, 21 December 2010 (UTC)

I am about to move all reference styling into the various divs. This eliminates the styling issues with the bulleted and indented lists (see above), and simplifies the styling in Common.css, as only div.references is needed. This means a div is added to MediaWiki:Cite references prefix, the "references" class is removed form {{reflist}}, and all that is left in Common.css is div.references { font-size: 90%; }. — Edokter • Talk — 17:58, 21 December 2010 (UTC)

Done. Purge your caches please. — Edokter • Talk — 18:32, 21 December 2010 (UTC)

I documented all of the MediaWiki messages related to Cite at Help:Cite messages. ---— Gadget850 (Ed) ^talk 18:57, 21 December 2010 (UTC)

Thank you. I missed that. — Edokter • Talk — 19:00, 21 December 2010 (UTC)

Next time, please make sure new CSS is deployed for 30 days before you remove old definitions from templates. The visual changes could have gone undetected for the majority, if proper 30 day staging period had been used. Reading Template_talk:Reflist, undetected they certainly were not. There is a big fat warning in the editnotice to remind you. —TheDJ (talk • contribs) 19:28, 21 December 2010 (UTC)

There was no other way around. Now that you have restored references-small in reflist, there is a genuine risk that the 90% is applied twice, as there are many that have it in their personal CSS. Better risk no styling for 30 days then duplicate styling. — Edokter • Talk — 20:08, 21 December 2010 (UTC)

I vehimently disagree. Editors who style their own CSS KNOW how to style their CSS and thus any effects caused by it can be solved by themselves and is their personal problem. Broken sitewide styling is OUR problem and should be avoided whenever possible, which is why we have our 30 staging and decaching period. —TheDJ (talk • contribs) 10:34, 25 December 2010 (UTC)

Normally I agree. However, had we maintained the original classnames, there would be no issue (changing them was your idea). But it did expose problems with the original proposed code, which could only be fixed by moving to the current setup, which I think is way more robust, so that is a positive thing.

There was talk about a new caching scheme some time ago, at least for common.js (and by extention common.css). Whatever happened to that idea? — Edokter • Talk — 13:26, 25 December 2010 (UTC) (Merry Christmas!)

New approach

I'm not entirely happy with the curent setup,mainly because it produces inconsistent bahaviour in columns. This is how HTML is currently structured in each if the three cases using either <references />, {{reflist}} and {{refbegin}}:

<references />:
<div class="references"> (90%)
  <ol>

{{reflist}}:
<div class="reflist"> (columns)
  <div class="references"> (90%)
    <ol>

{{refbegin}}:
<div class="refbegin references"> (columns 90%)

This results in pages that have both reflist and refbegin with both their column width set to 30em, displaying reflist in two, and refbegin in three columns (I can't find a page right now). To remedy this, I want to partially return to the old proposed format, but which works in all browsers using standard CSS. I propose that we:

Remove <div>...</div> from MediaWiki:Cite references prefix/suffix
Remove .references class from {{refbegin}}
Add following to Mediawiki:Common.css:

/* Make the list of references smaller */
ol.references,
div.reflist,
div.refbegin {
    font-size: 90%;
}
/* reset fontsize of ol.references when nested in div.reflist */
div.reflist ol.references {
    font-size: 100%;
}

— Edokter (talk) — 20:22, 26 February 2011 (UTC)

I've implemented the changes. No breakage detected. — Edokter (talk) — 00:10, 3 March 2011 (UTC)

Aren't we losing some semantic value by removing .references from {{refbegin}}? IIRC, some people have .references { display:none; } to "hide the useless junk". — Dispenser 00:30, 3 March 2011 (UTC)

Refbegin is basically a manual list (not auto generated), but I can update Help:Reference display customization accordingly. Besides, this way allows more flexibility in hiding certain lists. — Edokter (talk) — 00:37, 3 March 2011 (UTC)

On a related note, I would like to find a way to apply list-style-type to format the reference list when custom link labels are used. See Help talk:Cite link labels. ---— Gadget850 (Ed) ^talk 04:08, 3 March 2011 (UTC)

Template:infobox

The generic infobox template uses the "infobox" class, but then adds a few more style statements, "width:22em; text-align:left; font-size:88%; line-height:1.5em;". Would it be possible to create a subclass for these additional style statements? This would allow editors to override the font-size in his/her own custom css file. I would add this myself, but I cannot think of a good name, and am slightly worried about not adding it correctly (although I am fairly certain I could figure it out with a bit of testing). This would also allow other infoboxes, which do not use {{infobox}}, to use this class as well. Thanks! Plastikspork _―Œ^(talk) 21:12, 26 February 2011 (UTC)

Best solution would be to just move these declaration to common.css, then they'll be easier to override. — Edokter (talk) — 22:25, 26 February 2011 (UTC)

Right, which is why I am asking here. I don't think we should add this to the "infobox" base class, since it would almost certainly have some unintended consequences, but perhaps an additional class would be good. What should we call this class? Thanks! Plastikspork _―Œ^(talk) 22:33, 26 February 2011 (UTC)

I don't think there will be unintended side effects; infobox is the only base template using this class. — Edokter (talk) — 22:39, 26 February 2011 (UTC)

Anyway, I think creating a subclass is only complicating matters even more. — Edokter (talk) — 22:47, 26 February 2011 (UTC)

I have seen {| class="infobox" in dozens of templates, and articles, so it would probably impact others. However, I don't recall how many of these were overriding the default, like say the second infobox in Amazon Kindle. This isn't necessarily a bad thing, and the easy fix is to just override it on a case-by-case basis if someone complains. I would certainly support just updating the base class if people are okay with fixing individual boxes as problems arise. I just thought going with a subclass would be the least controversial. Either way works for me. Plastikspork _―Œ^(talk) 22:59, 26 February 2011 (UTC)

I just like to keep things simple, while subclassing is generally a PITA. I'll incorporate the inline styling. — Edokter (talk) — 00:26, 27 February 2011 (UTC)

Thanks, I have already spotted some complaints, and fixed one in taxobox, but more will probably come up. Perhaps it would be a good idea to go through the templates with the largest number of transclusions, and check those. Thanks! Plastikspork _―Œ^(talk) 01:10, 27 February 2011 (UTC)

I'm not so sure I understand much of the above discussion, but I don't think such a widespread change should be dealt with by overriding if someone complains. I've noticed biography infoboxes, e.g. {{Infobox person}} and {{Infobox Scientist}} having the same small-text issue. Was this the intention? I've also noticed text within <pre> tags being smaller. I don't think this should be the default text size. Rkitko ^(talk) 01:33, 27 February 2011 (UTC)

(←) {{Infobox}} had inline styling, which is better served by moving it to Common.css. That way, individual styling becomes more flexible. I realise that this affects other template that use the .infobox class directly (not using infobox as a meta template), which can always be fixed inline. I don't think the <pre>...</pre> text is related though, unless you're talking about preformatted text embedded in an infobox. — Edokter (talk) — 02:08, 27 February 2011 (UTC)

Having had a look, {{Infobox person}} and {{Infobox Scientist}} both use {{infobox}} directly; they should not be affected. — Edokter (talk) — 02:11, 27 February 2011 (UTC)

I was using class infobox not only for variously purposed tables but also for floated divs. Now here's the strange thing. The div with class:infobox suddenly has a fixed width. Here's an example (with font-size 100%). I've specified no width in it, but its width is rigid and independent of line length. Increase & decrease browser width to see.

The Tetrast (talk) 02:22, 27 February 2011 (UTC).

Yes, the width is set to 22em. I've never seen a div using .infobox before. It seems the .infobox class has the tendency of being misused in some places. I'd really like to keep the infobox CSS in common.css, and not inline in {{infobox}}. Meanwhile. putting width: auto; in the div should fix this example. — Edokter (talk) — 02:35, 27 February 2011 (UTC)

Yes, the width:auto works. Class:infobox isn't misused when it's a way to save some bytes of markup. One would use divs instead of table markup (pipe or otherwise) when somebody might think that the table was being used to arrange a page element. The Tetrast (talk) 02:51, 27 February 2011 (UTC).

Width - the minwidth has been there for some time I believe but it might be a good idea to have a max-width too. See this example where it would have helped. Rich Farmbrough, 09:49, 27 February 2011 (UTC).

Yes, I see that one quite a bit when going through Category:ParserFunction errors. In some ways it's a nice big warning that the editor did something wrong, but it does make it hard to see exactly where things went wrong. Plastikspork _―Œ^(talk) 17:34, 27 February 2011 (UTC)

Removing the width just broke a bunch of stuff. I'd edited infobox tables to rely on this and the removal broke them; allowed tables to widen. This class is not just used in templates, it's used in a large number of inline tables. This class should have the width so that it's standard and 22em is fine; mostly it shouldn't be overridden, but I know some narrow templates do so; {{tl:Islam}}, for example. Gold Hat (talk) 22:42, 8 March 2011 (UTC)

Sorry to hear that. I moved the width back to the template because of complaints that moving it to common.css broke numerous templates. — Edokter (talk) — 23:23, 8 March 2011 (UTC)

I fixed the ones I'd edited; added the width. I doubt too many others took advantage of the width in the css and if they did, presumably they'll fix whatever (AGF, and all). I'm not too surprised that other things broke. This illustrates a fundamental problem with wikis; there's no one in charge of anything; chaos reigns. Above, for example, the mention of <div class="infobox">, hell, someone prolly set it on an em-element, somewhere. At this point in teh wiki's life, far too much is cemented in place for much to change absent some sort of authority to impose something. See the WP:POST re a WYSISIG editor; seems people think it's a good thing. It will lower the bar even further to allow anyone to snot-up the wiki-text with silly markup. And see Gerard's comment in the earlier issue; the body of wiki-text is full of junk the 'anyone' has been free to paste-in.

Anyway, with so many instances of this class in place in so many places, any change is going to break something. We're all fleas on a mammoth; no one knows what's really out there, so it's all a guess. I'd be inclined to let the templates need to get fixed by adding an override of width, but hey, no one listened to me before. Damned, Gold Hat (talk) 23:43, 8 March 2011 (UTC)

For my part, I was not complaining about having to add width:auto to a div that has class=infobox. I don't to mean to pressure folks here to accommodate every odd use of class=infobox that an editor like me happens for economy's sake to make of it. Instead I just wanted to report that width very recently suddenly became specified for divs by class=infobox, and not to prejudge but to let folks here judge whether it was unintended, significant as a problem, a tip of some iceberg, etc., I dunno. Sometimes I catch a problem that might affect many, not just me, such as the excessively small text that appeared for a short while in 2nd-level bullets in a refbegin setting. The Tetrast (talk) 01:26, 9 March 2011 (UTC).

Expand MediaWiki:Common.css/WinFixes.css

There is a bunch of templates that use explicit font definitions. These are intended to fix an MSIE bug: Its inability to choose a proper fonts. However, this fix for a MSIE bug negatively affects all other browsers. It needlessly causes ugly typeface mixes.

The same problem used to affect {{IPA}}, {{polytonic}} and {{unicode}}. However, there has been a solution: The explicit font definitions have been moved to MediaWiki:Common.css/WinFixes.css. Like this, the MSIE bug fix only works in MSIE, but no longer affects other browsers.

Is there any reason why this elegant solution is only used for these three templates, while most other templates that fix the MSIE bug still negatively affect all other browsers by using explicit font definitions? If there is no such reason, I suggest that Common.css/WinFixes.css be expanded.

Some of these templates include:

In order to fix any of these, the template must be edited so it no longer includes a font definition, but a special class, and then the font definition for that class must be included in Common.css/WinFixes.css. -- mach ᵗᵃˡᵏ 09:13, 30 March 2011 (UTC)

Article feedback / printing

The article feedback section in articles such as 1346 should probably be excluded from printing. ---— Gadget850 (Ed) ^talk 18:57, 3 April 2011 (UTC)

I agree. Since the interface is not loaded in the print version if javascript is not enabled, I think this is something to be reported on bugzilla, so that the script isn't added at all in such pages (instead of hiding it after it is added). Helder 12:02, 4 April 2011 (UTC)

Gentium for {unicode}?

Any problems moving Gentium to the head of the list for unicode? The current display with Arial is hideous. — kwami (talk) 17:20, 4 April 2011 (UTC)

Yes, that would be a problem. While regarded hidious by some, it is the most comprihensive unicode font on Windows, and the second most widely available one next to Lucida Sans Unicode. Preferring any less avialable font may adversely affect unicode support. — Edokter (talk) — 17:44, 4 April 2011 (UTC)

FreeSans vs Free Sans

The .script-phoenician class of MediaWiki:Common.css/WinFixes.css refers to "FreeSans" while elsewhere it is referred to as "Free Sans". Is this a problem? John Vandenberg ^(chat) 16:13, 11 April 2011 (UTC)

The typeface should be called as "Free Sans", so yes, that may be a problem. — Edokter (talk) — 16:29, 11 April 2011 (UTC)

The .script-phoenician class refers to "ALPHABETUM Unicode", however Template:Mufi refers to "Alphabetum" (and "ALPHA-Demo" is a different font) more info here. I'm pretty sure these are the same font; can these fonts have multiple valid names registered at the same time? John Vandenberg ^(chat) 18:23, 11 April 2011 (UTC)

No. The CSS names must match the Windows fontnames. In this case, "ALPHABETUM Unicode". — Edokter (talk) — 20:20, 11 April 2011 (UTC)

Thx for fixing that. John Vandenberg ^(chat) 00:12, 13 April 2011 (UTC)

who can add?

who can add something as below? it makes infobox gorgeous :) but they have to be translated from World language into English

 /* Por informkestoj - laŭ la franca kaj suprasoraba vikipedioj "entete" resp. "hornja-linka" */
/* Nun ŝanĝita tiel, ke devus funkcii kun aliaj CSS-klasoj, kiuj difinas la fonan koloron. */
.kaplinio.io {}
.kaplinio.aktorado {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/3/37/Picto_infobox_masks.png"); 
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.biero {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/0/04/Picto_infobox_beer.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.komikso  {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/2/2c/Picto_infobox_comicballoon.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.film,
.kaplinio.kino  {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/e/ea/Picto_infobox_cinema.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.komunikado    {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/a/a2/Picto_infobox_antenna.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.mapo  {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/7/7a/Picto_infobox_map.png");
  background-repeat:  no-repeat;
  background-position: top right;
  font-size:110%; 
}
.kaplinio.muziko {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/6/60/Picto_infobox_music.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.skribisto {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/1/1e/Picto_infobox_auteur.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.sporto   {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/8/8e/Picto_infobox_Olympic.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.videoludo   {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/2/2d/Picto_infobox_gamepad.png");
  background-repeat: no-repeat;
  background-position: bottom right;
}
.kaplinio.persono {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/8/82/Picto_infobox_manwoman.png");
  background-repeat:  no-repeat;
  background-position: top right;
}
 
/* Aldonoj de Tlustulimu */
.kaplinio.astronomio {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/7/71/Picto_infobox_astronomy.png");
  background-repeat:  no-repeat;
  background-position: top right;
}
.kaplinio.fiziko {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/d/d1/Picto_infobox_physics.png");
  background-repeat:  no-repeat;
  background-position: top right;
}
.kaplinio.kemio {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/9/95/Picto_infobox_chemistry.png");
  background-repeat:  no-repeat;
  background-position: top right;
}
.kaplinio.stelo {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/2/2e/Picto_infobox_star.png");
  background-repeat: no-repeat;
  background-position: top right;
}
 
.kaplinio.papo,
.kaplinio.vatikano
{
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/3/31/Picto_Emblem_of_the_Papacy.PNG");
  background-repeat: no-repeat;
  background-position: top right;
}
 
/* plia bildetoj */
.kaplinio.iloj {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/c/cb/Picto_infobox_tools.png");
  background-repeat: no-repeat;
  background-position: top right;
}
 
.kaplinio.armeo,
.kaplinio.armeano,
.kaplinio.soldato {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/0/03/Picto_infobox_military.png");
  background-repeat: no-repeat;
  background-position: top right;
} 
 
.kaplinio.helpo,
.kaplinio.projekto {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/2/24/Picto_infobox_default.png");
  background-repeat: no-repeat;
  background-position: top right;
}
 
/* bildetoj laŭ la hungara vikipedio */  
.kaplinio.ponto {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/8/87/Picto_infobox_bridge.png");
  background-repeat: no-repeat;
  background-position: top right;
} 
 
.kaplinio.pilko,
.kaplinio.piedpilko,
.kaplinio.futbalo {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/a/a8/Picto_infobox_football.png");
  background-repeat: no-repeat;
  background-position: top right;
} 
 
.kaplinio.strato,
.kaplinio.vojo {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/5/57/Picto_infobox_motorway.png");
  background-repeat: no-repeat;
  background-position: top right;
}
 
/* bildetoj laŭ la portugala vikipedio */
.kaplinio.astronauto,
.kaplinio.kosmonauto {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/0/0a/Picto_infobox_astronaut.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.frukto,
.kaplinio.fruktoj {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/6/66/Picto_info_grape.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.gazeto {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/d/d6/Picto_infobox_newspaper.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.komputilo,
.kaplinio.informadiko {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/d/d1/Picto_infobox_pc.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.libro {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/4/42/Picto_infobox_book.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.ludo,
.kaplinio.ludilo {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/b/b8/Picto_info_toys_and_games.png");
  background-repeat: no-repeat;
  background-position: top right;
}
.kaplinio.TV,
.kaplinio.televidado {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/4/44/Picto_infobox_TV-icon-novela.png");
  background-repeat: no-repeat;
  background-position: top right;
}
 
/* travideblaj fonaj bildoj */
.media.audio {
  background-image: url("http://upload.wikimedia.org/wikipedia/commons/thumb/a/a6/Gnome-speakernotes.png/35px-Gnome-speakernotes.png");
  background-repeat:  no-repeat;
  background-position: top left;
} 
.media.video {
  background-image: url("http://upload.wikimedia.org/wikipedia/en/thumb/2/20/Tango-video-x-generic.png/35px-Tango-video-x-generic.png");
  background-repeat: no-repeat;
  background-position: top left;
}

please check [1] —Preceding unsigned comment added by 113.111.199.85 (talk) 00:30, 2 May 2011 (UTC)

"Gorgeous" is in the eye of the beholder. This is a radical style change that requires consensus, and I don't see that happening soon. Sorry. — Edokter (talk) — 09:45, 6 May 2011 (UTC)

Horizontal lists

From Wikipedia talk:Manual of Style (accessibility)#Horizontal lists in navboxes:

“

Many thousands of Wikipedia articles have navboxes, in which lists of links are presented, horizontally, without using list mark-up, but instead using {{·}} or suchlike as a kludge. This is semantically poor and has implications for accessibility.

I created {{Flatlist}} in an attempt to begin addressing this, but previous discussion (two-and-a-half years ago) petered out before various concerns were resolved. Now that CSS an browsers have moved on, I'd like us to find a solution. Ideas? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's talk; Andy's edits 13:58, 28 March 2011 (UTC)

”

Following discussion, a solution has been suggested and tested which creates a subclass, tentatively named "hlist" which creates a horizontal list with middot-type separator from any ordered or unordered list by wrapping it in a div class="hlist".

The sub-class may be defined as follows:

/* Style for horizontal lists (separator following item) */
.hlist ul, .hlist ol {
    padding: 0em;
    margin: 0em;
}
.hlist li { 
    padding: 0em 0.54em 0em 0em;
    display: inline;
    background-image:url(http://upload.wikimedia.org/wikipedia/commons/d/da/Middot.png);
    background-position:right center;
    background-repeat:no-repeat;
}
.hlist li:last-child {
    padding-right: 0em;
    background: none;
}

It may be implemented as:

<div class="hlist">
<ul>
<li>Item 1</li>
<li>Long Item 2</li>
<li>Im 3</li>
<li>Item 4</li>
</ul>
</div>

or

<div class="hlist">
:Item 1
:Long Item 2
:Im 3
:Item 4
</div>

or

<div class="hlist">
#Item 1
#Long Item 2
#Im 3
#Item 4
</div>

or even directly on a UL or OL tag.

The resulting output is believed to be as accessible as possible, using W3C standard recommendations to display decorative visual elements as background images. It has been tested by Graham87 on JAWS (spoken as a normal vertical list, as it should).

It has been tested in users' vector.css and monobook.css without problem on multiple browsers. User:Pigsonthewing/scratchpad 2 contains several examples of the style implemented within templates.

There is a general consensus at Wikipedia talk:Manual of Style (accessibility)#Horizontal lists in navboxes that the style would be a useful step forward in improving accessibility across the wiki, as it would be applicable wherever a separated horizontal list would be appropriate (navboxes being an obvious example).

Any thoughts, comments, or other observations would be welcome. Should no objections be raised, would it be possible to incorporate this sub-class (or something similar) into common.css, please? --RexxS (talk) 01:58, 8 April 2011 (UTC)

Support. Everything has been said. {{Flatlist}} is currently poorly accessible, and RexxS's proposal will make this template perfectly accessible. Plus, it drastically improves the design too, which increases the likeliness of {{Flatlist}} to become widely used. Speaking of potential, there is a drastic number of horizontal lists that should be using {{Flatlist}} in order to improve accessibility. Yours, Dodoïste (talk) 19:07, 8 April 2011 (UTC)
- {{Flatlist}} is fully accessible. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:26, 8 April 2011 (UTC)
  - My mistake, you're right. It's a design improvement for {{Flatlist}}. And then this template can be used to replace many inaccessible horizontal lists. I somehow got confused. Dodoïste (talk) 22:58, 8 April 2011 (UTC)
Support. This fully resolves the issue I raised in the post quoted above. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:26, 8 April 2011 (UTC)
Support But the CSS needs some tweaking; the zero margin is too tight. — Edokter (talk) — 21:49, 8 April 2011 (UTC)

I agree that some rationalisation would be helpful, assuming that you're referring to ul/ol margin-bottom. We already have:

div#content ol ... div#mw_content ul { margin-bottom : 0.5em
div.medialist ul { margin: 0
.horizontal ul { margin: 0

The "hlist" class was intended to be as compatible as possible with the existing "horizontal" class, as one of the early suggestions was to redefine that class. In any case, if this new class were to be used as replacement (partial or otherwise) for "horizontal", then it would seem sensible to have the same metrics in order to minimise the chances of breaking existing implementations. Nevertheless, a better suggestion for margin would always be appreciated (inherit, perhaps?). --RexxS (talk) 00:53, 9 April 2011 (UTC)

It depends on where it's used. In navbox lists, the zero marging creates too little space below the list, but the default margin creates too much space in other places. Basically, I think we should maintain the default list margin (only reset the left margin), but add an option to disable it. The padding is redundant. So the code would look like this:

/* Style for horizontal lists (separator following item) */
ol.hlist, ul.hlist,
.hlist ol, .hlist ul {
    margin-left: 0;
}
ol.nomargin, ul.nomargin,
.nomargin ol, .nomargin ul {
    margin: 0 !important;
}
.hlist li { 
    padding: 0em 0.6em 0em 0em;
    display: inline;
    background-image: url(http://upload.wikimedia.org/wikipedia/commons/d/da/Middot.png);
    background-position: right center;
    background-repeat: no-repeat;
}
.hlist li:last-child {
    padding-right: 0em;
    background: none;
}

I also added element classes so you can assign the hlist class directly to the list. — Edokter (talk) — 09:25, 9 April 2011 (UTC)

Thank you, that looks like a valuable improvement in flexibility. I'd be more than happy to support those modifications. --RexxS (talk) 19:03, 9 April 2011 (UTC)

Request

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

As the discussion above seems to have some consensus, I'd like to request that the changes shown in the "syntaxhighlight" box immediately above this (timestamped 09:25, 9 April 2011 (UTC) by Edokter) be implemented. --RexxS (talk) 00:21, 20 April 2011 (UTC)

Added — Martin (MSGJ · talk) 08:33, 20 April 2011 (UTC)

What about .horizontal?

The reason I didn't put it in yet was because of .horizontal. The two classes are essentially duplicates. Shall we deprecate .horizontal in favor of .hlist? — Edokter (talk) — 10:30, 20 April 2011 (UTC)

I would guess that "horizontal" is probably redundant now, but I've dropped a note to Andy Mabbett as I believe he was the prime mover for "horizontal" and the associated templates, so he might be aware of any reasons why it shouldn't be deprecated. --RexxS (talk) 11:05, 20 April 2011 (UTC)

I'd either keep it, but restyle with the new CSS, or remove it and fix anything that breaks (chiefly {{Flatlist}}). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:23, 20 April 2011 (UTC)

Let's remove it then and change {{flatlist}} to use .hlist. — Edokter (talk) — 14:24, 20 April 2011 (UTC)

OK. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:23, 21 April 2011 (UTC)

A better solution?

One problem with the current css code is that because the mid-dot is a png file, when you zoom in, the dot starts to look lousy and pixelated. I have another solution that is equally accessible, which avoids this problem and does not require the use of a background image:

/* Style for horizontal lists (separator between items) */
ol.hlist, ul.hlist,
.hlist ol, .hlist ul {
    margin-left: 0;
}
.hlist li { 
    display: inline;
    border: none;
    margin: 0;
    padding: 0;
    background-image: none;
}
.hlist li:before {
    content: "• ";
}
.hlist.ndash li:before {
    content: "– ";
}
.hlist.vline li:before {
    content: "| ";
}
.hlist.circle li:before {
    content: "◦ ";
}
.hlist.square li:before {
    content: "▪ ";
}
.hlist li:first-child:before {
    content: none;
}

I've tested it on Chrome and Firefox, and it looks great. Another benefit is that as an alternative to the bullet, you we can optionally specify other separators, such as an ndash, vertical line, circle, or square, etc. COGDEN 23:01, 20 April 2011 (UTC)

Sadly, around 10% of visitors are using IE7, and perhaps as much as 5% are still using IE6. I think you'll find the :before selector isn't supported by those browsers. Have you checked how a screen reader speaks the lists, as it would be nice to have an accessible alternative to the images when the proportion of IE7 users drops to a level where this more elegant solution would be practical. --RexxS (talk) 00:33, 21 April 2011 (UTC)

IE6 and 7 do not like these pseudo selectors, so I think we're stuck with the image for now. — Edokter (talk) — 00:33, 21 April 2011 (UTC)

Speaking of which, we have an even greater problem with the current code. According to Microsoft, the :last-child pseudo-selector is not supported by IE8 (IE7 supports :first-child, however). Thus, the current code doesn't work in IE8. Are IE workarounds out of the question? COGDEN 01:58, 21 April 2011 (UTC)

I don't know how people feel about IE7 hacks, but here is a hack that apparently works in both IE7+ and in real browsers:

/* Style for horizontal lists (separator between items) */
ol.hlist, ul.hlist,
.hlist ol, .hlist ul {
    margin-left: 0;
}
.hlist li { 
    display: inline;
    border: none;
    margin: 0;
    padding: 0;
    padding: 0em 0em 0em 0.6em !ie7;
    background-image: none;
    background: url(http://upload.wikimedia.org/wikipedia/commons/d/da/Middot.png) left center no-repeat !ie7;
}
.hlist li:before {
    content: "• ";
}
.hlist.ndash li:before {
    content: "– ";
}
.hlist.vline li:before {
    content: "| ";
}
.hlist.circle li:before {
    content: "◦ ";
}
.hlist.square li:before {
    content: "▪ ";
}
.hlist li:first-child:before {
    content: none;
}
.hlist li:first-child {
    padding-left: 0em;
    background: none;
}

This still does not address IE6, but maybe someone can think of a replacement for :first-child, which IE7 understands, but IE6 does not. COGDEN 05:12, 21 April 2011 (UTC)

If you read the original discussion at Wikipedia talk:Manual of Style (accessibility)#Horizontal lists in navboxes, you'll see that a solution was being sought which displayed the separator after the item text, not before it, because of the effect when long lists wrap. The solution you're proposing is actually /* Style for horizontal lists (separator before items) */. It could be re-written to place separators after, but then you'd be back to the same support for last-child. --RexxS (talk) 08:52, 21 April 2011 (UTC)

I did not even notice that it didn't work in IE8. Since IE6 and 7 are on the decline, I don't mind the extra bullet after the list; I doubt many will even notice. As for the bullet, I think we should stick to the image. The standard ul list also uses

(in Vector) and

(in Monobook). — Edokter (talk) — 09:56, 21 April 2011 (UTC)

I don't see any way to both: (1) have the bullet at the end of the line rather than the beginning, and (2) omit the extra bullet in IE8. I think we have to choose one or the other. What looks worse? As to using the png rather than a character, I think that nobody would consider using png bullets in Monobook if IE8 supported SVG. Sometimes these png images look really crappy when you print them out on a laser printer. In Monobook, they made a choice between color vs. pixelation. For common.css, we are not using color bullets anyway, so why settle for them being pixelated? Here is my revised code below, which solves all the problems discussed above for real browsers and IE9. For IE8 there is an extra bullet at the end. For IE6 and IE7 there is no bullet at the end, but there is a bullet at the beginning of lines after wrapping, and it has the pixelated bullet.

/* Style for horizontal lists (separator between items) */
ol.hlist, ul.hlist,
.hlist ol, .hlist ul {
    margin-left: 0;
}
.hlist li { 
    display: inline-block;
    display: inline !ie7;
    border: none;
    margin: 0;
    padding: 0;
    padding: 0em 0em 0em 0.6em !ie7;
    background-image: none;
    background: url(http://upload.wikimedia.org/wikipedia/commons/d/da/Middot.png)left center no-repeat !ie7;
}
.hlist li:after {
    content: " •";
}
.hlist.ndash li:after {
    content: " –";
}
.hlist.vline li:after {
    content: " |";
}
.hlist.circle li:after {
    content: " ◦";
}
.hlist.square li:after {
    content: " ▪";
}
.hlist li:last-child:after {
    content: none;
}
.hlist li:first-child { /*for IE7*/
    padding-left: 0em;
    background: none;
}

COGDEN 10:47, 21 April 2011 (UTC)

An SVG won't work with the background selector. MediaWiki normally converts SVG to PNG for display, but it doesn't work when used in this fashion. ---— Gadget850 (Ed) ^talk 11:52, 21 April 2011 (UTC)

Good point. Thanks.

I'm concerned that the status quo, with an extra bullet at the end, looks so bad in IE8 that editors won't use this, which is a real shame considering the accessibility benefits. I think maybe the best option is to just do a complete separate hack for IE6-8, and then use a solution with :last-child with all the other browsers. COGDEN 06:10, 4 May 2011 (UTC)

I think the best and simplest solution is to remove the last bullet in IE through javascript (for example in a new IEFixes.js). — Edokter (talk) — 19:18, 9 May 2011 (UTC)

I think that's a good solution. But if we're going to use IEFixes.js for IE6-8 anway, we might as well use .hlist li:after { content: " •";} for the normal case, rather than the background bitmap hack. Also, the Javascript could insert real bullets between the list items, rather than bitmaps of bullets. In fact, that would probably be easier to do in Javascript than dealing with the bitmaps. COGDEN 20:11, 9 May 2011 (UTC)

(←) That complicates things further... Shall we concentrate about getting it working first, and worry about prettyfication later? — Edokter (talk) — 20:25, 9 May 2011 (UTC)

The Javascript solution will be completely different depending on the course taken. I actually think that solution will be less complicated using real bullets. If we're going to go the Javascript route, we should do it right the first time. COGDEN 20:51, 9 May 2011 (UTC)

I'm not a fan of filling the lists with bullets using javascript; not everyone has javascript enabled. For that reason alone, I think we're stuck with the background image. Whatever javascript is left should be as small and fast as possible. — Edokter (talk) — 21:23, 9 May 2011 (UTC)

Applying this to navboxes

I've started discussion on applying this to navboxes. Contributions welcome. See also two related deletion debates. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:09, 22 April 2011 (UTC)

Styling for dfn tags

The dfn tag has recently been whitelisted as a permissible element in Wiki markup. I thought it would be appropriate to add some default styling. There are probably two potential uses for the tag. The first one is for the defining instance at the beginning of the article, which is now generally bolded. Other instances in the body of the article will likely be rendered in italics. Therefore, I propose the following additions:

/* Styling for defining instances of terms. */
dfn {
      font-style: italic;
}
dfn.lede {
      font-style: inherit;
      font-weight: bold;
}
dt dfn {
      font-style: inherit;
      font-weight: inherit;
}

The "lede" class will appear whenever the dfn tag is used to designate the defining term in the lede for the article, usually the article's title. This appears to render correctly in every browser.COGDEN 11:27, 28 April 2011 (UTC)

How would this be implemented? Are we expected to edit every article to wrap the first instance of the title in a <dfn class="lede">title</dfn>? Seems a bit labor-intensive. — Edokter (talk) — 12:00, 28 April 2011 (UTC)

We could create a dfn template. But I don't see the benefit here. The italic and bold markup is quite simple, so there is no savings in markup. <dfn> is intended for definitions and I don't see that the title phrase in the lede is a definition. We already have the semicolon markup for definition lists. ---— Gadget850 (Ed) ^talk 12:47, 28 April 2011 (UTC)

I don't think you properly understand <dfn>, it's not intended to contain the definition itself, it should hold the defining instance (i.e. it should hold the first instance of what is going to be defined by the page). I do agree somewhat however, that it would be quite a task to replace what we currently use (bolding) with dfn instead, and the end result may not really be worth it. - Kingpin¹³ (talk) 13:06, 28 April 2011 (UTC)

As a devil's advocate point: Nothing like that has to be done over night, and much of it could be done by a bot. I don't see that it needs to be done though, and it's problematic for reason I'll raise below. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 05:15, 9 May 2011 (UTC)

Is it important that the tag appear in the body of the text? If not, wouldn't it make more sense to just have the software wrap the page title in it? Happy‑melon 13:22, 28 April 2011 (UTC)

It's a <body> element. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 05:15, 9 May 2011 (UTC)

I don't think anybody needs to go and change every Wikipedia article any time in the near future, but for those editors wishing to make articles more accessible to the disabled, and make definitions more visible to Google and other search engines, the tag would be available--and it is available now, but just doesn't have standardized styling yet. Either way, there would not be any visible difference to the reader. See this discussion at MediaWiki about the rationale for whitelisting the tag. COGDEN 17:35, 28 April 2011 (UTC)

Re: "We already have the semicolon markup for definition lists."
Semicolons are suggested also for pseudo-headings in Help:Wikipedia: The Missing Manual/Formatting and Illustrating Articles/Article Sections and Tables of Contents#Technical Solutions for Long TOCs. Please advise if that use causes a problem or conflict. The Tetrast (talk) 18:10, 28 April 2011 (UTC).

Just as some asides: Per WP:MOSGLOSS, semicolon markup for definition lists should be studiously avoided for anything but the simplest lists, as its functionality is severely limited and buggy. And doing ;pseudoheadings to avoid long TOCs is no longer sensible now that we have {{TOC limit}}. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 05:15, 9 May 2011 (UTC)

Thanks for raising that issue. There is no conflict, either semantically or stylistically. First, there is no semantic conflict. According to HTML5, when "definition lists" (using "dl/dt/dd" tags) are used, you still use the "dfn" tag to tag any defined term within the "dt" element. The "dt" element is not only for defined terms, but they can be defined terms if the "dfn" tag is used.

Second, there is no styling conflict now that I have revised my original proposal above. In the original proposal, the use of a "dfn" tag within the "dt" part of a definition list (i.e., between the semicolon and colon) would have the effect of making the pseudoheading bold and italic. Therefore, I have made a slight revision to my proposal to fix that. Now, the use of a "dfn" tag in the "dt" part of a definition list will by default make no difference in the styling of a definition list. So there is no styling conflict. COGDEN 20:20, 28 April 2011 (UTC)

You can safely remove the inherit lines, as that is always the default. I'm not so sure about having different styling for one tag; it may be slightly confusing. — Edokter (talk) — 23:54, 28 April 2011 (UTC)

In this case, the inherit properties are needed. The "font-style: inherit" line for the "dfn.lede" selector is overriding the "font-style: italic" line for the "dfn" selector. The same goes with the other two inherits. If we didn't have the inherits, a <dfn class="lede"> tag would be presented as both italic and bold, which is not what we want. As to it being a different styling for one tag, I assume you mean a different styling for one particular class? The style sheet applies special rules for many different classes. Ultimately, this will be confusing for nobody because this functionality will be wrapped in templates. There will be one template in which you could optionally wrap a lede term, to ensure that it is presented as bold regardless of which browser is used, and that it will be recognized by screen readers and Google as a defined term. COGDEN 01:35, 30 April 2011 (UTC)

Which means it can be done in the template and there's no reason at all to have it be a site-wide style sheet class. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 05:15, 9 May 2011 (UTC)

Re: semicolon markup. Just a note to say thanks for the response and you're welcome (much of this discussion is beyond me). The Tetrast (talk) 04:21, 1 May 2011 (UTC).

This doesn't seem to be controversial, so styling has been added. COGDEN 05:56, 4 May 2011 (UTC)

(outdent) This is definitely controversial, should be reverted, and can safely be reverted with no changes to anything as far as I can tell. This stuff is problematic in several ways, some major.

Italicization (or other such effect) should not be done as a default in regular prose uses of dfn as such, either as a bare XHTML element nor embedded in a general prose template, since what bold and italic means in any given context in any given article can vary widely. E.g., in an article with many foreign words and expressions, or book titles, or other such uses of italics, the italics indicate those things, and "words as words" are usually given in quotation marks instead for clarity (like I just did what that phrase), while in many if not most articles without a lot of italicized things, words-as-words are italicized, like that. And so on; you cannot predict all of these cases nor account for them, so do not force CSS textual effects on general tools like dfn (which notably has no default style in the HTML specs, unlike some other elements like em and strong), unless and until there's a clear consensus to do so, that has thought through these issues and resolved them. I.e., I think you'd need direction from a clear consensus at WT:MOS, where anything like this should be discussed first, for any sort of default dfn appearance different from regular inline prose, after a rather long discussion there. I'd bet serious money that no such consensus would ever arise, for reasons I've already touched on; it's just too complicated, and there's no benefit to forcing a default. The principal purpose of using dfn in regular prose would be to label something in a machine-readable way the defining instance of a term in the context of that article's prose. This should be done transparently to the user. If editors feel this instance also warrants human attention as notable in and of itself, they can mark it up as appropriate in that specific context (bold, italic, list item, new section, whatever). So, the premature
dfn { font-style: italic; }
needs to come out.
Use both of boldfacing and of the dfn element for the lead term(s) of an article are and must remain severable, and there's no need for a permanent CSS class here. Just put it in a template (perhaps a ~~{{topic}}~~ I mean {{subject}} - {{topic}} is already taken) that applies <dfn style="font-weight:bold;">...</dfn>. We only need classes for stuff that is going to be reused in more than one place; this "lede" class is pretty much the diametric opposite of that (and it's "lead" not "lede"; the terms are near-antonyms: a WP lead is an informative summary that obviates reading the entire article unless one needs details, while a journalistic lede is a teaser opening that intentionally omits the most interesting information, forcing the reader to read more to understand the topic at all – a lead is to a movie review as a lede is to a movie trailer). Bold and dfn are necessarily severable code matters here because they sometimes have to be for grammatical reasons. I.e., in some cases, what appears in bold is not just the topic (the dfn term), but the topic plus one or more other (usually inflectional) morphemes. So, the special class for the lead case serves no purpose. Which means that the inherit stuff would also be pointless. Which, finally, means that none of these three CSS directives should have been added, and all should be removed.

There may well be specialized cases aside from lead term that will need special CSS handling, but we need to keep dfn unstyled by default, just like W3C and the rest of the Web do, or it's just going to be messy and confusing. In every case I can imagine, there's no reason not to do the custom style in a template, since there is nothing broadly generalizable enough about the appearance of any use of dfn that is likely to arise here such that it needs to be in the site-wide style sheet.

This is not the first proposal that the bolded term(s) in the lead representing the term(s) being defined by the article would be best put in templates. If this were done, it should use dfn now that it's available, when appropriate (it sometimes isn't, e.g. for any article title beginning "List of" or "Glossary of"). It just doesn't need to have anything to do with common.css, since there's no case for re-use outside of one template.

— SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 05:15, 9 May 2011 (UTC)

I'm not a fan of the default italic/bold styling either; it is confusing and not intuitive. I do have another suggestion though. I see many sites that semi-underline certain terms that pop up a brief defenition of that term. I think we can use that same priciple here: This term is defined. (See {{dfn}}.) — Edokter (talk) — 10:09, 9 May 2011 (UTC)

Yeah, I've been meaning to get around to something very similar for glossary entry links, so they are distinguishable from links to articles (or article sections). — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs.

Break

I've removed the styling for now. Since it is not clear how and when <dfn> should even be used, there is little point having it. Application should be tested in-line first. — Edokter (talk) — 12:23, 9 May 2011 (UTC)

I don't think that WP:MOS is the appropriate place to discuss stylesheet matters. That would be a good place to discuss when to use <dfn>, but how the tag should be represented is a different matter, and I think that discussion belongs here.

The reason I thought this styling would be non-controversial is that it merely codifies what most browsers do anyway. Most browsers, such as IE, Firefox, Opera, and Safari, automatically italicize <dfn>-tagged text. (Chrome, though, does not.) Not defining <dfn> in the stylesheet results in a situation that I think most people would find unacceptable: Wikipedia pages looking different in different browsers. Another reason I thought it would be non-controversial is that most writing style guides specify that the first instance of a defined term is italic.

If we want <dfn>-tagged text not to be italic, then we should definite as "normal" in the style sheet. Or, alternatively, we can use the dotted underline that Edokter prefers. Really, all I'm concerned about is to have some default styling for defined terms that is consistent across browers.

SMcCandlish, I'm not sure what you mean by <dfn> being kept "unstyled by default" by "W3C and the rest of the web". <dfn> is styled as italic by most browsers--at least, by far, the largest number of browser installations. And W3C is agnostic about how to style <dfn>.

Finally, even if an html class is used only in a single template, if the template will be used on many pages, there is good reason to put it in the style sheet. First of all, it improves server performance, and second, using style sheets to separate style from content is better practice, if possible, than using ad hoc "style" attributes. COGDEN 19:39, 9 May 2011 (UTC)

If some but not all major browser use the italics, then it isn't an actual convention, much less a standard. What I meant, in ref. to W3C, is that the HTML specs do not suggest any styling nor state that any particular style is typical (as they do for <strong> and some other tags), and the W3C-provided default style sheet for all elements does not provide any default style for the dfn element. Not italicizing is wise for reasons already mentioned - the short versions being that there are machine-readable reasons for tagging something as a defining instance without any effect on prose readability, and there are multiple uses of dfn (in regular prose, in glossaries and other special structure, and in article leads) with different (sometimes no) styling needs, so the "italicize because it's the first instance of a defined term" bit doesn't always apply (e.g., it would be foolhardy to do this in many cases, such as a glossary, or an article making heavy use of italics for some other reason). I agree that styling it "normal" by default here is a good idea, to force consistency, cross-browser. Any cases where the dfn element is needed to be italicized, or put in quotation marks, or whatever, as appropriate for its context, can be done with templates. And it shouldn't be the dotted underline by default, since that specifically indicates a pop-up or link-accessible definition. The matter genuinely is complicated and not something that we need to hard code (except maybe your consistency tweak). Lastly, I think that the MoS regulars would disagree with you on the role of WP:MOS. They regularly weigh in on matters such as this, because they are style matters, and the stylesheets generally flow from what MoS comes to a consensus on, rather than working the other way around, unless there's a technical issue. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 09:49, 10 May 2011 (UTC)

And it shouldn't be the dotted underline by default - You may have noticed in the {{dfn}} template that the underline is conditional depending on the presense of the defenition. — Edokter (talk) — 12:12, 10 May 2011 (UTC)

Yeps. (And sorry for the noinclude error yesterday!) I'm looking into generalizing {{cuegloss}} into a {{glossary link}} meta template that I hope will also use code from {{dfn}}. Sandboxing it right now. While we're on the subject, is there a way HERE (i.e. not in the deeper MW code) to override MW's default behavior of showing a tooltip of the page name and only the page name for wikilinks? In the template I'm working on for glossary links, I want it to show {{{glossaryname}}}: {{{term}}} as the title= value for the link. No other changes would be needed. I don't know if this is possible, since link handling may not be overridable here. If so, I'd like to also alter the display in this template such that it would have a blue dotted underline just like {{dfn}}'s green one, but blue to indicate it is an actual link, and not be a blue-text link. The idea is to make glossary links as unobtrusive as possible, but not invisible. Basically I need a class called glossary and (for now) some a .glossary stuff, IF that can actually override what MW does with links by default. Basically, I think it would be color: inherit; and underline code same as in {{dfn}} but the same blue as we use for links. So, basically, if your dfn is just a dfn marker, and the term is defined inline in the article, there'd be no typographic effect at all by default (I've modified {{dfn}} to ensure this). If it has a tooltip definition, it'd be plan text with a green dotted underline, as {{dfn}} now also does, but if it's a link to a definition entry in a glossary (in-article or external), it would look just the same except have a blue dotted underline, via {{glossary link}} and its topic-specific implementations, like {{cuegloss}} is about to become. Hopefully these can also be modifed to show what comes after the # in the line, not just the pagename. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 06:53, 11 May 2011 (UTC)

The only way to show a custom tooltip is to embed a span with it's own title parameter in a link, for example: [[Main Page|<span title="Overridden title here!">Link text here</span>]]: Link text here. This also allows you to apply any styling you want to a wikilink. — Edokter (talk) — 09:35, 11 May 2011 (UTC)

Perfect! You rule. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 02:54, 12 May 2011 (UTC)

@SMcCandlish, I would support setting <dfn> to "normal" as default, and then defining some number of html classes--yet to be determined--that could be used in specific circumstances, defined semantically rather than stylistically (which is what I think you are already starting to do with the html "glossary" class). Once we start talking about semantics (i.e., when to use particular html classes or templates wrapping such classes), rather than mere presentation by browsers, that's when I think the discussion more appropriately belongs in WP:MOS. COGDEN 19:26, 11 May 2011 (UTC)

Re: the dfn element defaulting to "normal" display - Please! This would obviate the need to keep putting that in all the templates that use this element.

Re: MoS - That works for me, mostly (there are cases where presentation is still a MoS issue - like, book titles should be given in italics, not in green strike-through text >;-)

Re: Semantic glossary stuff: I'm pretty much "Mr. Semantic Markup", so I'm definitely trying to do semantic things with the "glossary" class stuff (namely, move all presentational aspects into CSS, and develop templates that use definition lists and dfn precisely as they were intended). I probably would have already asked for a glossary class here, but there's so little styling that actually needs to be applied that it's easier to do it in templates than by making a case for a site-wide CSS solution. Other than this expediency bit, I don't feel strongly about how/where it happens. The templates that would use this class and sub-classes ("glossary-link", etc.) to potentially do something interesting are {{glossary}} (and {{glossary end}}, but it's just a div closure), and {{term}} and {{defn}} (not to be confused with {{dfn}}, inside the gloss/glossend, then {{glossary link}} (and derivatives like {{cuegloss}} will be after some more testing), and its non-dfn counterpart {{glossary link internal}}. So, for example, a revamped (per Edokter hint above) {{glossary link}} would use a span in it with class "glossary-link".

Anyway, I don't need any classes to do what I need to, I think, but suspect some people would prefer it be done that way. I've got some tinkering to do, and can come back here with a list of what's going on with CSS and what CSS might be usefl to put in common.css instead of in inline style in the templates, if that would be helpful.

PS: I tweaked {{dfn}} to behave more consistently, and documented the living daylights out of it.

PPS: I still like the idea, way up there, of having a template intended for the boldfaced term(s) in the lead, whether the CSS for it lives here or not. While it would take a long time to propagate, that's not really a big deal; lots and lots of stylistic and technical changes take a long time to filter through the whole system. I think {{subject}} is available.

— SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 02:54, 12 May 2011 (UTC)

The default style for <dfn> actually needs to be font-style:inherit;. Having nothing causes it to be italicized in some but not all major browsers, as noted already, while using "normal" instead of "inherit", as was suggested, causes it to be forcibly de-italicized in italicized phrases, as I just noticed while goofing around with {{glossary link}}. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 16:49, 12 May 2011 (UTC)

Good point. — Edokter (talk) — 17:23, 12 May 2011 (UTC)

Agreed. COGDEN 22:54, 12 May 2011 (UTC)

Accessibility improvement affecting only citations

Based on the consensus of Template:Citation/core, I will soon be adding what should be a non-controversial addition that improves the accessibility of citations, and has other benefits discussed there.

 /* Default styling for the title of any work within a citation,
 or specifically the title of a periodical: italics */
 .citation cite,
 .citation cite.periodical {
       font-style: italic;
 }
 
 /* Default styling for the title of an article within a
 periodical, or a contribution within a compilation.
 IE6 and IE7 will show unquoted text */
 .citation cite.article,
 .citation cite.contribution {
       font-style: <del>normal</del><ins>inherit</ins>;
 }
 <del>.citation cite.article:before,
 .citation cite.contribution:before {
       content: '"'
 }
 .citation cite.article:after,
 .citation cite.contribution:after {
       content: '"'
 }
 
 /* Default styling for a volume number: bold. */
 .citation .volume {
       font-weight: bold;
 }</del>

COGDEN 07:57, 6 May 2011 (UTC)

I'm all for seperating content and styling, but I do not consider the quotes as styling but as formatting, thus they should stay inline in the template; that guarantees 100% browser support. — Edokter (talk) — 09:42, 6 May 2011 (UTC)

I agree with Edokter - Kingpin¹³ (talk) 10:02, 6 May 2011 (UTC)

In this case, the IE6-7 difference is not a big deal, though if there is a consensus that we should maintain IE6-7 compatibility at all costs even when it doesn't matter that much and the IE6-7 result still looks good, I'll take that part out.

But I respectfully disagree with your opinion that quotation marks are content. Quotes are almost always a matter of styling. How do I know? Because the rendering of quotations changes when the language changes, when the content is rendered by screen readers, and based on context such as when the quotes are nested within other quotes. Both HTML4 and CSS2.1 treat quotes as style, and wrap quote content in <q> tags. Treating quotes as style rather than content is more accessible and more localizable. COGDEN 10:28, 6 May 2011 (UTC)

The language doesn't change much here. And while (text) formatting can be considered a small subset of styling, they remain different beasts. I simply see no benefit in doing something in a way that is not fully supported, while it can be. — Edokter (talk) — 10:42, 6 May 2011 (UTC)

I agree, that's somewhere around 16% of our Wikimedia audience, so about 3.88 million of our monthly unique visitors that we would be giving the finger. I think that is bit much. —TheDJ (talk • contribs) 15:25, 9 May 2011 (UTC)

I don't disagree. My point was that even though IE6-7 shows a different styling, it was still a good styling for those browsers. But given the comments, I'll just add the other styling and leave off styling for the quotes until that 16% gets lower.

@Edokter, given your comments here, it sounds like you have reconsidered your position as to the .hlist styling, discussed above. Does that mean that you think we should just not have any horizontal list styling at all, given that it shows an extra bullet at the end not only in IE6-7, but also IE8? COGDEN 18:39, 9 May 2011 (UTC)

Thats a different íssue. The horizontal lists were introduced for semantic reasons, and as far as I know, there is no workable workaround (yet) to have them rendered correctly under IE6/7. That is not to say I disagree with horizontal lists alltogether. I just think that we should use the most widely supported styling where possible. — Edokter (talk) — 19:13, 9 May 2011 (UTC)

In any event, there has been a need defined at {{Citation/core}} for stylings for a few classes of titles within citations. Unless there are any objections, I'll implement it without the stricken portion relating to the "article" and "contribution" classes, and will continue to have the template do the styling for that, probably until browsers are consistent enough that semantic non-block quoting with the <q> tag becomes possible. I am also leaving out the volume class, because I want some additional discussion at {{Citation/core}}. COGDEN 00:32, 13 May 2011 (UTC)

Toggle tranparency background on file description pages

On the linked bugzilla discussion, there is talk about adding some form of transparency background (the checker pattern) toggle for the main image on file description pages, either in the form of some button or using the :hover selector. I like the :hover approach, which is trivial to implement by simply changing #file img to #file img:hover. Any more comments on a final approach is welcome. — Edokter (talk) — 14:09, 21 May 2011 (UTC)

I wouldn't be opposed to that. Not sure what less experienced editors might think of that however. They might see it as a 'bug' —TheDJ (talk • contribs) 22:36, 24 May 2011 (UTC)

MediaWiki:Print.css

Looks like some markup in MediaWiki:Print.css is now redundant with http://en.wikipedia.org/skins-1.17/common/commonPrint.css:

.wikitable, .thumb, img {
	page-break-inside: avoid;
}
h2, h3, h4, h5, h6, h7 {
	page-break-after: avoid;
}
p {
	widows: 3;
	orphans: 3;
}

---— Gadget850 (Ed) ^talk 14:34, 30 May 2011 (UTC)

Indeed it is. Removed. — Edokter (talk) — 15:39, 30 May 2011 (UTC)

Simplification

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

It seems possible to simplify part of the code added in this edit:

.breadcrumb li a:after,
.breadcrumb li a:before {
        content: " ";
        display: block;
        width: 0;
        height: 0;
        border-top: 50px solid transparent;           /* Go big on the size, and let overflow hide */
        border-bottom: 50px solid transparent;
        position: absolute;
        top: 50%;
        margin-top: -50px;
        left: 100%;
        z-index: 2;
} 
.breadcrumb li a:before {
        border-left: 31px solid white;
        margin-left: 1px;
        z-index: 1;
}

Besides, the long line below the comment

/* Makes it possible for the boxes in the Account Creation Process to overlap */

should probably be split up into multiple lines for better readability. What do you think? Helder 14:14, 31 May 2011 (UTC)

Leave a note to Hannibal on his talk page. Prodego ^talk 19:48, 2 June 2011 (UTC)

Well, the author of that code is actually Fetchcomms, so any comments and suggestions should go to him. I just moved that code here from the outreach wiki. I'll point him here.//Hannibal (talk) 20:40, 2 June 2011 (UTC)

Done. /ƒETCH COMMS / 22:55, 2 June 2011 (UTC)

Infobox/sidebar/... header class

I have noticed that quite a few infoboxes and sidebars are using "background: #ccccff" for the header color. To improve accessibility, I would like to replace these with a CSS class, so that the user can override it. Thus far, I have had success with just using the "navbox-title" class, but this has been resisted in infoboxes since "infoboxes are not navboxes". Would it be possible to add a css class that I can use to accomplish this? My initial count is that there would be around one to two thousand templates which could use this feature. Again, it would be entirely optional, and added to infobox/sidebar templates on a case-by-case basis. I will defer to the experts as to what to call it or how to best add it to the CSS, but one possibility is pasted below. I really don't care what it is called, just as long as it is not explicitly tied to the "navbox" class. If this is possible, it would also be good to have an additional "level 2" version, like say "background: #ddddff", but this can wait. Thank you. Frietjes (talk) 16:33, 9 June 2011 (UTC)

.box-header {
  background: #ccccff;
}

Remove deployed code

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

Hi!

It seems that the code

/* Fix monospace fontsize in new edit toolbar (jquery.wikiEditor.toolbar.css).
   [[Bugzilla:27502]] */
.wikiEditor-ui-toolbar .section-help .page-table td.cell-syntax,
.wikiEditor-ui-toolbar .section-help .page-table td.syntax {
    font-family: monospace, "Courier New";
}

is already deployed (see rev:82533), so it could be removed from MediaWiki:Common.css. Helder 15:11, 30 June 2011 (UTC)

Done. — Edokter (talk) — 15:38, 30 June 2011 (UTC)

Better support for the Gaelic script

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

Hello! I'd like to add some free Unicode fonts to the Gaelic script template in order to improve the font fallback:

.script-gaelic {
    font-family: Duibhlinn, Bunchló GC, Rudhraigheacht UNICODE, Gadelica, Ceanannas, Úrchló GC, Glanchló GC, Corcaigh, Gaelic;
}

Bunchló GC font Gadelica font More info about Gaelic fonts Thanks. — Preceding unsigned comment added by 83.38.112.103 (talk) 05:38, 12 August 2011 (UTC)

Not done for now. CSS for single low-volume templates should be placed inline. — Edokter (talk) — 15:24, 12 August 2011 (UTC)

The actual Gaelic template in WinFixes.css supports only propietary fonts. Bunchló GC & Gadelica fonts are free available ones (more people could use them). Also, can I suggest a Fraktur/Blackletter script template?

.script-fraktur {
    font-family: UnifrakturCook, UnifrakturMaguntia, Fraktur, Germanica;
}

UnifrakturCook & UnifrakturMaguntia (Google Web fonts available for @font-face embedding) — Preceding unsigned comment added by 83.38.112.103 (talk) 01:27, 13 August 2011 (UTC)

Blockquote size

It might be nice to bump blockquotes down to say 95%, just to subtly separate them from the surrounding text. —Designate (talk) 22:49, 25 August 2011 (UTC)

Support. Precedent set by most quote templates. We should also class it so it gets included in Special:Preferences → Gadgets → Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists. ---— Gadget850 (Ed) ^talk 18:49, 4 October 2011 (UTC)

RTL support in 1.18

I have prepared this for when 1.18 is launched here. It should be all that is needed to properly support &uselang=he —TheDJ (talk • contribs) 14:52, 20 September 2011 (UTC)

Fix for mixed secure/insecure content on HTTPS view of pages with some icons

A number of icons are loaded direct off http://upload.wikimedia.org in the stylesheet; this causes mixed-content warnings in many browsers on pages which trigger loading of those icons like McManus House (there's a PDF link in the infobo). Some browsers may have this disabled, so not everyone sees the errors. Swapping the http:// for // makes these load off of either HTTPS or HTTP as appropriate. If no objection (or nobody else applies it first) I'll poke it in in a bit. :) --brion (talk) 23:52, 30 September 2011 (UTC)

I did some testing with personal CSS and a gadget and saw no adverse effects. I'll remove the protocols. — Edokter (talk) — 08:24, 1 October 2011 (UTC)

I switched a couple more, the skins CSS, but also hot cat, utcliveclock, edit.'s and ref toolbar. —TheDJ (talk • contribs) 12:21, 1 October 2011 (UTC)

Looking good, thanks! --brion (talk) 17:51, 4 October 2011 (UTC)

Fundraising page CSS code

Current we have 2 pages with a bunch of page specific css changes (generally hiding the interface) for a couple fundraising tests. So that we can do some A/B testing the creative team wants to create more of these pages (and created the pages) but I don't want to hide the interface for all of them through common.css since it will end up taking up an enormous amount of space. My original thought was putting it all on a separate page and doing an @import but perhaps the new default enabled gadgets are better? I'm probably going to want to do this Tuesday or Wednesday ( Oct 18th or 19th) evening but I wanted to see if anyone had thoughts or preferences. Jalexander--WMF 23:48, 17 October 2011 (UTC)

I support the idea of moving the code to a gadget (enabled or not, depending on the target 'audience'). — Edokter (talk) — 13:31, 19 October 2011 (UTC)

Me too. Helder 13:35, 19 October 2011 (UTC)

PDF icon

Looks like the PDF icon is now in the core stylesheet. Should we clean up here? ---— Gadget850 (Ed) ^talk 14:13, 20 October 2011 (UTC)

It's a different icon. MediaWiki CSS specifies an icon that looks somewhat like

, Common.css overwrites it with

. — AlexSm 14:56, 20 October 2011 (UTC)

Thanks, missed that. ---— Gadget850 (Ed) ^talk 15:25, 20 October 2011 (UTC)

Account creation project code

Can the account creation project code be removed? --MZMcBride (talk) 15:05, 8 October 2011 (UTC)

...or at least moved to a "gadget enabled by default" (bug 13742 was fixed), so that editors can disable it if they want. Helder 15:38, 8 October 2011 (UTC)

I trust it is no longer needed then? — Edokter (talk) — 20:29, 8 October 2011 (UTC)

I don't think we need this anymore but haven't been actively involved in the project. Let me double check and I'll report back/remove if not needed. Jalexander--WMF 23:49, 17 October 2011 (UTC)

Any news? — Edokter (talk) — 19:53, 9 November 2011 (UTC)

Category links spacing

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

There seems to be consensus to fix the category links issues from the 1.18 upgrade at <https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=454644446#Categories_are_surrounded_by_much_more_space.2C_and_they_don.27t_wrap_from_line_to_line>.

I've filed a bug at bugzilla:31547, but if someone could add the code sooner with a comment to remove it after the bug is resolved, that'd be great.

Something like...

/* Remove this when https://bugzilla.wikimedia.org/show_bug.cgi?id=31547 is resolved/deployed */
#catlinks li {
    padding:0 .3em;
    border-color:black;
    display:inline;
}
#catlinks li:first-child {
    padding-left:0;
}

Or some variant. The idea is to at least reduce the excessive spacing. The word-wrapping I'm less concerned about for now. Thanks! --MZMcBride (talk) 02:15, 9 October 2011 (UTC)

That doesn't really fix it for me. It makes the space around the separator lines less, but there is still far too much space between the lines in Firefox, Chromium, and IE9. If we want to get rid of that, set margin:0. Or set display:inline to get rid of that and the no-wrapping at the same time. Anomie ⚔ 03:58, 9 October 2011 (UTC)

That sounds fine to me. I've updated the example code accordingly. Want to push it live? :-) --MZMcBride (talk) 04:31, 9 October 2011 (UTC)

I'm finetuning the CSS right now. I have to check the code against all skins and browsers. — Edokter (talk) — 09:21, 9 October 2011 (UTC)

After some experimenting, all that is needed is to reduce the lineheight and margin of the list item. Therefor the following code will 'fix' the display on all skins:

#catlinks li {
    line-height: 1em;
    margin: 0.25em 0;
    padding: 0 0.5em;
}

#catlinks li:first-child {
    padding-left: 0.25em;
}

Please test by putting it in your common.css and test some skins, then post your findings here. If there are no problem, I'll make it live and submit a patch to bugzilla. Putting the editrequest on hold for the time being. — Edokter (talk) — 09:43, 9 October 2011 (UTC)

I compared your proposal to a version using display:inline (which should closely simulate the pre-1.18 display) using Firefox 6.0.2. The display is identical for chick, modern, monobook, simple, and vector; it has extra space between lines for standard, cologneblue, myskin, and nostalgia. Setting margin:0 instead of margin: 0.25em 0 gives a display identical to my display:inline test for all skins. Anomie ⚔ 15:33, 9 October 2011 (UTC)

I tried display:inline, but that mangles the list in Chrome. I think that is the reason why inline-block was choosen. — Edokter (talk) — 15:46, 9 October 2011 (UTC)

display:inline seems ok in Chromium here if you don't reduce the line-height. I wasn't suggesting to use display:inline, though; I was just using it for testing to try to simulate what MediaWiki used to do. Anomie ⚔ 18:16, 9 October 2011 (UTC)

Ah OK. The purpose of my code is to reduce the the amount of space around the category items, not to perfectly emulate the pre-1.18 behaviour. Having that as a goal will only result in unsightly hacks that will only come back to bite us in the future. — Edokter (talk) — 18:20, 9 October 2011 (UTC)

I wouldn't want to perfectly emulate it either. I mainly care about the excess spacing between lines of text in the category box in Monobook. Anomie ⚔ 18:32, 9 October 2011 (UTC)

Code implemented. — Edokter (talk) — 18:55, 9 October 2011 (UTC)

Excellent! Thank you both for your work on this. --MZMcBride (talk) 15:31, 10 October 2011 (UTC)

Some IE users are seeing the category text with the descenders clipped. See Wikipedia:Village pump (technical)#Category name letters missing their tails. ---— Gadget850 (Ed) ^talk 19:00, 2 November 2011 (UTC)

~~But is that due to the change here, or due to the underlying MediaWiki change in 1.18? Anomie ⚔ 19:25, 2 November 2011 (UTC)~~ Yes, probably the line-height. Anomie ⚔ 19:28, 2 November 2011 (UTC)

Can anyone test (as described above) with margin:1px 0 and line-height:1.35em? It looks fine to me on Firefox 7.0.1 Linux (all skins), Chromium 14.0.835.202 on Linux (vector), and Safari 5.1 OS X (vector). Anomie ⚔ 19:52, 2 November 2011 (UTC)

The problem is only apparent in IE's compatibility mode. Already testing another alternative. — Edokter (talk) — 20:00, 2 November 2011 (UTC)

Duh. But if you fix IE while breaking other browsers, that wouldn't be particularly useful. Anomie ⚔ 20:30, 2 November 2011 (UTC)

Done. I increased the line-height while decreasing the margin to compensate. Seems to be consistent in IE, Chrome and Firefiox. — Edokter (talk) — 20:37, 2 November 2011 (UTC)

Looks good here too. Anomie ⚔ 20:54, 2 November 2011 (UTC)

Non-inline sysop-show

Currently the sysop-show class is only defined to be visible to admins in MediaWiki:Sysop.css, and content that bears it is hardcoded with inline style=display:none. I believe we should define that instead as a class here in Common.css, for several reasons:

inline styles have been discouraged for a while
browsers that don't load css files, such as text browsers, will likely not honor inline styles either (see past discussion)
while inline styles will make the content remain hidden even if the page is exported to / embedded in another wiki or site that doesn't define the same css classes we have here, they won't be shown either for sysops, and being hidden for everyone is definitely bad as fallback behavior.

That said, are there any objections to remove those hardcoded styles and define the sysop-show as display:none here in Common.css? --Waldir ^talk 12:49, 19 October 2011 (UTC)

I like the idea. Besides, if the intent is to make it more accessible, then we should really move MediaWiki:Sysop.css to MediaWiki:Group-sysop.css, as suggested on MediaWiki talk:Common.js#Group-specific JS and CSS, because currently the CSS which restores the visibility of the content depends on a script from MediaWiki:Common.js and will only work if JavaScript is available. Helder 13:49, 19 October 2011 (UTC)

Any other comments? Could this be implemented? Helder 15:54, 9 November 2011 (UTC)

Done. — Edokter (talk) — 16:54, 9 November 2011 (UTC)

Hidden category list in smaller font

One thing I noticed on Commons is that "Hidden Categories" are shown in a smaller font. While one of the reasons for that is because they are displayed by default, which is not the case here. Just wondering what everyone thought about doing that here for those who show the hidden cats. -- WOSlinker (talk) 23:07, 4 November 2011 (UTC)

#mw-hidden-catlinks { font-size: 87% !important; }

I'm neutral to the idea. — Edokter (talk) — 23:21, 4 November 2011 (UTC)
Support, as long as it is spanned with a class and added to NoSmallFonts. We should have a general span class for this anyway. ---— Gadget850 (Ed) ^talk 23:30, 4 November 2011 (UTC)
We can't 'span' it from here, and it's not needed anyway as it has the id #mw-hidden-catlinks attached to it. — Edokter (talk) — 23:46, 4 November 2011 (UTC)
I'll just add it and see if it creates any huffing and puffing. — Edokter (talk) — 20:04, 9 November 2011 (UTC)

"Huffing and puffing" : Awesome ;-) fg ^t _c 00:08, 10 November 2011 (UTC)

First Huff'n'Puff™ spotted. — Edokter (talk) — 00:14, 10 November 2011 (UTC)

Mhmm. I hope your house is made of bricks fg ^t _c

Oppose If people have chosen to display hidden categories, it's because they want to see them. Smaller fonts are an accessibility issue; those marked !important doubly so. What supposed problem does this change serve? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:01, 10 November 2011 (UTC)
- Not all changes are a solution to a problem, but a mere enhancement. The Commons code has !important, but not here. — Edokter (talk) — 11:10, 10 November 2011 (UTC)
  - The display of hidden categories affect only those who enable them through gadgets, so this is going to affect a minority of readers. Font size can be an accessibility issue, which is why we have Preferences → Gadgets → Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists, which does work with hidden categories. ---— Gadget850 (Ed) ^talk 11:20, 10 November 2011 (UTC)
    - Nonetheless, my objection stands. We shouldn't make editors jump such hoops. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:30, 10 November 2011 (UTC)
      - We already make them jump through hoops if they don't like the size on reference lists and other elements, but we have a simple solution. Once again, I will note that Wikipedia:Manual of Style/Accessibility has nothing on minimum font size and I have found nothing on a diligent search. What we don't have is a fix for the myriad of uses of <small> and hard coded font sizes. ---— Gadget850 (Ed) ^talk 12:15, 10 November 2011 (UTC)
        Actually, <small> is caught by the gadget. — Edokter (talk) — 17:29, 10 November 2011 (UTC)
  - Please don't make changes to others' comments, especially when third parties have already commented on them. I've undone your change. In what way does this "enhance" the encyclopedia? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:30, 10 November 2011 (UTC)
Oppose People who see them, want to see them, no point in making them smaller and more difficult to read. —TheDJ (talk • contribs) 16:09, 13 November 2011 (UTC)

No consensus then, removed. — Edokter (talk) — 16:31, 13 November 2011 (UTC)

"Is IE really this stupid???"

Yes. f g 18:32, 14 November 2011 (UTC)

Retarded IE is retarded. Apparently, it does not understand combined declarations if one of them has a selector it does not understand (:last-child), even though it has no problem doing so in compatibility mode. Go figure... OK, I'm done testing. — Edokter (talk) — 20:16, 14 November 2011 (UTC)

I gave up pandering to IE a long time ago. I tried at first but so much either didn't work or needed to be specially coded for each and every version, I just gave up. If MS can't follow standards instead of inventing their own then as far as I'm concerned they lose. More people are moving to Linux and/or Mac OSX and so don't have IE thrust upon them. More people are choosing other browsers even when they are using Windows. Eventually MS will have to bite the bullet one way or another. Either make IE work with the standards like WebKit or Gecko or kill the project and concentrate on operating systems.

The fact that WP has to pander to MS and its insane browser just makes your job so much more awkward. I feel your pain. My CSS know-how is backward compared with yours (from what I see), otherwise I would offer some help. Best of luck. Long live Chrome! f g 21:00, 14 November 2011 (UTC)

What would Vicky say? The truth of it is: They make it so, deliberately. Me, me, me; pay-attention-to-me. They want to be pandered to, to be catered to. Alarbus (talk) 23:24, 14 November 2011 (UTC)

Flatlist css tweak

We have a class .hlist that displays a list horizontally with an appropriate separator. That class is used extensively and successfully in Template:Flatlist which is transcluded into Template:Navbox. Looking at its use, it seems that the preference is always to constrain list elements so that they do not wrap across lines, and that line breaks should only occur between list elements. I would suggest that rather than transcluding {{nowrap}} multiple times (with its associated cost), we would be better off by including the declaration white-space: nowrap; in the definition of .hlist li so that it becomes the default for these list elements. Clearly it can be overridden at a lower level should the need arise, but it seems to me to make sense having the overwhelmingly most common usage as the default. What do others think? --RexxS (talk) 17:07, 29 August 2011 (UTC)

Flatlist doesn't work in many of the browsers that still are in use. I find it wrong that millions of seeing users should see broken lists, when all that flatlist does is that a small number of blind users don't have to hear the word "dot" if they bother to listen all the way down to the navbox at the bottom of articles. So flatlist should not be used at all.

Note that many users can't change to another browser since they are not admins on the computers they use. (Work computers, public computers, school computers, and so on.)

--David Göthberg (talk) 18:42, 4 October 2011 (UTC)

Flatlist does not produce broken lists, as the code is fully W3C standards-compliant. Only Internet Explorer fails to render the background images accurately in certain configurations and then it is only a small misalignment that affects hardly anybody, since it does nothing to alter the information presented. However, Flatlist does much more than remove the annoying "dots" - it actually produces a list of the items, rather than a single, unbroken line of text with unwanted characters between every item. That not only improves the accessibility of the list, but also allows re-users of our content to have semantically accurately marked up lists. Of course, it's easy for sighted users to fool themselves that their bad editing habits don't matter because it only affects "a small number of blind users", but actually it affects all blind users, who – unlike the rest of us – really don't have an alternative available. --RexxS (talk) 19:06, 4 October 2011 (UTC)

Is there a discussion with samples of the issue? Other than the IE dots? ---— Gadget850 (Ed) ^talk 18:50, 4 October 2011 (UTC)

As usual the "usability jihadists" speak with a twisted tongue:

1: There are several other browsers than IE that has problems with flatlist. Older versions of all browsers have problems with it, including Firefox.

2: The CSS primitives used in flatlist are a fairly new standard. Those primitives weren't in the standards some years ago. So "standards compliant" is not the same thing as "works everywhere". Browsers should try to support the latest CSS stuff, while web sites should try to use only the slightly older CSS stuff so older browsers can render the page.

3: Reusing our horizontal lists are not an issue, since other web sites should not reuse our navboxes.

4: No, it doesn't affect all blind users for several reasons. One being that blind users I have talked to say they rarely bother to listen all the way down, since they are interested in the article text, not the stuff at the bottom of the article such as the often huge lists of references.

5: I have repeatedly suggested a better solution where we add four lines of CSS in Common.css which will allow us to mark content that should not be read by screen readers. Then we could mark the dots in the navboxes so they will not be read out loud. But the usability jihadists don't want that, and one reason they stated was that such markup won't work if the blind user uses a very old browser... See the archives of this page for that code suggestion.

--David Göthberg (talk) 20:01, 4 October 2011 (UTC)

Please consider these points:

1. Firefox has supported last-child since version 1.0 in 2001 (although it was not completely bug-free until ver 3 in 2008). Opera has supported it since version 9.5 in 2005. Safari since ver 3.1 (2008) - and Chrome has always supported it. ref

2. The CSS primitive called "last-child" is the only one that IE has problems with and is the newest. It was introduced in this W3C document in 2001. That's TEN years ago.

3. {{Flatlist}} (and more relevantly, the .hlist class) are available for use in any list that is to be displayed horizontally, not just Navboxes. You need to expect others to reuse any of our content containing lists – including those that our editors choose to display horizontally.

4. It's not true to assume that Flatlist is only used in navigation at the bottom of pages. Even if it were, the argument that blind users rarely read to the bottom is matched by the identical argument that sighted used also rarely read to the bottom, so they won't see any misaligned dots in IE.

5. I'll try to find the discussions you refer to, although it would be easier if you could post a link. We might be able to resurrect something useful, although you really do need to understand that this isn't just a question of a non-visual agent reading dots - there's also the important issue of making sure that lists are lists, rather than huge strings of unpunctuated text.

Microsoft has abused its near monopoly position in operating systems to push a buggy, insecure, non-standard browser on the general public. Normally this is not a problem, but in this specific case, the lack of support for a ten-year-old standard has a negative impact on disabled users, and I for one am not inclined to overlook their shortcomings in that respect. --RexxS (talk) 22:03, 4 October 2011 (UTC)

I generally agree with all the factual points you raise, although I think many people would agree that the tone of this response is scarcely any better than David's: it is unnecessarily aggressive for someone who, I think, is usually very polite. Your argument can easily stand entirely on its own merits; it is only weakened by diversions to pick at David's individual phrasing. Regardless of any of the merits or demerits of either argument, if you encounter a comment that you believe to be uncivil or otherwise inappropriate, you should always seek to rise above it. Of course, perhaps this comment would be seen in the same vein; that's the risk we all run with online interactions... Happy‑melon 22:25, 4 October 2011 (UTC)

You're quite right to admonish me and I apologise to David unreservedly. I've removed my incivil comments (rather than struck them), and hope you will accept that it was solely because I was having an unusually bad day. Thank you for your gentle reminder. Cheers --RexxS (talk) 14:45, 5 October 2011 (UTC)

We're all entitled to bad days once in a while :D Happy‑melon 17:37, 5 October 2011 (UTC)

FYI, the Categories list in 1.18 will use a similar type of styling but with borders instead of backgroundimages, and first-child.. —TheDJ (talk • contribs) 23:32, 4 October 2011 (UTC)

I'm the original proponent of {{flatlist}}, so I guess that makes me one of what David would call a "usability jihadists" (though I didn't get the memo saying that WP:AGF and WP:CIVIL had been rescinded. And perhaps we need an equivalent of Godwin's law for references to Islamic fundamentalism). None of David's objections address the fact that the template uses semantically-correct list markup, rather then the previous fudge. For how long are we supposed to disregard web standards in order to pander to users of buggy and superseded browsers? May we now return to the original proposal in this section; regarding the use of {{Nowrap}}? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:15, 10 November 2011 (UTC)

This isn't needed, and probably never was, because there is already a CSS declaration .nowraplinks a { white-space: nowrap; } in common.css, and used in {{navbox}}, that prevent any wikilinks from wrapping. So any use of {{nowrap}} can be removed. Also, the need for {{flatlist}} in navboxes is also redundant by adding listclass = hlist. — Edokter (talk) — 11:33, 10 November 2011 (UTC)

This is needed. The purpose is to extend the nowrap to the whole list-element, not just the actual link. A typical use would be:

Slaughterhouse-Five (1969)

In an hlist, it would be better to not have to use nbsp or some template to keep these together.

listclass = hlist looks interesting. Support for it will have to be added to other navboxish templates, too, or passed-through; {{navbox subgroup}}, &c. {{military navigation}} and others would need a pass-it-along approach. Alarbus (talk) 12:15, 10 November 2011 (UTC)

I just made this use listclass = hlist:

{{Kurt Vonnegut}}

It can drop years away from titles even though they're in the same list-item (play with browser window size). Alarbus (talk) 12:28, 10 November 2011 (UTC)

OK, I see the problem with wrapping. I ammended the CSS rule so horizontal list items no longer wrap in navboxes. — Edokter (talk) — 14:17, 10 November 2011 (UTC)

Thanks. You just fixed tens of thousands of templates that didn't have nbsp/nowrap and obviated hundreds of thousands of uses of those. People need to know about this so that many start cutting the un-needful bits. I'm so late... Alarbus (talk) 14:24, 10 November 2011 (UTC)

Do we now need a bot to remove such unneccessary markup? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 14:54, 11 November 2011 (UTC)

That would be awesome ;) Alarbus (talk) 14:57, 11 November 2011 (UTC)

Slight clarification: only where hlist (or flatlist) is used will items no longer wrap. Navboxes that are not converted yet still need these nowrap/bullet templates. However, since links are automatically no-wrapped, those navboxes that only show links (without any suffix) would not need them. — Edokter (talk) — 15:14, 11 November 2011 (UTC)

I was thinking that the bot would be adding the hlist class as it removed nbsp, {dot}, and {nowarp begin/end} [sic;]. For huge numbers of single list navboxes, it should be a bot-task. Once the Use-The-Button notices are being served to IE users in the same manner as the beg-a-thon-banners, of course...

nb: the /doc page is still calling those 'recommended', which it shouln't be. I saw class horizontal on-offer on a MOS page (changed it, too). Alarbus (talk) 15:25, 11 November 2011 (UTC)

An elegant solution. Thank you. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 14:54, 11 November 2011 (UTC)

listclass = hlist doesn't work for |above= or |below= (see, for example {{Pink Floyd}}. Can we make it do so? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 15:43, 11 November 2011 (UTC)

That is correct behaviour. Use aboveclass and belowclass (or bodyclass for the whole navbox) instead. — Edokter (talk) — 15:52, 11 November 2011 (UTC)

re nowrap on whole list-items, again: Here, it insures that the quotes stick with the links. Before, most browsers figured it out on their own, but one didn't. Alarbus (talk) 16:09, 11 November 2011 (UTC)

also posted at Template talk:Navbox#Wrapping issues

An editor comment to me that he's seeing {{campaign}}-boxes widen when [show]n, when in IE's do-it-wrong-mode (my term). Seems to me that their old-school mode might be getting the recent white-space: nowrap; tweak inadvertently applied to the ul/ol elements. If so, something like:

.hlist ol,
.hlist ul
{
 margin: 0 !important;
 white-space: normal; // for old-ie-modes?
}

might help. Might help to use !important, too. Alarbus (talk) 05:05, 12 November 2011 (UTC)

flatlist padding

0.7em for right

I'm thinking that should be moving in the other direction, say from 0.6em to 0.55em, not to 0.7em. This should be accompanied be a tweak to the middot:right positioning to move the middot in a few pixels from the right of the list-item's padding; say about 0.1em (or -0.1em — would have to try it).

Here, group-padding was set to a non-default, and I've seen this done on list-padding, too. If there's any real merit to this sort of padding adjustment, it should be made in the CSS. Ditto re the line-height stuff, of course. It's crazy to have endless thousands of tweaks out there. Too many people are tweaking to match their specific machines and browsers.

And whatever happens here, the class horizontal should be kept in sync with hlist... no?

Alarbus (talk) 03:34, 11 November 2011 (UTC)

I'm still tweaking for optimal padding. Decreasing it will leave too little space between the items. Since the image is fixed, 8px results in the most consistent results across browsers. IE in compatibility mode remains a problem with it's padding and wrapping. I have no way of counteracting that (which is why I would really like the site to serve HTML5). I think .horizontal is deprecated. — Edokter (talk) — 10:14, 11 November 2011 (UTC)

I'd like to see HTML5 served, too; it would sort some IE-oddities. I mostly see the middot a hair-off to the right. I was only suggesting a very slight reduction, but am not specifically concerned about the gap-width; the centering is the issue, which is why I suggested not hard-abutting the image (which you see has 1px transparent around the actual 2px-square dot). Rather than position it hard-right against the list-item's right-padded box, step it in a bit from the edge. I'll try a few things and may post an example tomorrow. Maybe horizontal should simply be removed, or added to the hlist selectors as an alias. Alarbus (talk) 10:38, 11 November 2011 (UTC)

'ordered lists should never be horizontal' (without numbers)

See^diff

Not going to be common, but if a set of items has a natural order, then it should be an ol-structure (#) even if the numerals are not displayed.

The 8px is probably for the best; browsers zoom-well, these days. Alarbus (talk) 10:57, 11 November 2011 (UTC)

Why not? It's perfectly reasonable to display ordered lists horizontally, with no numbering: The Olympics were held in …1972 - 1976 - 1980 - 1984 - 1988 - 1992… Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 15:43, 11 November 2011 (UTC)

I agree; that's Edokter's edit summary I quoted. I think support for ordered-lists should be maintained. There won't be very many, but the appropriate ones should be done-up w/'#'. Alarbus (talk) 15:51, 11 November 2011 (UTC)

I just can't see any benefit of using a numbered list without any numbers showing... That would create an accessability issue. How about a flatlist that actually showed some numbers? — Edokter (talk) — 16:18, 11 November 2011 (UTC)

It's proper semantic markup. The numbers (and bullets, on ul) are just presentational. Anyway, all you cut was the margin; hlist'd ols still work as ul and ol share the li element, and that's all still present. Alarbus (talk) 16:32, 11 November 2011 (UTC)

They're ordered lists, not numbered lists; where the sequence is significant. How could displaying them horizontally, or without numbers, cause an accessibility issue? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 17:32, 11 November 2011 (UTC)

Because I wouldn't see the numbers, therefor, some vital information is obscured; ie, it would be impossible to refer to a specific (numbered) item ("look at item #4"). — Edokter (talk) — 19:33, 11 November 2011 (UTC)

(←) Et voila! A proper ordered flatlist!

Item one
Item two
Item three
Item four
Item five
Item six
Item seven
Item eight
Item nine
Item ten
Item eleven
Item twelve

— Edokter (talk) — 20:49, 11 November 2011 (UTC)

No; there is no requirement in any web markup- or accessibility- standard to display numbers for ordered lists, that's merely the default state, and the fact that CSS provides the capabilities to overwrite it shows that that was what the spec's authors intended us to be able to do. The list of years I gave as an example above is clearly ordered, even without number prefixes (indeed, it would look silly with them). By comparison, an unordered list of things I like to eat (cheese - apples - cake - chocolate) makes exactly as much sense in any other order (for example: apples - chocolate - cake - cheese). Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 00:12, 12 November 2011 (UTC)

↑↑↑ What-he-said. using numbers is a good option, and I'd be fine with it being optional. It looks fine and will be useful in some cases (praising the work, but not making it ambient). But I think it inherent in the use of the word 'flat' here that the intent is to be compact (and inline, of course). So 'flat' lists are about moving away from the ul/ol blocks and ornaments to an inline form focused on presenting concise boxfuls of links.

Are there any known instance of this out there (now with numbers)? Alarbus (talk) 01:00, 12 November 2011 (UTC)

There are lots of lists that possess an order, and they should all be marked up with # (i.e. the list becomes an ol in the output html): this won't cause accessibility issues (as Graham87 and other non-visual agent users expect to hear an ordered list in those cases). Failing to use an ordered list will sadly result in violations of meaningful markup though. Not all ordered lists are numbered, of course - just consider the Otto cycle:

It really doesn't want the numbers - they incorrectly indicate a 1-2-3-4 order to what is actually a cyclic ordered list: It doesn't matter which we choose to be first, but they have to be in that sequence. Phases of the moon; seasons, etc. are similar: ordered, but unnumbered. What do others think? --RexxS (talk) 01:29, 12 November 2011 (UTC)

I think ordered lists should be able to be numbered sequentially, but that in the context of hlist it should not be the default. Add class holist (it just happened) to add-back numbers. Might want them followed by a colon or period... Alarbus (talk)

I have to disagree with flat ordered lists not being numbered. The fact that normal ordered lists are numbered by default is enough evidence for me to number the ordered flatlist as well. The CSS specs never considered horizontal listst to begin with, let alone that they should be without numbers. The fact is simple; if you don't want numbers, use * instead of #, otherwise, put the items in the right sequence (the browser does not order them for you). — Edokter (talk) — 08:59, 12 November 2011 (UTC)

You are of course entitled to disagree; but in doing so, you're making the (sadly all too common) mistake of confusing presentation and semantics. Please reefer to the HTML specifications and see whether you can find anything there to support your arguement. You won't. You're wrong. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:17, 12 November 2011 (UTC)

I don't know any better then that ordered lists are numbered. If you have any evidence that says otherwise, then please kindly point me toward it instead of stating I am dead wrong, because I am not. — Edokter (talk) — 12:37, 12 November 2011 (UTC)

w3schools is notorious for its poor advice. It's also nothing to do with the standards body the W3C. I refer you again to the HTML specifications, which - deliberately - say no such thing. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 15:07, 12 November 2011 (UTC)

Then you are not looking close enough. This text comes directly from W3C's XHTML Working Draft: "Ordered and unordered lists are rendered in an identical manner except that user agents MUST by default number ordered list items. User agents may present those numbers in a variety of ways. Unordered list items are not numbered." (emphasis mine). So again, I am not wrong. — Edokter (talk) — 15:50, 12 November 2011 (UTC)

I am also not going to discuss this any longer. I gave Wikipedia the option to use a sematically correct and now established standards complient, ordered horizontal list—a feature that has never been used before—and all I get is bitching about how ordered lists should not be numbered. You don't have to use it, you know? Just go back to using the old unordered lists. I don't effing care anymore. — Edokter (talk) — 15:58, 12 November 2011 (UTC)

The text you cite includes the words "user agents … by default". Wikipedia is not a user agent and we are not discussing user agents' default behaviour. Its also the spec for XHTML2, which we don't use (and nor does almost everybody else). And I think you'll find that I was the originator of horizontal lists. But Alarbus's point, below, is a sound one. We need to work together to inform the community about the importance of semntically-correct and accessible markup. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 16:25, 12 November 2011 (UTC)

"Wikipedia is not a user agent" is irrelevant. Flatlist is a hack, but it is still an OL, thus it must be numbered. And practically every draft version carries this comment. In short, OLs should be numbered by default. — Edokter (talk) — 16:57, 12 November 2011 (UTC)

"Wikipedia is not a user agent" is very relevant, given that the only evidence you have provided to support your assertion that OLs "must be numbered" is an instruction to user agents. It's no different to saying ULs "must have bullets". Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 17:07, 12 November 2011 (UTC)

But ULs must have bullets! No, what I'm saying is user agents, are expected to show numbering, and users expect to see them, so that is what I'm serving them. There is no point is deviating from established practice, especially when presenting something that has essentially never been done before, such as horizontal lists. — Edokter (talk) — 17:18, 12 November 2011 (UTC)

See Google.com; the menu is an OL sans-numbers. Apple.com uses UL, so does MS; no bullets. Just sayin. Alarbus (talk) 17:30, 12 November 2011 (UTC)

What you're serving?! User agents are expected to show numbers by default - not when they are told - by styles - to do otherwise. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 19:36, 12 November 2011 (UTC)

I think you (Edokter) should be congratulated for working so hard and diligently on this project. Don't let bitching put you off or down. You don't need to defend your actions or choices, they speak for themselves. Have a good weekend. f g 16:52, 12 November 2011 (UTC)

Chill, gentlemen. It's not about who's right, it's about what's right. Of course default OLs get numbered, ULs get • The words ordered and numbered are related but not synonymous. UL/OL/DL are used for all sorts of things without their default presentation. You can layout whole pages with them. I especially like using DL/DT/DD. Consider recasting the navbox tables as DLs; the groups as the DTs; the DDs as the lists. Anyway...

That other page is due to get a lot of traffic, soon, due to being listed in {{centralized discussion}}. Like it or not, the template talk:Navbox#Wrapping issues thread is where you are both needed, now. Alarbus (talk) 16:10, 12 November 2011 (UTC)

It's about to become moot; my CSS hack seems to work. — Edokter (talk) — 16:57, 12 November 2011 (UTC)

I see the posts, saw your css edits. Good work. Alarbus (talk) 17:30, 12 November 2011 (UTC)

An inline string of words without numbers is a great deal less obviously a list than when each entry is numbered.

An
inline
string
of
words
without
numbers
etc

Without the numbers the list simply looks strangely punctuated. f g 13:12, 12 November 2011 (UTC)

We're taking about lists which could be included in navboxes; for example, the lists of albums in {{Pink Floyd}}, in chronological order, should be an ordered list. Why would they need numbers? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 15:07, 12 November 2011 (UTC)

And here's another good example: {{Edmonton elections}} - one of many like that, no doubt. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 16:21, 12 November 2011 (UTC)

If the content of a list is self-evidently ordered, you don't necessarely have to use an ordered list. — Edokter (talk) — 17:21, 12 November 2011 (UTC)

Again, please cite the parts of the HTML specifications which you believe support your argument. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 19:36, 12 November 2011 (UTC)

I don't have to. Please come up with evidence of why we should deviate from standard practice instead. — Edokter (talk) — 19:48, 12 November 2011 (UTC)

You do, if you wish to assert that it's "standard practice"; it isn't. And I and others have already given examples where unnumbered, ordered list are needed. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 20:42, 12 November 2011 (UTC)

Every draft/specification I have looked through on w3.org says that ordered lists are/should/must be numbered by default (here is the current HTML4 specification, I couldn't find XHTML1). Your refutal below ammounts to nothing but a stated preference to have an "unnumbered ordered list", which is a contradictio in terminis in itself. I have cited the specs, which you are choosing to dismiss as "irrelevant".

A horizontal ordered list is still an ordered list. The fact that bullets and numbering do not show is because we use a CSS hack to display the list inline. The bullets for UL were replaced with interpuncts, now the numbers have been put back for OL. Semantics mean shit to me if I can't see information that is relevant. If the numbering were removed, we'd have the insanely ironic situation where the blind hear the numbers, but the seeing can't see them. How can that possibly be semantically correct?

It is standard practice, backed up by the W3C, that oredered lists are numbered, and that exceptions must be motivated. I stand by that practice. If you wish to have unnumbered list items, use unordered lists. If you still disagree, my final suggestion is to conduct an RFC. — Edokter (talk) — 21:49, 12 November 2011 (UTC)

None of the specifications ("recommendation" in W3 parlance) uses the word "must" with regard to displaying numbers for OLs. The section in the HTML4.01 spec which you site carries the following caveat: "Note. The following is an informative description of the behavior of some current visual user agents when formatting lists". The word "informative" in this context has a very specific meaning: informative material is not essential to implementing a recommendation. Or, as our own article has it: "W3C also publishes various kinds of informative Notes which are not intended to be treated as standards". You have provided zero evidence that the visual numbering of OLs is a requirement of either the HTML specs or accessibility guidelines. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 22:06, 12 November 2011 (UTC)

By that rationale, nothing is standardised. Let's just throw all web standards overboard, because they obviously serve no purpose. — Edokter (talk) — 22:24, 12 November 2011 (UTC)

(edit conflict) I don't think that any HTML spec has ever made anything mandatory; it's always been a set of non-binding recommendations, which is why Microsoft have been able to go their own sweet way for so long.

Ordered lists don't have to be numbered; most browsers will by default number the list items using Arabic numerals. The list items may be distinguished by other methods: roman numerals (upper or lower case) and Latin letters (upper or lower case) are the other common forms. The one which should be used is usually specified in the CSS (prior to HTML 4 the TYPE= attribute of the <OL> tag had this function). --Redrose64 (talk) 22:30, 12 November 2011 (UTC)

Also as already suggested, if you don't like it don't use it. The examples you gave aren't broken by Edokter's work so no harm, no foul. The cite you wanted has already been provided ie. and relax. Aside: I just found out href can be used as a li attribute in the same way as with a. Cool. f g 19:59, 12 November 2011 (UTC)

As the original proponent of using horizontal lists, and as I have refuted that irrelevant citation, above, I think I'll ignore your suggestion. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 20:42, 12 November 2011 (UTC)

Numbering is now optional and is enabled by adding the hnum class. — Edokter (talk) — 15:44, 16 November 2011 (UTC)

Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:23, 20 November 2011 (UTC)

Definition lists

Is there any demand for a flat definition list? I have the CSS ready. — Edokter (talk) — 09:58, 13 November 2011 (UTC)

I peeked. Yes, please. It would function as a lightweight group:

group · item1 · item2 · item3

Alarbus (talk) 10:28, 13 November 2011 (UTC)

We

should
be
- able
to

mix
things
up

Alarbus (talk): 10:46, 13 November 2011 (UTC)

(and generated content such as parens would be cool)

You mean everything on one line? That could be done, but there would be no interpunct between the several list types. — Edokter (talk) — 11:03, 13 November 2011 (UTC)

I was just mulling on the possibility of allowing anything allowed in other contexts — and somehow 'flatten' it... The DL will have direct applicability in current boxes; I'll have to rummage around to find an example. The generated parens would be nice (IE; I know...) for sublists. Some mixing-it-up will likely prove useful, so it should be tried-out. I did, on my talk. More, another day.

a heads-up; I noticed that groups are getting the nowrap from a class placed in the overall table. This might not be such a good thing; I was trying to remove some br-tags from long group-text and declare the groupstyle to be white-space:normal and it wouldn't because of the class. My intent was to allow the browser to apportion the width per the content, which would have ment it typically would have wrapped the long group-text wo/BRs. I didn't save it. And I'm not keen on the blue middot; it's pretty much the link colour, but it's not a link. The black was to match normal text, which does appear with some frequency in navlists (the Slaughterhouse-Five years). Alarbus (talk) 11:49, 13 November 2011 (UTC)

That's odd. A groupstyle (=inline) should override the default styling from the navbox-group class. As for the blue middot; I choose the color inspired by the list bullet, not the link color. The dot is so small I can hardly see the difference anyway. Also, how would the generated parenthasis look like? — Edokter (talk) — 12:07, 13 November 2011 (UTC)

It's the class targeting the a-element, not the td-cell; can't override that. Saying 'group' was wrong; I meant links in groups. I know the usual bullet is blue, too, but it's also about the same as an unvisited link. I run zoomed all the time; the ambient stying is much too small; and I have browser prefs set to font-size:18pt; You said somewhere that the middot doesn't scale; nope, it does, at least for some of us. The px offsets are scaling well, too.

For sublists:

Main1
- sub1
- sub2
- sub3
Main2

I'd expect something like:

Main1 · (sub1 · sub2 · sub3) · Main2 ...

Obviously, you-know-what won't do the parens as generated content. I've seen a lot of such wrapped with small, which I hate, and parens-in-the-content. Maybe generating them is not best; some convention of including them in the text (this they can use {braces} if they prefer). Off, now. Alarbus (talk) 12:25, 13 November 2011 (UTC)

Don't confuse scaling with zooming; the first relates to font size alone (set by either the site or browser), while the second is the browser scaling every element on screen (including images etc.). As for sublists, a sublist is issentially a new list, and I cannot detect when a new lists start as a sublist in CSS (perhaps in CSS3, but that is not IE<8 compatible). I think we're stuck with no-nesting for now. — Edokter (talk) — 16:54, 13 November 2011 (UTC)

DL example

{{Campaignbox Peninsula Campaign}}: this, my friends, is a flat definition list; and this, is nested flat definition lists; the DD of the outer on is the whole inner DL, which does not have its own DT

The above are two takes on flat definition lists. The first merely gets bold for the DT and middots for interpuncts, including between the DT and first DD. The second gets generated parens, but gets there by using double-colons; i.e. a whole nested DL without a DT on it. Comments? Am I missing something? Alarbus (talk) 07:20, 17 November 2011 (UTC)

That is correct behaviour. DT and DD are interchangable list items within a DL list. — Edokter (talk) — 10:34, 17 November 2011 (UTC)

Inline nesting

You'll need to be careful about making *everything* inline. Many boxes are using separate ULs in the same list to effect an implicite line break; i.e. relying on the UL/OL being a block-element. Before, these were implemented as sequences of {{flatlist}} {{flatlist}}. w/inline on UL/OL, div-wrappers or BR-tags will have to be added. gotta go... Alarbus (talk) 12:12, 13 November 2011 (UTC)

I'm running into too many problem mixing the different liststyles inline anyway. So, mixing an nesting flatlists is not possible. — Edokter (talk) — 12:22, 13 November 2011 (UTC)

I'll try and put something together. Nothing is impossible ;) off... Alarbus (talk) 12:29, 13 November 2011 (UTC)

Can you give me examples where these boxes rely on inline lists being block elements? I'm running into problems where displaying them inline would actually solve more problems, like {{Prince singles}}. — Edokter (talk) — 15:04, 14 November 2011 (UTC)

I'll look for live examples; they're not too common. They go something like the box I've mocked-up. For whatever reason, someone wants to start the list over again. In the {dot} style, they would have been using br-elements, and I converted a few to sequences of {flatlist}s; in the hlist scheme of things, it would be a pair of ULs delineated by a blank line. And see User talk:Pigsonthewing#User:Cartoon Boy/User talk:69.210.140.154 for the cartoon boy with a lot of IP being disruptive about hlist et al. See hist of {{Kiss}}... (example is hacked-up version of {{Campaignbox War of 1812: St. Lawrence Frontier}}, which doesn't really do this pair-thing). Oh, and the Prince page should be DL'd... on it. Alarbus (talk) 15:27, 14 November 2011 (UTC)

See here; {Prince singles}. It needs a mechanism to not always bold the DT; class dtnobold? The newlines are what delineate the discrete lists. Alarbus (talk) 15:57, 14 November 2011 (UTC)

Not another class please; too complicated. If all horizontal lists were diplayed inline, a simple <br> can force a new line, and one could use ** to delimit sublists inline (instead of using ; and :). — Edokter (talk) — 16:13, 14 November 2011 (UTC)

Note: Not meaning to seem prissy but: we should be using <br /> now. f g 16:28, 14 November 2011 (UTC)

Oh, shut up... :) — Edokter (talk) — 16:33, 14 November 2011 (UTC)

f g

then i don't have to say it... Alarbus (talk) 23:47, 14 November 2011 (UTC)

I think I have a solution; I can diplay nested lists inline, while an empty line would still start a new list on a new line. Putting in the code now., then test with {{Prince singles}}. — Edokter (talk) — 16:33, 14 November 2011 (UTC)

this is useful, and {Prince singles} is looking nice with it. Will be looking further. (the':' is not part of the list-item, it's presentational and should be generated.) Alarbus (talk) 23:47, 14 November 2011 (UTC)

(←) OK, I came up with this, but IE8 does not understand the :last-child selector (surprise), and IE6/7 do not understand any of it. Also, pondering if the bullet is needed.

.hlist ul ul li:first-child:before {
  background: url("//upload.wikimedia.org/wikipedia/commons/d/da/Middot-blue.png") no-repeat left;
  content: "(";
  padding-left: 6px;
}
.hlist ul ul li:last-child:after {
  content: ")";
}

I could hack a some jQuery together, but is it worth it? — Edokter (talk) — 00:20, 15 November 2011 (UTC)

definitely a futuristic-step (and syntaxhighlight is cool). Not sure if this is live, yet, but embellishment like this (and the colons I was referring to) are simply what's coming. See: Wikipedia:Wikipedia Signpost/2011-11-14/Technology report re 'Athena' and "graceful enabling". Generated code is an appropriate paradigm, and if retarded browsers don't display it; too bad, they just don't get the enhancement, but they still get the content, which is the mission. If users of defective equipment seek to add such enhancements by old-school mechanisms (resulting in, say, duplicate parens or colons), then they're being disruptive (albeit, many will be doing so in good-faith, and should simply be informed, and gently restrained). Let's go; go, go, go. Alarbus (talk) 01:01, 15 November 2011 (UTC)

It's not live (but you can test the code in your CSS). It may look pretty, but there is no established way of showing nested horizontal lists (interpunts? parens?). We're basically inventing it here. I'd like some more input before we go any further. — Edokter (talk) — 01:16, 15 November 2011 (UTC)

I'm busy, ATM; I'll give it a better look and test-out, later. {{Quentin Tarantino}} would be a typical sort of nested-list example; specifically the two volumes of Kil Bill in the first group. It's and-old-school {dot} thing, now, but it uses parens (twice: vols, years) for parenthetical information, which amounts to the same sort of subsidiary nature that a nested list entails. There might be some other sort of interpunc that would look ok, but parens are all over and would be the easiest-sell. I would expect the mark-up of a next-generation {Quentin Tarantino} to include Kill Bill as something like this:

Kill Bill
- Vol. 1
- Vol. 2

- 2003
- 2004

Kill Bill
- Vol. 1, 2003
- Vol. 2, 2004
foo
bar

Kill Bill
- Vol. 1
- Vol. 2

- 2003
- 2004

Kill Bill
- Vol. 1, 2003
- Vol. 2, 2004
foo
bar

The second form is more practicable, as I'm not seeing how we might indicate a sequence of two nested list.

The rendered output would be something like:

Kill Bill (Vol. 1, 2003 · Vol. 2, 2004)

with this set-off from the ones before and after with middots.

Alarbus (talk) 02:11, 15 November 2011 (UTC)

I've tweaked the example above, as I'm looking at it through your css. The second example is close; it renders as:

Kill Bill · (Vol. 1, 2003 · Vol. 2, 2004) ·foobar

The new 'foobar' item is getting the dot tight against the left-edge. I've tried a few local css tweaks, but am not happy with them. I'm seeing some extra space on the right-end of the first-level LI that the nested UL/LIs are in, and this is what's shoving the dot off to the right. I'm not seeing what this space is; it's about a half-em. Hope that helps. Alarbus (talk) 05:32, 15 November 2011 (UTC)

Slightly tangentially, I can't remember if I posted some of the solutions I found to IE's lack of support for :last-child. Older IE (and retarded mode) recognise the keyword 'expression' in style sheets (and proper browsers ignore it). It's buggy, but can be used to do things that are useful. Here's an example from User:RexxS/monobook.css that's intended to remove the dot at the end of the list:

.hlist li {background-image: expression(this.nextSibling==null?'none':'');}
.hlist li {padding-right: expression(this.nextSibling==null?'0em':'0.4em');}
.hlist li {margin-right: expression(this.nextSibling==null?'0em':'0.2em');}

The javascript inside the expression can't be complex, but the idea is to switch between two values depending on whether you're at the end of a list or not. The technique isn't perfect, but it might be worth remembering when IE is causing you problems as it helps to cater for IE users who can't get their browser into standards mode! --RexxS (talk) 02:37, 15 November 2011 (UTC)

The dot against 'Foo' is actually the one from the parent list item ('Kill Bill'). I don't seem to be able to make it align correctly against the next parent item ('Foo'). This is getting too complicated, so I'm afraid generated parenthesis are a bridge too far. The code required is just not justified. So I have to freeze adding features, and we will have to make due with what we have. — Edokter (talk) — 11:05, 15 November 2011 (UTC)

Allright, I managed it after all, with help of some jQuery. IE<8 will not show the parens, but it won't break either. No more hlist coding for me; the nested listing was the hard part, but it should accomodate most common uses. — Edokter (talk) — 13:44, 15 November 2011 (UTC)

I just stepped through the css and js; well done. The rendering looks fine to me. I'll check in some other browsers, too. U haz barnstar due... Alarbus (talk) 13:49, 15 November 2011 (UTC)

fyi, I'm not seeing the middot after Bill and before the generated '(' in Firefox, Safari, or Opera when not logged-in; I just logged-in w/Firefox and got the dot.

{{Quentin Tarantino/sandbox}} — This is a test for {{Quentin Tarantino}} that moves the years to sublists of the work. It's got a stretch-wide issue in Chrome, and I suspect it's the whole-li nowrap rule. (marinating on this a bit, I now suspect that it's Chrome not including the generated content in a width calculation... 15:18, 15 November 2011 (UTC))

Alarbus (talk) 15:07, 15 November 2011 (UTC)

There should be no middot between 'Bill' and '(', as per your render example. Since the nested list of actually part of it's parent item, a middot would not be appropriate. You see the dot in Firefox because you still have some code in your common.css. I did move the generated '()' to the entire sublist instead of the first/last item (at the penalty/bonus of extra space, however you see it). Putting the years in as subitems would indded break no-wrap, as it is no longer part of the same item. — Edokter (talk) — 15:41, 15 November 2011 (UTC)

I see the quirkyness of the middot after a nested list. That remains a problem I cannot fix. — Edokter (talk) — 15:57, 15 November 2011 (UTC)

I'll go clear my local css; forgot about that. I've been marking-up with things like:

...

which produced approximately: ... · foobar · (foo · bar) · ...

to get reasonable lists, and this has been producing a middot before the paren (all this before the generated ones; just flatlist/hlist). The middot will likely be a good fallback for browsers not generating the parens. I do see your point about it not really being appropriate... The widening issue seems to have gone away due to your recent tweaks, which I've not looked at. See recent edits to {{National personifications}} for a DL example; Diannaa edited it and I fixed a minor issue and then DL'd it. CSS cleared; things look good. I like the paren-spaces. Alarbus (talk) 16:23, 15 November 2011 (UTC)

See {{National personifications}}, now. I used '::' for sublist/nested DL, and it's causing the overall DL to end and another to begin... resulting in linebreaks after each instance. Off for a while. Alarbus (talk) 20:05, 15 November 2011 (UTC)

I: Entry1, Entry2, Entry3 II: Entry1, Entry2 i: Entry1, Entry2, Entry3, Entry4 ii: Entry1, Entry2 III: Entry1, Entry2 i: Entry1, Entry2, Entry3 etc? f g 20:38, 15 November 2011 (UTC)

Done

The code grows bigger and bigger, but I am done. There should be no more kinks and I have put far more coding in it then I should have. Next time someone has a great idea, they may code it themselves... especially if it doesn't play well with IE. — Edokter (talk) — 23:53, 15 November 2011 (UTC)

One
Two
- Three
- Four

Not done! Found a bug. I think I'm going to have to do this from scratch again... — Edokter (talk) — 00:04, 16 November 2011 (UTC)

Now I'm done! I was going about it the wrong way. Using a background image gave too many headaches. So I started fresh using inline interpuncts and parens, and jQuery for selecting elements (as CSS does not provide a :prev selector), giving IE below 8 the proper markup to boot. And it only took me two hours! No more tinkering with margins and paddings that sprout up new bugs. It's clean, lightweight and does not rely on images. Only downside I can think of is that those with javascript disabled will not see the interpuncts and parens (but the old version also partly relied on jQuery). I checked some of the bugged templates reported above and I see no problems whatsoever. I'm glad it's finally finished. — Edokter (talk) — 13:39, 16 November 2011 (UTC)

Wow; will have to have a look-see (ok, had a first peek). I'll report any anomalies back here. Thanks, Alarbus (talk) 13:42, 16 November 2011 (UTC)

fyi; this was just to shut Advisor.js up; I know it's not needed. I'd changed it to _–_ as I mistook it for being on the left-side of a pipe.

I'm seeing full-spaces around the sublists on {{Prince singles}}, {{Quentin Tarantino}}, and {{Quentin Tarantino/sandbox}} — the last having *all* the years as sublists. These are not part of any nowrap and can get separated; maybe they can be simply removed? Or you're intent on this as a method of distinguishing them from ordinary brackets, in which case how about nbsp-entities? With the spaces, there's going to be a MOS-issue for many potential uses. Mulling the idea of square-brackets, but that might be too different (and braces certainly would be). All for the moment, Alarbus (talk) 14:12, 16 November 2011 (UTC)

I don't see the point in having the years as seperate sublists, they should be part of the list item, shouldn't they? Technically, I can't remove the spaces (they are induced by the linebreaks in the wikilists), and I can't 'nowrap' the generated parens without nowrapping the entire sublist. So that's a minor glitch we have to live with. — Edokter (talk) — 14:31, 16 November 2011 (UTC)

The individual years as sublists was just a test; I doubt it is appropriate for actual use. I wanted to try a lot of sublists. They're not really subsidiary, anyway; they are, quite literally, parentheticals of the list item. Being a part of the item is quite valid. The paren-dropping is unfortunate, and I'm concerned that too many will make a big deal of it. Again; nice work. Alarbus (talk) 14:42, 16 November 2011 (UTC)

There's no way around it; list items are nowrapped (only in navboxes), but sublists (being a list item itself) has it's nowrapping cancelled to prevent long sublist from breaking out of the box. If people make a big deal out of it, they can find a solution themselves. I for one think it's not a big deal. — Edokter (talk) — 14:53, 16 November 2011 (UTC)

I understand that whole sublists, potentially quite long, can't be nowrap'd, and that they're part of the higher level LI. The drop doesn't much bother me, but it seems people can make a huge fuss over the damnedest things, here; a quarter-meg of bickering over a comma. Site's got a reputation as an argument nexus. Alarbus (talk) 15:11, 16 November 2011 (UTC)

For what it's worth, I've checked a number of templates using hlist on FF, Chrome, Opera, and IE8 (standards and retarded modes). Apart from IE8 (retarded mode) - which allows some items to break across lines (e.g. Template:Quentin Tarantino) that don't break elsewhere - I can't find any glitches. I've even done a quick install of XP on a spare machine to see how IE 6.0 handles the lists, and it performs just like IE8 (retarded mode). I haven't attempted to install Win2K and test earlier versions of IE, as I reckon that anybody who is forced to use a browser older than IE6 has bigger problems than seeing a dot in the wrong place. Well done to all who contributed, and especial thanks of course to Edokter for all the perseverance and for such an elegant solution. --RexxS (talk) 15:31, 16 November 2011 (UTC)

My PDP-8, with 8kb of core memory, is not rendering things properly; I believe it's mostly due to the ASR-33 I've got connected to it. Please ensure that this is supported ASAP. Thanks very much, Alarbus (talk) 15:45, 16 November 2011 (UTC)

I'm going to need a screenshot to debug the problem. — Edokter (talk) — 15:52, 16 November 2011 (UTC)

No need, it's a well-known problem. A lot of folks upgraded their 4 Kwords of memory using the readily available 8-bit memory. Being a 12-bit computer, the PDP-8 stores the dots in the last four bits, so any page that makes use of the expanded memory won't render as expected. You need to upgrade your PDP to an earlier version. --RexxS (talk) 16:01, 16 November 2011 (UTC)

see below; I'll look into your suggestion; it might get my a proper Spacewar! platform. Thanks! Alarbus (talk) 16:12, 16 November 2011 (UTC)

(edit conflict) OHNoez; no screen. I can run a .jpeg out on the paper tape punch, if you've got a reader. I'm gonna have to blow the paper dust out of the core, again; damned fans draw it in. Plays a mean game of strek [2]^: 54. Alarbus (talk) 16:12, 16 November 2011 (UTC)

OK, all fun aside... I'll post a message in the Signpost's newsroom to announce hlist is ready for general rollout. — Edokter (talk) — 17:59, 16 November 2011 (UTC)

I'll be looking for it. Alarbus (talk) 07:14, 17 November 2011 (UTC)

Lists of archives

We should apply class="hlist" to {{Archive list}} and its sibling templates; I've started a discussion at Template talk:Archive list#Proper list markup, in which your participation is invited. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:26, 15 November 2011 (UTC)

Bot req

Per discussion above, I've requested a bot to replace dot-separated pseudo-lists in navboxes. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 15:46, 15 November 2011 (UTC)

fixed-width boxes

{{Campaign}} boxes, really any box with a fixed width, has trouble with links or list-items that don't wrap. See Campaignbox Gettysburg Campaign, where things expanded too much. This happens much more often in their titles, where I've been sticking in BR-elements, often having to add link-text to do so (example). There should be a better mechanism, starting with relaxing the rule in titles. For full-width boxes, any expanding (hscroll) is really due to absurd length links or list items: {{Hunter Thompson}}Alarbus (talk) 18:28, 15 November 2011 (UTC)

Indeed, the entire nested list is treated as one non-wrap item. Fixed. — Edokter (talk) — 18:43, 15 November 2011 (UTC)

thus enabling me to revert myself... to better results. On the titles, it is unfortunate that breaks will often be needed, anyhow, as editor-chosen break-points will often be better than browser-chosen. Thanks. Alarbus (talk) 18:53, 15 November 2011 (UTC)

[1] See:
Test test

[2] Test test

[1]