MediaWiki talk:Common.css/Archive 14

nocontent class
Since hlist has taken off, there are (sometimes slightly overenthousiastic) calls to turn everything into a hlist. When it was suggested that navbar be turned into a hlist, I had to intervene. Though I understand the reasoning, I do think navbar is not a list. If the goal is to mask the various visual aspects from any elements from content in order to make it sematically correct, there are better ways. For instance, stuff like bullets, pipe symbols and other seperators that are not content, could be wrapped in a  class, which has the following properties: I don't know much about screenreaders and such (so it may need extra rules), but this would enable editors and template coders to hide the various visual elements from semantic content, such as the bullets in navbar. — Edokter  ( talk ) — 15:16, 24 November 2011 (UTC)
 * I usually find myself in agreement with what you write, so I hope you won't be disappointed that I don't agree with your characterisation of navbar. To me it's clearly a list of associated links: view, talk, edit. I really would expect it to be marked up as a list, not just because it removes annoyance from screen readers (which it would), but because it actually makes sense as a list (i.e. the list markup would be semantic = have meaning).
 * Nocontent may have uses, but I wouldn't be very keen on making it easier for editors to avoid using accurate semantic markup by giving them a tool that allows them to hide their mistakes from screen readers. It's really better to encourage editors into good habits in the first place. --RexxS (talk) 01:57, 25 November 2011 (UTC)
 * Here's my biggest problem... Turning navbar into a list means it becomes dependent on outside CSS for it's core visual appearence; the content rule now used in Common.css cannot be substituted with inline CSS. That means porting to other wikis would require porting the CSS as well, and optional styling of the bullets using parameters (fontstyle) would become impossible. — Edokter  ( talk ) — 02:11, 25 November 2011 (UTC)
 * Yup, that will be a recurring problem as different wikis find solutions that live in their own css and make it difficult to port content without porting the required definitions as well. It's the price we pay for the separation of content from format. Taking a longer view, what is needed is an inter-wiki coordination to share best practice in css and attempt to synchronise that css between languages. May I be bold and suggest you would be the ideal person to take that concept to the German wiki as a staring point? Or are you aware of any initiatives already underway? --RexxS (talk) 02:34, 25 November 2011 (UTC)
 * *more* inter-project co-operation can only be good. Alarbus (talk) 08:03, 25 November 2011 (UTC)
 * *more* inter-project standardisation, doubly so. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:22, 26 November 2011 (UTC)
 * Ideally, hlist should be incorporated in core, which would solve a lot of porting issues. (BTW, I'm Dutch). — Edokter  ( talk ) — 12:58, 26 November 2011 (UTC)
 * Indeed, core would be the best place. I knew you were Dutch from your user page, but your English is so good I was hoping you'd also have sufficient ability in German to take it up there (it's the next largest wiki, IIRC). My thinking is that once the large wikis have adopted a style, it should make it easy to get it implemented in core. --RexxS (talk) 13:13, 26 November 2011 (UTC)
 * Unfortunately, mein Deutsch saugt Arsch. So that would best be handled by a German wikipedian. — Edokter  ( talk ) — 13:27, 26 November 2011 (UTC)


 * As I in the talk that seems to have lead to this, {navbar}, {navbox}++ should be a package on-offer to other wikis, and this should include the hlist++ stuff. All should be done carefully, of course, and it's not a next-week thing. This would include Edokter's new work and more. This package (or packages) would be a collection of templates, css, js, doc, and whatever else glues it together. There is nothing specific to the English Wikipedia about any of this. The WMF runs many hundreds of wikis, and they would all benefit from this. The internet has thousands more. Years ago, the other wikis took code from here to get themselves off the ground. Some have gone off on their own directions (not all good, though), but mostly they will be occasionally looking back to EN:W for updates. When the new navigation gets well-deployed here, people who participate in multiple projects will be considering it for elsewhere. EN:W is the source of the poor code that {dot} and such are, and this place should also be the source of the solution.
 * I see v·d·e as a list, albeit a small one. It should be rendered as LI-elements and styled along the lines of hlist. It doesn't have to be the exact same code; quite likely it shouldn't be, or if so-implemented will eventually move on its own path. Look at most any well-designed website, and you'll find mostly list-items for the menues, navigation, and much more. This is good structure, good design, and a forward-leaning approach. See this site; everything along the left is in LI-tags; the stuff across the top and bottom, too. List-items are *the* way website navigation is done these days.
 * The nocontent class may be a good thing, although it is not likely to be so simple. Not really what I see this thread as being about. Alarbus (talk) 08:03, 25 November 2011 (UTC)
 * It's a list. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:22, 26 November 2011 (UTC)

Navbar
OK, have a look at the navbar sandbox version and its test page (and even the navbox test page). There remains a small spacing issue when used inline with brackets, but that scenario is never used AFAIK (I might as well remove the brackets option). Expect a lot of tweaking. Eventually, most navbar CSS will be moved to Common.css. — Edokter  ( talk ) — 15:19, 25 November 2011 (UTC)


 * May also want to look at doing template:v at the same time. -- WOSlinker (talk) 16:08, 25 November 2011 (UTC)


 * Is that one still around? It is only used in a couple of core templates, which are easily replaced with/redirected to navbar. I haven't seen a single instance of the extra links being used. — Edokter  ( talk ) — 18:44, 25 November 2011 (UTC)


 * Looks nice; ship-it ;> The brackets seem dispensable. The v would really only seem interesting for the v-only form, but if it's easy maybe keep it around. It's unhelpful to have too many variations on stuff. That new collapse/expand mechanism looks nice, too. Thanks. Alarbus (talk) 05:01, 26 November 2011 (UTC)

Suggest #mw-panel{position:fixed;}
As section title.

Nice to have the tools follow one down the page. Would be nice for WP:ACCESSIBILITY too.  fredgandt  23:36, 24 November 2011 (UTC)
 * p.s. I assumed it had its current  set in the common.css but actually there is no mention of it. I guess it must be inherited? the only two  's I can find are for navToggle and breadcrumbs. Confused as ever.  fredgandt  00:24, 25 November 2011 (UTC)
 * The core CSS file for Vector is at [//svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/vector/screen.css?view=markup /skins/vector/screen.css] (loaded through ResourceLoader). And I have to recomment against  as you would not be able to scroll down all items if the entire list spans more then one screen, as is often the case with interwiki links. You can always put it in your personal CSS though. —  Edokter  ( talk ) — 01:02, 25 November 2011 (UTC)
 * Ah. I didn't think of that. Hard to imagine a list of links that long but I suppose it could happen (ah yes right, interwiki, languages, got ya). As for changing it in my own common.css, I already did (thanks for suggesting it though). Along with scripts and css I have pretty much totally reformed the whole navigation set-up (still working on it though). An alternative could be to contain mw-panel in a scrollable div with overflow set to auto and set the container to fixed. this would allow the panel to stay put but the contents of it to be scrolled. How about that?  fredgandt  01:11, 25 November 2011 (UTC)
 * And have a very ugly scrollbar across the page? It'd be like frames all over again... — Edokter  ( talk ) — 01:20, 25 November 2011 (UTC)
 * I like frames Face-sad.svg. The scroll-bar would only show when needed and could be styled to be less nasty. In fact I can well imagine it's possible to style it so it doesn't even show. The scrollability would still be there but no scroll-bar. Before you say "but accessibility would be compromised", scroll buttons could still exist. Where there's a will there's a way! Just a thought anyway. I'm going to try it out after walking my dog.  fredgandt  01:26, 25 November 2011 (UTC)
 * Good luck . I predict that IE is going to bite you. (But it could be a nice gadget.) — Edokter  ( talk ) — 01:33, 25 November 2011 (UTC)

← My eyes have grown sticky with the night so I've not yet looked at styling the scroll-bar (except that it can be done in webkit and apparently in IE (I am shocked!!)). Here's a quick demo of the basic stuff though. <!DOCTYPE html> <style type="text/css"> {	position:fixed; background-color:#ddd; border:1px solid #888; top:8px; float:left; width:150px; height:700px; font-size:70%; overflow:auto; } {	margin-left:160px; border:1px solid #888; } p { margin:5px; } p:hover {	color:#0f0; font-weight:bold; } <script type="text/javascript"> var str; var count=0; document.write("<div id=\"main-dish\"> "); var md=document.getElementById("main-dish"); if(md) {	while((++count)<201) {		str=" "+count+" "; md.innerHTML+=str; } } document.write("<div id=\"side-dish\"> "); var sd=document.getElementById("side-dish"); if(sd) {	count=0; while((++count)<201) {		str=" "+count+" "; sd.innerHTML+=str; } } I don't think it's that bad even with the scroll-bar but I'll still look see if it can be styled (later). Thanks for the good luck wishes. I detest IE passionately.  f<i style="color:#0dd;font-size:60%;">red</i>g<i style="color:#0dd;font-size:60%;">andt</i>  03:39, 25 November 2011 (UTC)
 * 1) side-dish
 * 1) main-dish
 * Please don't go mucking with attempts to style scroll-bars. Better yet, let's try to avoid the addition of extra scroll-bars anyway (especially horizontal ones). I know (or at least understand) that you're talking about hiding the scroll-bar bit of the actual scroll-bar, but I don't think that makes it any better. There's a usefulness in having standardized user interface features, and what you're talking about here sounds like breaking users' browser UI (to the extent I understand what you're aiming at). &mdash; JohnFromPinckney (talk) 06:08, 25 November 2011 (UTC)
 * mw-panel is a vertical side bar and if it scrolled, that too would be vertical with a scroll-bar running vertically (if not hidden). As for breaking user UI; that's just silly. If changing the UI is breaking the UI, it has been broken countless times since Wikipedia was first served.  f<i style="color:#0dd;font-size:60%;">red</i>g<i style="color:#0dd;font-size:60%;">andt</i>  07:25, 25 November 2011 (UTC)
 * I'm positive that there are already userscripts out there that do this. As a matter of fact the old skins cologneblue and classic even have this as a preference option in the preferences. —Th e DJ (talk • contribs) 08:35, 25 November 2011 (UTC)
 * Interesting to hear that other skins may already have this featured but as you say, they are old skins. The default (as far as I know) is Vector and it is that which most visitors then use. User scripts may very well emulate this effect but they must be first thought of as an option then found and added (a process some may be quite confused and intimidated by), or created from scratch by the user. None of this is nice simple default behaviour and it is that I proposed changing. I would hardly suggest changing the MediaWiki common css if I didn't think the change beneficial to all users. I ask, do you not send email because you can already send messages to people by post? This is a suggestion to rethink and rebuild the UI by changing one word in one file (fair enough it turns out to be a little more complex) but the suggestion to update and upgrade remains since user scripts (it can be done in users common css btw) and old skins are not the most used or favoured.  f<i style="color:#0dd;font-size:60%;">red</i>g<i style="color:#0dd;font-size:60%;">andt</i>  09:19, 25 November 2011 (UTC)
 * I was just pointing out what was there already. Also, I've personally given up on making changes to the default UI of the English Wikipedia. It's way too much effort and stress, to convince all the old farts, but if you want to deal with that, go right ahead :D —Th e DJ (talk • contribs) 13:41, 28 November 2011 (UTC)
 * I apologise for my rant. It is actually the frustration you have just mentioned that drove it. I feel like I'm smacking my head against a wall sometimes. I am too new at this (not web-deving, wiki-deving) to give up yet but may eventually join you. Mediawiki has node.js installed! It is even poised on the verge of Websockets (Wikia are using them so I believe). I had to explain to my own server provider what they were, and they are in the business of serving the web. For the Mediawiki software to be so advanced that it is ready to deal with the next generation of web applicationism, but for it to hang back while the rest of the web strides forth is nuts. Wikipedia is Mediawiki's vanguard. It should be screaming ahead of other users of the software. It seems the community are too precious to give new things a go. Sure some ideas are just plain bad, but not all. This ultra simple change to the css would mean that if at the bottom of a long page, users wouldn't have to scroll back to the top just to click a button. How is that a bad thing? Anyway, sorry I blew my stack a little at you there.  f<i style="color:#0dd;font-size:60%;">red</i>g<i style="color:#0dd;font-size:60%;">andt</i>  15:57, 28 November 2011 (UTC)

I still use a custom version of the Modern skin precisely because it was tweaked to keep the tabs and sidebar always visible; I find that to be a extremely convenient. I've been meaning to apply the same to the Vector skin, but haven't found the time to do it. I'd be happy to try on a custom style I could import to my vector.css and give feedback/offer further enhancements in return :) (ps - I tried to import your common.css but I saw no change even after clearing the cache. Does it work only with accompanying js? If so, would it be possible to make it work with css only?) --Waldir talk 11:50, 27 November 2011 (UTC)
 * If you @import CSS, you must import the 'raw' content using . Alternatively, you can use   in your personal javascript file. —  Edokter  ( talk ) — 14:22, 27 November 2011 (UTC)
 * Waldir: Do not import my css or javascript separately. Very important to not use the js without the css. Some of the js without the accompanying css will make the site almost impossible to use and thus extremely difficult to fix.


 * However, to make the side panel stay in place (in the Vector skin) while scrolling you only need a few lines of css in your common.css.

{	position:fixed !important; max-height:500px; overflow:auto; }
 * 1) mw-panel
 * will do it. The height setting is something you might want to adjust for personal comfort. My javascript sets that property by measuring my window.  f<i style="color:#0dd;font-size:60%;">red</i>g<i style="color:#0dd;font-size:60%;">andt</i>  01:42, 28 November 2011 (UTC)

Reuse #userlogin code also in #userloginForm
Currently there is a nice styling for the user signup form, why not applying it also for the user login form? /* Makes it possible for the boxes in the Account Creation Process to overlap */ margin:0; width:90% !important; max-width:100% !important; padding:1.5em; padding-top:0.75em !important; border:0; -moz-box-shadow: inset 0 0px 10px rgba(0, 0, 0, 0.35); -webkit-box-shadow: inset 0 0px 10px rgba(0, 0, 0, 0.35); box-shadow: inset 0 0px 10px rgba(0, 0, 0, 0.35); -moz-border-radius: 7px; -webkit-border-radius: 7px; border-radius: 7px; background:white; background: #fff; background: -moz-linear-gradient(bottom, #fff 90%, #F5F5F5 100%); background: -webkit-gradient(linear, left bottom, left top, color-stop(90%,#fff), color-stop(100%,#F5F5F5)); background: -webkit-linear-gradient(bottom, #fff 90%,#F5F5F5 100%); background: -o-linear-gradient(bottom, #fff 90%,#F5F5F5 100%); background: -ms-linear-gradient(bottom, #fff 90%,#F5F5F5 100%); background: linear-gradient(bottom, #fff 90%,#fff 100%); } —Fitoschido [shout<sub style="margin-left:-3.5ex">track] \\ 3 December, 2011 [20:32]
 * 1) userlogin, #userloginForm {


 * If it were up to me, that code should be removed. It was added in relation to another project (Article creation wizard?), someone will have to remind me. — Edokter  ( talk ) — 20:41, 3 December 2011 (UTC)


 * Yeah, you’re right. Anyway, this is inconsistent with the rest of Wikipedia’s UI. —Fitoschido [shout<sub style="margin-left:-3.5ex">track] \\ 9 December, 2011 [05:57]

What is the point of winfixes.css?
The font stacks in MediaWiki:Common.css/WinFixes.css are a true mess. Over the years, the list of exotic fonts has grown with every editor adding his/her own preferred font. Apart from the three or four MS fonts in the list, the rest of those fonts are mostly found on non-Windows machines, which is rather pointless since the file is only loaded on Windows(!). Why have fonts listed which have an installed base of less then 0.01%?

I think it is time for a cleanup, and prune this list to it's bare minimum. Therefor, I would like to do an inventory for the requirements and compile a list from scratch. Since most classes are intended to mostly fix IE issue, perhaps it is best to limit loading to IE only. Any used fonts should be readily available, preferably without requiring any downloads (as most Windows readers won't even bother with fonts). Then the list should be split into serif/sans-serif to match the several skins.

I can't do this alone, so I need input on the requirements and suggested fonts. What I can do is list the (unicode) fonts most likely available to Windows users (sorted by glyph count). — Edokter  ( talk ) — 21:46, 27 November 2011 (UTC)
 * Just to let you know that I'd love to help but have little clue about fonts (the tech stuff).  f<i style="color:#0dd;font-size:10px;">red</i>g<i style="color:#0dd;font-size:10px;">andt</i>  12:39, 4 December 2011 (UTC)


 * Arial Unicode MS (sans-serif)
 * Microsoft Sans Serif (sans-serif)
 * Lucida Sans Unicode (sans-serif)

Not just for Windows?
I suspect this code should never have moved to Winfixex.css in the first place. Case in point: Template talk:Unicode. — Edokter  ( talk ) — 14:25, 1 December 2011 (UTC)
 * Other OS'es should be good enough to do proper font and script fallback. I looked at this in the past quite a bit. Making font selections for the user in general is a BAD and broken approach. The primary all these style templates existed, was mostly because windows was broken, and worse, shipped with quite a few broken fonts. As far as i'm concerned these classes shouldn't exist at all. —Th e DJ (talk • contribs) 12:31, 4 December 2011 (UTC)
 * I agree, but some exotic glyphs still need it (even in Chrome and Firefox on XP). And one Linux user also has problems. I do intend to trim the list, and split them into platform-specific stacks (is possible). 99.9% of Windows users don't even have font like Gentium installed. — Edokter  ( talk ) — 12:41, 4 December 2011 (UTC)
 * Yes gentium should never have been added to that list. The eventual ACTUAL solution to this is the WebFonts extension perhaps. —Th e DJ (talk • contribs) 13:12, 4 December 2011 (UTC)
 * Same problem... who needs it and who doesn't? Plus, if you're going to use one all-encompassing unicode font, it will probably run into one giant multi-megabyte font file. No, lang= attributes are the future. — Edokter  ( talk ) — 13:25, 4 December 2011 (UTC)

Another frustrating issue... Where IE8 and Firefox display unicode correctly, Chrome fails miserably with combining diacritics, but only under XP! This seems to be a long standing issue, judging from the miriad of bugs filed with Chromium, with no fix in sight. I'm am going to narrow the target for loading Winfixes.css to IE6/7 and Chrome under XP. — Edokter  ( talk ) — 19:24, 4 December 2011 (UTC)
 * Yes, chrome (and Safari actually) uses the OS features for fontrendering. Firefox uses it's own internal rendering (most of the time that is). What Opera does, i'm not sure of. Since XP doesn't have full support for exotic languages (and DEFINETLY not if you don't have the right language packs installed), the rendering breaks in many ways (depends on how much countermeasures (implementing own bidi and diacritics logic) the browser has taken). The fact that Firefox does it's own rendering has the nasty effect of it not supporting some language features on OS X, that native OSX rendering DOES support :D —Th e DJ (talk • contribs) 10:40, 7 December 2011 (UTC)

WinFixes is gone
After trimming the list, I eventually ended up with the two main unicode fonts for Windows for both unicode and IPA. Since it was now a single line of CSS, I opted to have it load directly in Common.js and remove WinFixes.css. Less clutter, one less HTTP request, so faster loading. — Edokter  ( talk ) — 22:57, 7 December 2011 (UTC)

Centering title
I posted about this not too long ago but removed the thread since I chalked it up to PEBKAC... but on further inspection, this issue seems to be legitimate. I'm having trouble finding where in the CSS this is, but the navbox and templates that transclude the class (e.g., ) no longer seem to center the title in Firefox and Opera, though it seems to work fine in IE. I'm not sure if there's something non-compliant in the CSS that's breaking that particular aspect of the class. The problem seems to have started not too long ago, and I suspected it might be this edit that's causing the issue, but I've tried reverting to the previous version already and the problem corrected itself temporarily, but is back now, which is quite odd. I'd rather not continue reverting and testing, but if someone else also has the same issue and can figure out what's going on, whether it's the CSS itself or something with MediaWiki, that would be helpful. Thanks. -- Kinu  t/c 22:18, 6 December 2011 (UTC)
 * It was indeed my edit you linked that caused the problem. The change is necessary to accomodate developments in the navbox template. Unfortunately, some collapsible archive tempates also 'abuse' the navbox class, which now show left-aligned headers. I've fixed collapse top by adding, but a better solution is to have a seperate class for these archive templates. —  Edokter  ( talk ) — 22:59, 6 December 2011 (UTC)


 * I checked at Template:Hat and get left aligned "This discussion has been closed. Please do not modify it." on FF8 and Chrome15, but centred on IE9.
 * According to Chrome the alignment is inherited from table#collapsibleTable0.navbox.collapsible.collapsed -> Style attribute { text-align: left; } which overrides table.navbox { font-size: 88%; text-align: center; }
 * Internet Explorer has obviously decided to ignore that. Hope that helps. --RexxS (talk) 23:00, 6 December 2011 (UTC)
 * I've added text-align:center; to that. -- WOSlinker (talk) 23:21, 6 December 2011 (UTC)

Portal column width vs narrow and mobile screens
I've got a couple style defs I'd like to add:

Many portal pages like Portal:Literature and Portal:Science create two-column layouts by wrapping a float-left and a float-right div with specified percentage widths in a bigger div with open & close. This looks great on a wide screen, but on narrow windows (especially on mobile screens!) you end up with a really ugly result such as Portal:Literature on mobile. Something like these styles should disable the floats & the fixed widths on narrower screens, so it automatically devolves into placing the two "columns" vertically, with no shrinkage: much nicer on a small mobile screen.

Any objection to adding these styles globally and trying swapping more of them in? Experimentally using them on Portal:Literature/Mobile redesign attempt. (only works if you add the styles to your .css or the globals, otherwise you'll see the one-column layout) --brion (talk) 22:09, 7 December 2011 (UTC)


 * I've gone ahead and added them for now. I'll make some initial edits to a number of portal pages to match -- if they need to be undone, please feel free to revert them! --brion (talk) 22:46, 7 December 2011 (UTC)


 * (ec) Looks nice, but some portals have a bigger problem... They have a wide box called "Related portals" that have hardcoded, non-breaking rows of icons that break out of the display area, even before reaching 800px. — Edokter  ( talk ) — 23:31, 7 December 2011 (UTC)


 * I can confirm this happens on a lot of the portals linked from Portal:Literature that I've tried switching over. I think I can fix these by replacing the tables with a more modern technique (similar to how works these days), will experiment with that in a bit. --brion (talk) 23:41, 7 December 2011 (UTC)


 * How's this look? Portal:Literature/Mobile redesign attempt/Related portals (on iPhone it looks like ) Template info at Template:Related portals2 --brion (talk) 00:20, 8 December 2011 (UTC)


 * Very good. Icons break where they're supposed to. — Edokter  ( talk ) — 01:32, 8 December 2011 (UTC)


 * Excellent - I've gone ahead and used it for Portal:Literature and its friends. --brion (talk) 20:46, 8 December 2011 (UTC)


 * Is it worth also adding another class for width:100% rather than leaving full width columns set using style? -- WOSlinker (talk) 23:30, 7 December 2011 (UTC)


 * Agreed -- I prefer a consistent style for the full-width ones too, it'll look clearer in source. --brion (talk) 23:41, 7 December 2011 (UTC)


 * Shouldn't there still be a way to customize the width values per portal? Maybe there could just be a specific class that does nothing on non-mobile, but has  on mobile, rather than setting up different classes for each width and float location? --Yair rand (talk) 01:37, 8 December 2011 (UTC)


 * This is a good direction, and I'm glad to see others looking to support greater accessibility. Mobile use is seriously on the rise. I do cringe a bit at the skip-one-percent approach, though. I know it's common, and why; too bad it can't be 40%-1em.
 * Might this be better tweaked to not be named as portal-specific? Surely there are other places doing much the same thing. A generic name or several similar selectors? Alarbus (talk) 02:58, 8 December 2011 (UTC)


 * Genericizing is probably good -- using similar "column" selectors for things like the two-column references might be ideal. My inclination would probably be to go with approx even-sized columns (50/49% default or 49.5%/49.5% maybe) and allow those to be overridden when different balances are desired. --brion (talk) 16:43, 8 December 2011 (UTC)

hlist padding 0.125em 0; in navbox
The following, which was added as a sort of bridge while hlist is deployed to navboxes containing explicit padding styles, is not always being applied. There is a difference between the use of  and.

In the case of 'body' the padding is applied, but not for 'list'. This is because for 'list' the class is being assigned to the TD, while for 'body' it is applied to the table itself (inner one, the TD's), and this result in the above selectors not matching; the class is on the TD, not above it.

See where I changed to body and noticed a rendering change to all the rows (no comments on the single item list; it's a stub for anyone adding to the below item).

I'm thinking the above selectors need to be relaxed: drop the TDs. Maybe drop the navbox class, too. I think this was working but then changed. FWIW, this may be the time to drop it to 0.1em as widening the application of this after so many hlists have been deployed as 'list' will result in a lot of navboxes getting taller. Up to Edokter... Alarbus (talk) 07:29, 8 December 2011 (UTC)


 * Good catch. The padding (in height only) is tailored to navbox; it should not have padding in other places. I added the td because the title had unwanted padding as well. — Edokter  ( talk ) — 12:29, 8 December 2011 (UTC)


 * Thanks. This is now performing 'correctly'. But. But see the before and after of the Tennessee diff; the bottom section, which is the single-item list in the after-side of the diff, is getting the padding while the before-side, which is not a list, does not. This is what-all is supposed to happen, given where the class is set and what code is in place. But it's not quite ideal, because now the two don't match. This is fine for a diff of the same box, but out there we've a mix of listclass and bodyclass with a few aboves and belows, too; and they have slight variations in the padding. I'm thinking that we should really consider whether this padding, which is ultimately (when millions a hlist'd) about making all navbox lists space-out a wee-bit should be in navbox itself. I know you don't want to mess with that. It is a bigger deal to play with that; millions at once. So we think on it, ok? Revisit in a few days. Now may not be the right time, maybe once most are converted is... Alarbus (talk) 13:30, 8 December 2011 (UTC)


 * It will never be ideal, simply because lists behave differently then running text. The only reason for the the hlist padding is to reset the zero padding upstream and have it approximate the dimensions of running text inside the navbox, nothing more. I observe a 1px difference, which I find acceptable. Being pixel-perfect is not an option without a truckload of CSS accounting for every situation, which makes it unmanagable. So unless there are any obvious errors showing, I don't plan on any more tweaking. — Edokter  ( talk ) — 13:57, 8 December 2011 (UTC)

Font size for other_name
The desired line is:

table.infobox.geography.othername { font-size: 80% }

More details at Template_talk:Infobox_settlement SSzatmari (talk) 15:51, 13 December 2011 (UTC)


 * Oppose. I've looked at the discussion at Infobox settlement, and I believe that the smaller font size is being proposed for purely aesthetic reasons. While I have no problem with that rationale, per se, I believe that 80% is simply too small to be used on Wikipedia. I do not want to have to zoom my browser or find a stronger pair of glasses just to read a single item, nor should the large number of other older readers who will inevitably find 80% too small. Although it's not as black-and-white as this, the proposal is effectively asking to sacrifice accessibility for aesthetics. If the proposed size reduction were by a smaller factor, I'd be inclined to withdraw my objection, but multiple discussions at WT:ACCESS have usually agreed that font sizes around 90% are acceptable to most, while 85% seems to be lowest tolerable - and then only for very good reason (such as lack of space inside an element). --RexxS (talk) 16:19, 13 December 2011 (UTC)
 * I can agree with 85% too, and the reason is that the official (native) name must be more highlighted than the alternative names (e.g. the names in other languages). A similar font is used at Geobox infobox: http://en.wikipedia.org/wiki/Dunajsk%C3%A1_Streda SSzatmari (talk) 16:31, 13 December 2011 (UTC)
 * Note that othername is contained in the infobox' header, that has font-size 1.25em set, so this would reduce it back to 100%. (90% actually, as that is waht the infobox as a whole uses.) — Edokter  ( talk ) — 16:39, 13 December 2011 (UTC)
 * Good point, in which case, I don't think it will cause a problem and I withdraw my objection. Although you might want to leave a comment that the accessibility of an 80% setting depends on the header setting of 1.25em, in case that gets changed in the future. That might also help avoid "otherstuffexists" rationales for 80% in other cases where there's no 1.25em to compensate. Cheers --RexxS (talk) 16:58, 13 December 2011 (UTC)
 * My initial proposal was to make the font resize in that specific template:, but I was directed to MediaWiki:Common.css by another admin SSzatmari (talk) 10:15, 14 December 2011 (UTC)
 * I think it should be done in the template itself, since it's parent font-size is also set there. I'm disabling the request here. — Edokter  ( talk ) — 10:33, 14 December 2011 (UTC)

Space before colon in "hlist dt:after" rule
Just wondering if we need the space before the colon in the rule

The place where I saw it used was The Holocaust, where the spaces appeared to be extraneous. -CapitalR (talk) 18:54, 16 December 2011 (UTC)


 * That is intentional on my part. Partly because I find it helps identify it as as a horizontal list (I regard it more as an 'double interpunct' then a colon), and partly because I want to keep it consistent with the script that handles older browser, where the space can not be removed. — Edokter  ( talk ) — 19:21, 16 December 2011 (UTC)


 * I wouldn't mind if the space was omitted, as it's more a suffix to the DT (to me). On the other spaces ( on sublists ), could they be omitted too on modern browsers? If it's just due to *that* browser, we should not hold back others just for the sake of consistency across browsers. It is *fine* if such slight differences in rendering are occurring so long as users of any particular browser are getting a reasonably consistent user experience in that browser. If some users get minor rendering anomalies using a poor browser, it is OK . Alarbus (talk) 05:52, 18 December 2011 (UTC)


 * Ironically, on modern browsers, the space around the parens of sublists cannot be removed. So for consistency, all hlist interpuncts are spaced. — Edokter  ( talk ) — 12:16, 18 December 2011 (UTC)

Note: linked from Village Pumps to this page
Note: I have added a link to this page from Village Pumps, e.g Village pump (technical) (line four: "See also:..."). -DePiep (talk) 19:37, 16 December 2011 (UTC)

Linden Scripting Language
In the example below, the colors are a little off, and both event and function names should be bold. default {	state_entry {		llSay(0,"Foobar!!"); } } I'd be happy to provide a full example script containing all the components, if the styles can be improved.

JavaScript
In the example below, both the function names should be bold and dark blue. I'm sure if one function is not correctly styled, there must be others (functions, methods etc.).  f<i style="color:#0dd;font-size:10px;">red</i>g<i style="color:#0dd;font-size:10px;">andt</i>  04:57, 18 December 2011 (UTC)
 * It seems both of these bugs should be reported to GeSHi, or else to Bugzilla if they're already fixed upstream and just need a local update to the included GeSHi code. Anomie⚔ 05:37, 18 December 2011 (UTC)
 * Ahh. I wondered why I could find no reference to the classes they use. I'll look into making those reports after some sleep (if no one gets to it before me). Thanks Anomie.  f<i style="color:#0dd;font-size:10px;">red</i>g<i style="color:#0dd;font-size:10px;">andt</i>  05:42, 18 December 2011 (UTC)
 * I've reported . It would perhaps be an idea to create a test script for all languages supported, that we can use to keep tabs on the styling. Big job, but worth doing. I'll sort the LSL report out later.  f<i style="color:#0dd;font-size:10px;">red</i>g<i style="color:#0dd;font-size:10px;">andt</i>  06:03, 18 December 2011 (UTC)

Hlist with TOC
I replaced a hardcoded TOC in an article here and here. Is there a template for an hlist TOC? It would be even better if the presentation were similar to what was replaced, but I'm not sure if that is possible. Perhaps a TOC-hlist variation would be possible? Thank you! 174.56.57.138 (talk) 15:07, 26 December 2011 (UTC)
 * point for cleverness, but those won't last long. not sure what you're thinking 'similar to what was replaced' would be other than the usual... Alarbus (talk) 15:11, 26 December 2011 (UTC) ... ah, the oldrev wasn't usual (as you said). Alarbus (talk) 15:12, 26 December 2011 (UTC)
 * Right, the previous version was a hardcoded flat list construct, so I replaced it with the "hlist" class wrapped around a TOC. It would be nice if the top level ones were still the same format as a standard TOC, and the second level ones were in a flat bullet list.  A right or left floating one would probably also work, but I thought I would check to see if there was any interest in something else here.  Thank you! 174.56.57.138 (talk) 15:40, 26 December 2011 (UTC)
 * Wait for Edokter to comment; it's his css/js. It could be done of course; but you know that. Laters, Alarbus (talk) 15:44, 26 December 2011 (UTC)
 * This is just one example of how a TOC could be combined with hlist, but there are many many more, all with different wishes for which level to display as a flatlist, etc. To accomodate for each one of them means a truckload of CSS, because the CSS for the TOC is pretty tight to work around. Personally, I think it's too much work. — Edokter  ( talk ) — 01:23, 27 December 2011 (UTC)
 * This is probably something best done in MediaWiki itself; implement __HTOC__ or something. I've not seen such hardcoded TOC before... are they that common? Better; would they be appropriate in many pages if there were solid implementation available? Alarbus (talk) 03:06, 27 December 2011 (UTC)

List TOC alignment
Is there a way to pass css from the TOC definition down to the list? My particular case is Template:MTGkeywordsTOC, where my "align=center" tags appear in the  block, but the list css overrides that in the   block right inside it, as shown by Chrome:

and --Temporarily Insane (talk) 09:04, 3 January 2012 (UTC)


 * Not possible (to do from inside the template). The CSS for TOC is pretty tight. Perhaps you're better of using a navbox instead. — Edokter  ( talk ) — 10:19, 3 January 2012 (UTC)
 * I've been thinking that we could do with a parent template, modelled on Navbox, but simpler, for the various TOC templates. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 11:47, 3 January 2012 (UTC)
 * That is a possibility. — Edokter  ( talk ) — 12:17, 3 January 2012 (UTC)

Code
Text marked up with Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.

Can we make it a bit bigger, and thus more easily readable? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 23:08, 21 January 2012 (UTC)


 * Technically it is the same size. If the font-size of the first and third sentences is 14px, then so will be the font-size of the element is pure semantic markup, it is not typographic and should not be automatically visually distinct in any way, or problems immediately result, of many kinds.  At this time, per that previous detailed discussion at which consensus was arrived at to make this change, only, and the fact that nothing's changed since then, no other styling needs to be applied for dfn, and none is envisioned an time soon, but this change definitely does need to happen.  I've been having to manually work around the italics nonsense in dfn, etc. — SMcCandlish    Talk⇒〈°⌊°〉 Contribs. 23:49, 11 February 2012 (UTC)


 * Chrome does italize now. Are there any examples where dfn is used raw? —  Edokter  ( talk ) — 00:36, 12 February 2012 (UTC)
 * We don't care. New browsers and versions of browsers come out all the time. The italics interfere with all other uses of italics and their significations on Wikipedia. — SMcCandlish   Talk⇒〈°⌊°〉 Contribs. 01:07, 12 February 2012 (UTC)
 * I have yet to see a dfn tag in the wild. That is why I asked. As long as dfn is not use directly, there is no point is defining any styling for it. — Edokter  ( talk ) — 01:13, 12 February 2012 (UTC)
 * WP:IDONTKNOWIT? Really? The element can and thus certainly will be used directly, like any other [X]HTML that MediaWiki doesn't filter out; we have zero control over that. The point in removing bogus* style from  with a CSS one-liner is so that every time someone is trying to use it, in a template or otherwise, they don't have to figure out WTF is going on and how to work around it when stuff italicizes for no apparent reason (and only some of the time, as various templates usable inside a  could override the style, even aside from very likely browser problems; no one tested the issue on any of the profusion of *n*x browsers, for example, only Windows and Mac ones). Assuming they're even competent to work around it manually - not everyone knows CSS and how to add it to HTML elements. I don't know why we're arguing about this. There was already a consensus to do this, it just got archived and I forgot to editprotect-request it. Nothing has changed other than one browser's behavior (on the platform you tested it on), which isn't relevant anyway, because we want to avoid the italics universally (actually, the fact that Chrome is doing it now, too, strengthens not weakens the rationale – now no known browsers are doing what we want). — SMcCandlish    Talk⇒〈°⌊°〉 Contribs. 01:44, 12 February 2012 (UTC)  *Note: It's bogus because the W3C specs do not recommend it, and they don't even use it in the default all-browsers style sheet that the entire Web's display is essentially based on. What happened is either Netscape or IE, I forget which (probably IE, because their track record for standards compliance and weird experimentation was far worse) had it italicized this way back in the early to mid 1990s, and eventually the other one switched to emulate the competitor, then later browsers started doing what the big two of the era did, just to keep cranky designers happy, instead of doing what made sense. — SMcCandlish    Talk⇒〈°⌊°〉 Contribs. 04:50, 12 February 2012 (UTC)
 * Yes, probably IE. See . Anomie⚔ 06:04, 12 February 2012 (UTC)
 * I am a bit wary about changing default behaviour for a single HTML tag. The consensus in HTML seems to be that any tag that changes semantics in text is also visible to the reader, otherwise there would be no point in having the tag in the first place. However, I see this is also done with in core (who's default is also italics), so that is where this should be done as well. In the mean time, I'll add it here. —  Edokter  ( talk ) — 11:25, 12 February 2012 (UTC)
 * Here's my view on the matter, and I've given it some thought. Its analogous to there being no basic display difference between a lot of the semantic markup tags (e.g. code, kbd, tt, etc.); they're just monospaced and that's it. By default (and WP actually likes their defaults, for our purposes). But they're still detectable by and can be acted upon by software, by user-end style sheets (here or locally), etc. It's basically just a coincidence that that there's a gestalt that those are font-styled a certain way. It's also a coincidence that dfn and cite (and address, were it supported here) are often italicized by default, but would need to  be, for our purposes.  Their italicization dates to the early 1990s when the World Wide Web and creating Web pages on Web sites was something new and different, with its own nascent, experimental conventions. Many of those have been abandoned in the intervening two decades plus (has it really been that long!? I feel old!), as the Web is now about rich applications on websites and embedded into other interfaces. They increasingly mirror offline publishing and traditional style, including the lack of pushing things like italics as some kind of standard, but rather a matter of flexible designer-side typography choice overridable by user needs, especially since CSS starting the mid-1990s has (too slowly!) separated the presentation from the semantics. In short, if MSIE had decided that h3 and h4 should be italic instead of bold, and various browsers had gone along with this to make consistency-seeking designers happy, WP/MW would still override that for our own internal consistency, because in the modern Web, the defaults are meaningless, and publications must style for their and their audiences' needs. [end essay] — SMcCandlish    Talk⇒〈°⌊°〉 Contribs. 23:10, 12 February 2012 (UTC)

Account creation code
Is the code for account creation still needed? — Edokter  ( talk ) — 00:40, 12 February 2012 (UTC)

Add selectors for mediawiki collapsible plugin
Per suggestion on Village pump, could someone add the needed selectors to the formatting of NavFrames? The specific change is highlighted on that discussion. Helder 20:34, 31 August 2011 (UTC)
 * Shouldn't we await a progress on bug #30402 and bug #30327 before rolling this out, as the likely solutions seem to imply possible additional changes to Common.css? --RexxS (talk) 00:00, 1 September 2011 (UTC)
 * Request disabled pending further discussion. &mdash; Martin (MSGJ · talk) 13:11, 1 September 2011 (UTC)
 * So, [//en.wikipedia.org/w/index.php?diff=460483718&oldid=460458422 it was added] a selector for mw-collapsible elements, but the ones which were requested on this thread are still missing. Could someone include them? Helder 17:37, 15 November 2011 (UTC)
 * Or would it be better to create a separate class to apply these styles, so it remains possible to use mw-collapsible without having these extra styles forced? Anomie⚔ 17:54, 15 November 2011 (UTC)
 * That would be an option, but for testing, it is better to mirror existing markup and work our way from there. — Edokter  ( talk ) — 18:02, 15 November 2011 (UTC)
 * Now my userbox has unwanted borders :( Anomie⚔ 19:17, 15 November 2011 (UTC)
 * I don't think that is related. The border around userboxes has been there since July. — Edokter  ( talk ) — 19:42, 15 November 2011 (UTC)
 * But the border around the expanding thing in User:Anomie/User Admin adminstats just showed up. Until I used inline styles to override it. Anomie⚔ 20:39, 15 November 2011 (UTC)
 * ✅ [//en.wikipedia.org/w/index.php?diff=460810664&oldid=460788659]. — Edokter  ( talk ) — 18:02, 15 November 2011 (UTC)

Revert?
I was wondering if is it too late to regret my choise of applying the styles directly to the mw-collapsible* classes. I was testing an script which collapses old talk page threads on Portuguese Wikipedia and when I tried it on enwiki I realised that Anomie's suggestion would have been better than mine, because this change is indeed causing unwanted styling to appear on elements which we make collapsible by using  (which force us to [//en.wikipedia.org/w/index.php?diff=prev&oldid=460823525 override it] every time).

So, could you revert that change? Helder 16:44, 14 February 2012 (UTC)


 * I could, but I'd like to know if this breaks any existing uses. — Edokter  ( talk ) — 17:54, 14 February 2012 (UTC)


 * I'll remove editprotected for now until that's sorted out. Tra (Talk) 07:17, 17 February 2012 (UTC)
 * Template:Hidden wasn't updated yet to the new plugin, and it was that template which motivated the inclusion of these selectors, so I don't think it would break anything.
 * Any suggestions on how to make sure it doesn't break (other) existing uses?
 * Helder 17:40, 22 February 2012 (UTC)
 * . Navframe is better off being build from scratch anyway. — Edokter  ( talk ) — 19:06, 22 February 2012 (UTC)

Alternative
See MediaWiki talk:Common.js. Helder 14:05, 5 March 2012 (UTC)

Age doesn't show up on mobile wikipedia
An unresolved issue is discussed at Template talk:Birth date and age. Your assistance would be appreciated. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:38, 20 February 2012 (UTC)
 * Unfortunately it's not really possible to make a good distinction between mobile and print atm. Making all noprint sections mobile visible will dramatically increase clutter. If you have good suggestions, I'm sure the mobile team will welcome them. —Th e DJ (talk • contribs) 21:30, 20 February 2012 (UTC)
 * A more-specific class in the template; and in the CSS?  Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 22:02, 20 February 2012 (UTC)
 * Yeah, that's non-trivial info to be excluding just because of platform. I wonder what else is being affected... — SMcCandlish    Talk⇒ ɖ∘¿ ¤ þ  Contrib.  12:18, 3 March 2012 (UTC)
 * Looks like it's fixed. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 18:38, 3 March 2012 (UTC)

Small bug
Hi, I do not have a clue how this stuff works, but FYI the following discussion:

Template talk:Navbox

The spaces are clearly incorrect. If their inclusion really was an intentional design decision, then that decision was wrong (unless it was a compromise consequence of avoiding worse difficulties elsewhere, or something of that nature, of course). 86.177.105.189 (talk) 03:52, 14 February 2012 (UTC)
 * I concur. Just discovered this behaviour in another template. Undesired spelling. -DePiep (talk) 09:04, 14 February 2012 (UTC)
 * I also concur. The spaces aren't necessary and don't make sense.  --CapitalR (talk) 09:41, 14 February 2012 (UTC)
 * It is a CSS limitaiton which prevents me from removing trailing spaces from generated interpuncts between parent-child lists, and this way is the only way to make them consistent. — Edokter  ( talk ) — 10:16, 14 February 2012 (UTC)
 * Technical limits - I should have thought of that. -DePiep (talk) 10:36, 14 February 2012 (UTC)
 * See also Wikipedia talk:Manual of Style/Accessibility. -- Red rose64 (talk) 09:25, 16 February 2012 (UTC)

Can this be fixed such that the trailing spaces before and after parentheses rising from the ** form of hlist are removed? Or encode it so the spaces only surround the interpunct instead of being placed before and after the list items?— Ryulong ( 竜龙 ) 09:30, 2 March 2012 (UTC)
 * Yes, of course. All you need to do is persuade W3C, Microsoft, Mozilla, Apple, Google, etc. to change the way that browsers render spaces around interpuncts that happen to be parentheses, because it's your browser that's adding the spaces (as it should do if a different character like middot were used). --RexxS (talk) 17:47, 2 March 2012 (UTC)
 * So if all of the basic browsers cannot properly read it, why the fuck are we using it?— Ryulong ( 竜龙 ) 09:59, 3 March 2012 (UTC)
 * They read it perfectly properly. It's just that most characters that are used as interpuncts look right when they have a space each side, but for some reason you don't like a space after '(' or before ')'. Please feel free to suggest an alternative character that comes closer to meeting your aesthetic sensibilities. --RexxS (talk) 18:03, 3 March 2012 (UTC)
 * It is not just someones aesthetic sensibilities. It is incorrect spelling. -DePiep (talk) 11:08, 4 March 2012 (UTC)
 * On the contrary, spaces around parentheses are purely an aesthetic consideration. "Spelling" means the arrangement of letters within a word, not the position of spacing relative to punctuation. The thing which is fixed by the browser is the spacing; the variable is the character used. If you don't like '(', then why not suggest a different character that would look right to you? --RexxS (talk) 18:14, 4 March 2012 (UTC)
 * Maybe you need a short break from this topic, RexxS. Language, after Ryulong I must say, is deteriorating. Again: it is not a personal thing, and don't push it into one. The fact that I don't have a better character (or other solution, I add) does not imply this version is OK. Any regular text with such spacing would be edited. Don't you also implicitly agree that, was there another solution, we'd use it? -DePiep (talk) 18:30, 4 March 2012 (UTC)
 * What is the point of dragging this out ad infinitum? If we all know there is no solution, complaining about it is utterly futile. Have I done weeks of work for nothing? — Edokter  ( talk ) — 18:34, 4 March 2012 (UTC)

Edokter (I got it), would anyone of your standing even contemplate this ugly try: 1. For the opening bracket, use ")" (our regular closing bracket). 2. Envelop it in RLO-PDF "bidi directional enforcing brackets": they write this single character R-to-L, not L-to-R (which is idle for an isolated single character) and since it is a bracket, bidi rule mirrors the bracket, using its mirror bracket: "(" 'closing bracket in R-to-L'. In code, it is RLO)PDF:
 * &rarr; &#x202e;)&#x202c;
 * -DePiep (talk) 19:01, 4 March 2012 (UTC)
 * Probably not, as I don't have full understanding of directional typography, especially in relation to browser support. What I do know is that the spacing is enforced due to the fact the interpunct is placed outside the content of the tag as a hidden text node, and all browsers seperate text nodes and block element with a space. There is simply no way around that. Any attempt to circumvent this behaviour with tricks like direction-reversal or negative margins is bound to fail... believe me, I tried. —  Edokter  ( talk ) — 20:59, 4 March 2012 (UTC)
 * I did some testing, and that's not quite correct. After all, the styling causes the and  to be inline elements, not block elements. Consider the HTML output by MediaWiki for a fairly generic list:


 * Note in particular the linebreaks. As you know, linebreaks and other whitespace in HTML are collapsed to a single space for display. Normally within the list this whitespace is effectively ignored. But when  is given to the  and  elements, it doesn't get ignored. And since the parens come "between" the linebreaks before/after the <ul ></ul> and the linebreaks before/after the first/last  (the effective HTML with the generated parens is something like  ), you get a space in the display. Unfortunately, there seems to be no way to get MediaWiki to output a list without these breaks, thanks to Tidy.
 * If you could apply the parens using selectors like  and   instead (stupid IE&lt;9), then the open/close parens would be after/before the newlines before/after the first/last  and everything would render correctly (the effective HTML with the generated parens would be something like  ). Or you could wait for browsers to support the CSS3   property and then try to get the word-spacing on the s (but not the os) set to  , causing the spaces to have zero width. Or you could wait for browsers to support CSS4 and the   property to use in the same manner.
 * BTW, the suggested hack with RLO/PDF characters doesn't seem to work, at least not when applied using Firebug. It flips the parens as expected, but has no effect on the spaces (as should be expected, since the spaces aren't enclosed in the RLO/PDF and so aren't flipped). Anomie⚔ 02:11, 5 March 2012 (UTC)


 * and  warrants some testing. However, I have IE8 to contend with, and IE6/7 may put up an even bigger fight. I'll report back. —  Edokter  ( talk ) — 09:47, 18 March 2012 (UTC)


 * That css3 looks promising, and if it can work for modern browsers, great; ship it. That it won't work on retarded browsers, is “OK”. It's just a bit of space; no content is lost, things work, get on with "The Project". Alarbus (talk) 10:07, 18 March 2012 (UTC)


 * By golly... I think I fixed it, even for IE8. Had a little problem with conflicts with the numbering for . I didn't touch IE6/7 yet, I'll see about that later. Also, with any luck, bullets should no longer break from their preceding list items. — Edokter  ( talk ) — 11:28, 18 March 2012 (UTC)
 * Unfortunately, the non-breaking space created an extra space after sublists.

Remove blue background for Monobook?
Currently MediaWiki:Monobook.css still has the blue background tint on certain namespaces. I just noticed that MediaWiki:Vector.css doesn't have the same code, so only Monobook users are continuing to be punished by this (specifically Monobook users who haven't locally overridden it). Can the blue tint be dead? Please? --MZMcBride (talk) 23:21, 3 March 2012 (UTC)
 * The distinction between mainspace and other namespaces is one of the things I like about Monobook (and one of the reasons I switched back when the change to Vector was forced on us). HJ Mitchell  &#124;  Penny for your thoughts?  23:47, 3 March 2012 (UTC)
 * It's pale yellow on Dutch Wikipedia. Quite sunny, really. Colours are cool (as long as there are no WP:ACCESS issues). -- Red rose64 (talk) 00:01, 4 March 2012 (UTC)
 * "Punished"? Personally, I like it. Anomie⚔ 14:14, 4 March 2012 (UTC)
 * I actually like it myself too. ~ &#8658;TomTom  N00  @ 00:52, 18 March 2012 (UTC)
 * I'd like to remove it from monobook. What do I have to put in my css to get rid of it? MathewTownsend (talk) 14:30, 19 March 2012 (UTC)
 * You can override the default colour by setting a different one: gives a pale yellow. -- Red rose64 (talk) 16:06, 19 March 2012 (UTC)
 * thanks! MathewTownsend (talk) 16:09, 19 March 2012 (UTC)
 * that turns the color white for me - which is good. But when I opened this page to edit it, the background is yellow! strange. MathewTownsend (talk) 16:15, 19 March 2012 (UTC)
 * this page is a (pretty bright) yellow, but regular article pages are white. MathewTownsend (talk) 16:17, 19 March 2012 (UTC)

but some pages are still bluish, like "Contributions". MathewTownsend (talk) 16:19, 19 March 2012 (UTC)
 * I didn't say it was guaranteed to work. Not knowing where to find the relevant documentation, I opened a few sample page sources, found a scope enclosed by the <body ></body> but which enclosed the <h1 ></h1> and subsequent block elements. The source for this particular page showed that the choices were    - I picked the innermost id=  and the most likely-looking class which would catch talk pages, and then I styled that. The yellow was just a demonstration that shows a noticeable difference. You can pick any colour you like - white is  . -- Red rose64 (talk) 17:06, 19 March 2012 (UTC)
 * I know you didn't say it was guaranteed to work. Thanks for the suggestion! I'd have to spend some time figuring out the code. Decided that I would just use vector for now, but maybe I'll fiddle are with it, per your suggestions. Thanks! MathewTownsend (talk) 18:09, 19 March 2012 (UTC)
 * Vector uses a declaration that sets the general content background colour to white. If you wanted all of your content to have a white background (rather than just the talk page backgrounds) You could place a similar declaration in your monobook.css like this:  --RexxS (talk) 18:22, 19 March 2012 (UTC)
 * I agree about the  technique working in all namespaces. I fiddled about with classes because I was under the initial impression that the desired change was just to the background of talk pages, not of all pages. -- Red rose64 (talk) 19:41, 19 March 2012 (UTC)
 * ok, will try. Thanks, MathewTownsend (talk) 20:00, 19 March 2012 (UTC)

works beautifully! MathewTownsend (talk) 20:03, 19 March 2012 (UTC)

Wikitable margins
Check the table on the right:

foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a fadsoo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo adsa foo a foo a foo a foo a foo a foo a foo a foo adsada foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo dasa foo a foo aads foo a foo a foo a foo a foo a foo a foo a foo a asdfoo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a foo a.

It seems to get fixed with a margin-left of 6px. --Locos epraix 05:00, 16 January 2012 (UTC)

<pre style="margin-left:1.5em;">


 * makes →
 * If one is already using styles to customise the table, the addition of an adjustment to the margin seems quite trivial. What is it that you are pointing out or requesting? Your right floated table has a margin of, just as the left floated table does. There may be another class that can be added to   to alter the margins of right floating tables. Is that what you're after?  f<i style="color:#0dd;font-size:10px;">red</i>g<i style="color:#0dd;font-size:10px;">andt</i>  06:02, 16 January 2012 (UTC)
 * Point is fixing this issue without adding additional complexity for editors. --Locos epraix 06:12, 16 January 2012 (UTC)
 * The default layout of a wikitable is indeed to be left aligned, just as an Infobox is by default designed to be right aligned. If you want to make it right aligned, you need to manually override. Additional classes could be added I guess, but i'm not sure if that actually makes it that much easier to use.... —Th e DJ (talk • contribs) 09:38, 16 January 2012 (UTC)
 * A general class .right which could be used for all floating elements sounds like a good idea. — Edokter  ( talk ) — 11:50, 16 January 2012 (UTC)
 * Just found 33445. — Edokter  ( talk ) — 11:53, 16 January 2012 (UTC)
 * Please do not use pixel-units; prefer em. So for a right-floated wikitable you'd include style="margin-right: 0; margin-left: 1em;" Best to simply allow top/bottom to have the default. Alarbus (talk) 10:05, 16 January 2012 (UTC)


 * From the 1.19 update release notes: "Style rules for wikitable are now more specific and prevent inheritance to nested tables which caused various issues." Before we get deep into changes, I suggest testing at http://labs.wikimedia.beta.wmflabs.org. ---—  Gadget850 (Ed)  talk 12:19, 16 January 2012 (UTC)
 * Aah, so that is why the IE6-breaking CSS was introduced. I already submitted a patch to revert this change. — Edokter  ( talk ) — 12:41, 16 January 2012 (UTC)
 * See Help talk:Table. IE6 is listed as 2.22% use across projects per . — Preceding unsigned comment added by Gadget850 (talk • contribs) 12:50, 16 January 2012‎ ((UTC)
 * As long as IE6 is still officially supported, this is a breaking change. It means IE6 will have no wikitable styling at all. So either it wall have to be reverted, or IE6 needs to be taken off the list of supported browsers; we can't have it dangling in limbo like this. — Edokter  ( talk ) — 12:58, 16 January 2012 (UTC)
 * IE6 is still in use throughout the world, although even Microsoft would like to see it go away: http://www.ie6countdown.com/ and the only reason for continuing to use IE6 is if you are stuck with a computer running Windows 2000, a product that Microsoft ceased to support in July last year. It's worth noting that Google has been gradually dropping support for IE6 for twelve months now, and at some point we are going to have to make the same decision. "Sooner rather than later" has my !vote --RexxS (talk) 14:23, 16 January 2012 (UTC)
 * What breaks when a wikitable is viewed with IE6? I also see that 1.19 is dropping CSS for IE5.0 and 5.5. ---— Gadget850 (Ed)  talk 14:31, 16 January 2012 (UTC)
 * The new CSS uses direct-child selectors (>) which will cause IE6 to not have any cell styling at all; no borders, no background color. — Edokter  ( talk ) — 14:53, 16 January 2012 (UTC)
 * Wow... IE6 still acounts for over 25% in China alone. — Edokter  ( talk ) — 14:57, 16 January 2012 (UTC)
 * FYI, IE 5.0 and IE 5.5 support was already dropped in Mediawiki 1.17 actually. Perhaps not officially, but it has been in a 'not specifically fixing stuff for it anymore'-mode since at least that version. —Th e DJ (talk • contribs) 08:35, 17 January 2012 (UTC)
 * MediaWiki Browser compatibility list IE5/5.5 as "red", that is as "official" as it gets. — Edokter  ( talk ) — 11:50, 17 January 2012 (UTC)

I like the idea of a .right class. But it would be nice if the .wikitable class (alone) looks good right aligned given it's widespread use. --Locos epraix 15:31, 16 January 2012 (UTC)
 * As stated before, the vast majority of wikitables in use is either non- or left-aligned. — Edokter  ( talk ) — 16:05, 16 January 2012 (UTC)
 * That's a very strong statement and begs for Citation needed. Ggenellina (talk) 19:42, 16 January 2012 (UTC)


 * According to http://www.w3counter.com/globalstats.php IE 6 has a global usage of only 1.43% and Windows 2000 accounts for only 0.09% global OS use. I'd definitely support not supporting IE 6 if those figures can be relied on.  f<i style="color:#0dd;font-size:10px;">red</i>g<i style="color:#0dd;font-size:10px;">andt</i>  00:49, 17 January 2012 (UTC)


 * We should let IE6 users have the content with bare bones styling:
 * http://code.google.com/p/universal-ie6-css/
 * The rest of us moved on a long time ago. Drop IE7 and "incompatibility" mode, too. Alarbus (talk) 08:47, 17 January 2012 (UTC)


 * For those advocating dropping supprot for IE6, please review MediaWiki Browser compatibility and Backward compatibility with old browsers. — Edokter  ( talk ) — 11:47, 17 January 2012 (UTC)


 * 0.1% eep!  f<i style="color:#0dd;font-size:10px;">red</i>g<i style="color:#0dd;font-size:10px;">andt</i>  12:44, 17 January 2012 (UTC)
 * Hey, while we're about it, let's drop all IE support, force MS to get in line. -- Red rose64 (talk) 18:42, 17 January 2012 (UTC)
 * I don't dispute IE6 marginal usage, but this statement: the vast majority of wikitables in use is either non- or left-aligned. That requires some kind of statistical evidence. Ggenellina (talk) 00:10, 20 January 2012 (UTC)
 * Why should I have to come with the evidence and not you? Most tables I see that float right are templates that have their own classes and styling (e.g. infobox). But I have never actually seen a right-floating wikitable. — Edokter  ( talk ) — 00:53, 20 January 2012 (UTC)
 * check out the tables in Colorado River. it would be really really nice if we could have a CSS class to add "float: right; clear: right; margin: ..." or "float: left; clear: left; margin: ..." or "float: none; clear: both; margin-left: auto; margin-right: auto".  My current plan was to use something like float style, but if we had this I would ask for speedy deletion of that template instead of adding it to nutritional value, sidebar, location map+, ...  we could instead just say something like class="floatright" or class="floatleft" or class="floatcenter", although it might be even better to have options for both floatright and clearright together. Frietjes (talk) 15:41, 23 March 2012 (UTC)

Parser function errors
Dtsh is a variant of dts that does not show the output. This also means that a parser function error such as invalid time is not shown and troubleshooting table sorting is painful. I would like to add some CSS so that the hidden output can be overridden in personal CSS:

We can then update dtsh to use this class. ---— Gadget850 (Ed)  talk 17:58, 26 April 2012 (UTC)


 * dts and date sortable also do this. Perhaps it would be better to name the class displaynone for more universal use. ---— Gadget850 (Ed)  talk 14:58, 27 April 2012 (UTC)
 * "displaynone" might be a little too generic; it could be used for any case where someone wants to apply "display:none" to something even when it isn't one of these errors. Perhaps "hiddenerror" or something along those lines? Anomie⚔ 16:18, 27 April 2012 (UTC)

Bug 32626
The resolution of in 1.20 added a class to the default for MediaWiki:Cite references link one and MediaWiki:Cite references link many. This allows styling to remove the reference backlinks from in the printed version. To enable this, we would have to update the interface pages, since we use a custom version and add the class to Print.css. ---— Gadget850 (Ed)  talk 02:26, 3 May 2012 (UTC)
 * And we can remove the newlines in those interface pages since is resolved. ---—  Gadget850 (Ed)  talk 02:47, 3 May 2012 (UTC)
 * Changes to the interface messages are ✅. Does the non-printing follow automatically with global CSS, or do we need to make edits to this page too? Anomie⚔ 19:41, 3 May 2012 (UTC)


 * Looks like we need to add  to MediaWiki:Print.css. ---—  Gadget850 (Ed)  talk 20:14, 3 May 2012 (UTC)

Nope, it is still bolding stuff
The current full reversion is still bolding changes by default. Unhooray. Fifelfoo (talk) 22:30, 10 May 2012 (UTC)
 * Should be fixed now. <span style="font-family:Palatino, Georgia, serif;">Steven Walling &bull; talk   22:33, 10 May 2012 (UTC)
 * Whew! Thanks!  Fifelfoo (talk) 22:34, 10 May 2012 (UTC)
 * Sadly the CSS removing the bolding should be undone. It's a hack that removes bolding elsewhere. Per the WP:VPT discussion, I'm going to undo all of my and Edokter's edits. If people want the site's configuration changed to remove the bolding, they should comment on the VPT and the bug referenced there. <span style="font-family:Palatino, Georgia, serif;">Steven Walling &bull; talk   23:42, 10 May 2012 (UTC)
 * Okay done. I am going to stop mucking with things, so if anyone feels strongly about removing the bolding again, adding back the stars or choosing a completely different option, feel free to go for it. ;) <span style="font-family:Palatino, Georgia, serif;">Steven Walling &bull; talk   23:48, 10 May 2012 (UTC)


 * GET RID OF THE BOLD!. Constantly having every-fucking-THING on your watchist in bold if you just started the day's editing is EXTREMELY distracting and does NOT make a good work environment. Hopefully this bolded paragraph will be able to aptly demonstrate what I mean! Barts1a / Talk to me / Help me improve 01:18, 11 May 2012 (UTC)
 * Not really, seeing as almost certainly your email client does the exact same thing. Bold is unread. Perhaps it was too bold, or perhaps users just need to see no changes ever, but regardless this is a feature used on most other wikis, including Commons, to great use. -  ʄɭoʏɗiaɲ  τ ¢ 14:48, 12 May 2012 (UTC)
 * I have no doubt that a lot of people like it or don't care about it. I also find it quite distracting and feel strongly that it should be 'opt in. Surely there is someone out there somewhere that can devise a way for this to be opt in? We have that nifty button to clear it, can't someone devise a way to set it to autoclear for those of use that don't wanna see it. Kumioko (talk) 15:01, 12 May 2012 (UTC)


 * Note - at the moment, the css has been modified so that the watchlist has no highlights (how it was before). The facility to highlight is still available, and offers the opportunity for customising your watchlist to what suits your eyes - see WP:CUSTOMWATCH for some suggestions. What needs to be done now is some communication to users - maybe a watchlist notice - to see if there is one particular style that is favoured. It would also be nice to have a gadget that mimics an 'opt-in'  - it's not possible to actually opt in/out of the software change, it changes it for the entire wiki, but you could have something that looked like it was doing the same thing by modifying custom.css to the option the user selects.  If users feel they have a bit of control over it, and can pick what suits their eyesight/usage then this will be an enormous net positive. More discussion is at Village_pump_(proposals). Elen of the Roads (talk) 15:55, 12 May 2012 (UTC)
 * Suggestion for comms to users now posted at above link. All comments, criticism etc welcome. Elen of the Roads (talk) 12:08, 13 May 2012 (UTC)

Right alignment and row headers in highway junction lists
I primarily work on highway articles, and I'd like to get our junction/exit list templates up to snuff on accessibility. It has been suggested that our mileposts function as the keyword for each individual row of these tables, and that they should have  coding. I've tested this in a table using  syntax, but that left-aligns the the column. As a column full of numbers with decimal points, those should remain right-aligned. I'm asking here for a simple fix. Can we have a  that would do the same thing, but right-align the text? Or can we change the coding that specifies that row headers using the current class must be left-aligned? Either works, and once something is implemented, I can update the templates used by us to add the row headers to thousands of highway articles' junction/exit lists. Thanks.  Imzadi 1979  →   05:16, 8 May 2012 (UTC)
 * It is recognised that tables often contain cells that function as both a data cell and a row header (i.e. a keyword, as in a database, if you like). It is good to mark these cells up as headers and assign them the row scope, as that ensures that widest range of assistive technology will recognise their function. The problem, of course, lies with the '!' which translates into html as  (table header). Most browsers will then render the cell as bold with centred text by default, but many editors prefer to see the data with its usual alignment and weight, because it is also data in that row of course.
 * That was the reason for the "plainrowheaders" class, which forces left-alignment and normal weight, to give some choice of display to editors when implementing  coding to existing tables. It seems to me that there is an exactly equivalent reasoning to support a "plainrowheaders-right" class for use where the keydata would normally be right-aligned, such as numbers. It would be less commonly used, I suspect; but for cases where it is useful, it would be clearly preferable to having to hard-code inline CSS such as   on every row. I'd support this proposal. --RexxS (talk) 13:34, 8 May 2012 (UTC)

Ok, since this doesn't seem controversial, and if it was, people would have jumped around here to oppose the suggestion by now given the brouhaha over the watchlists, I'm placing an edit request to have this added. Would an admin please add the following code? /* Normal font styling for table row headers with scope="row" tag needing right alignment */ .wikitable.plainrowheaders-right th[scope=row] { font-weight: normal; /* @noflip */ text-align: right; }

It is exactly the same code used for  with two minor modifications: the right alignment and the name. Thanks,  Imzadi 1979  →   21:09, 11 May 2012 (UTC)


 * I'm not so sure about this. Any header or cell that wants right-aligned text needs the inline css (or another class), and right-aligned is not considered 'plain' (which is left-aligned). I'm not in favor. — Edokter  ( talk ) — 22:16, 11 May 2012 (UTC)
 * I've tried using the existing class in a template that specified that the cell needs to be right-aligned... and the CSS overrode the article and left-aligned it. I had to revert my change to add row headers to jctint/core (the core template used for the junction list table rows) even though jcttop/core is using . (The article I looked at used templates that use the core.) In short, I wouldn't have proposed a change to the CSS if the template would have worked with what's here already.  Imzadi 1979   →   22:23, 11 May 2012 (UTC)
 * Oh, as for for "plain" not being right aligned, I read "plain" in this context as "not bold".  Imzadi 1979  →   07:25, 12 May 2012 (UTC)
 * No, "plain" refers to the header cell being formatted as a regular data cell. So the terminology is correct. Right-alinged cells are custom-styled, so they are defenitely not plain. — Edokter  ( talk ) — 21:37, 14 May 2012 (UTC)
 * We're going to have to agree to disagree on that. My word processor and spreadsheet applications don't apply "plain" to meaning anything related to alignment; they apply it to text formatting as in plain vs. bold/italics/underline/etc. Spreadsheets right align columns of numbers by default normally in my experience. This formatting is intended for mileposts and other data that is both numerical and the keyword/keydata/etc for the table row, and properly the row header. I don't care exactly what we call it, let's get something implemented before another highway article goes to FAC and someone complains that the exit lists don't have row headers, which currently can't be supported in the templates we use.  Imzadi 1979  →   22:55, 14 May 2012 (UTC)


 * Full support these changes are necessary to fully comply with accessibility guidelines. --Rschen7754 07:20, 12 May 2012 (UTC)


 * Editprotected disabled for now as there seems to be some opposition. Chris Cunningham (user:thumperward) (talk) 13:47, 14 May 2012 (UTC)


 * Support, no need to block this based on one users interpretation of "plain" (which as pointed out by imzadi, correctly, is used to refer to formatting of the font. Plain has nothing to do with left or right alignment.). I've reenabled the request since the user having an issue hasn't responded after 72 hours and hasn't provided any solid reasoning behind their opposition. -  ʄɭoʏɗiaɲ  τ ¢ 21:33, 14 May 2012 (UTC)
 * Well, I have now, so let's discuss this further. — Edokter  ( talk ) — 21:38, 14 May 2012 (UTC)
 * If your opposition is predication only on the name, as it appears, then suggest a different name and let's get this done. As I've explained twice already here and at your talk page, before my initial post here when I modified the templates, the CSS overrode the right alignment of the templates to the left alignment of the class. We need a different class to accomplish this, and if it's just a name (and we can agree to disagree there) let's get the name fixed so this can be implemented.  Imzadi 1979  →   22:49, 14 May 2012 (UTC)
 * A more generic name would be more suitable. th-right, which then should be used in conjunction with plainrowheaders.

/* Right-align row header cells in tables */ .wikitable.th-right th[scope=row] { /* @noflip */ text-align: right; }
 * — Edokter  ( talk ) — 19:51, 15 May 2012 (UTC)
 * And how would that work? I've tried  in an article, and it doesn't work. You can get sortable, or plainrowheaders, but not both because there isn't a "wikitable sortable plainrowheaders" class in the CSS. So if that's the case, we can't combine your class with the existing plainrowheaders class, unless there is something not documented someplace on how to combine two classes together.  Imzadi 1979   →   20:08, 15 May 2012 (UTC)
 * Correct: there isn't a, but that's not an omission, it's the way that HTML 4 works. Class names cannot contain spaces - spaces are the separators between classes, and they are applied from left to right. So, when you specify  , you're applying three separate classes in turn: first the   class is applied, then  , then  . If there are any contradictions, the one(s) which are applied later have precedence over the one(s) applied earlier. Thus, it's possible that   overrides some or all of  . Try exchanging the last two -   - to see if that helps. -- Red rose64 (talk) 21:25, 15 May 2012 (UTC)
 * Didn't work for either "wikitable plainrowheaders" or "plainrowheaders wikitable" - The columns wound up left-aligned in both cases. --Rschen7754 21:48, 15 May 2012 (UTC)
 * One slight correction: it's not the order of the classes in  that matters, it's the specificity and the order they're defined in the CSS files or  tags. Anomie⚔ 01:24, 16 May 2012 (UTC)

Centering an hlist in a wikitable
(Original thread: Template talk:Flatlist) Basically, the question is if we can add some functionality to make it possible to center a flatlist in a wikitable. For example, compare with or with or with the issue is with the code .wikitable td ul, .wikitable td ol, .wikitable td dl { /* @noflip */ text-align: left; } which seems sensible, but causes problems if we want to use an hlist. Frietjes (talk) 17:54, 18 May 2012 (UTC)
 * Actually it will also cause problems if one wishes to use a plainlist that will look better centered, e.g. to list synonyms inside a taxobox without losing the horizontal space of the bullet (as the bullets may cause unwanted line breaks) Circéus (talk) 19:09, 18 May 2012 (UTC)
 * true that it will cause problems with plainlist, although I don't think this is an issue with taxobox, since it uses the infobox class instead of the wikitable class. In the examples above, I show that it works for the infobox class. Frietjes (talk) 20:12, 18 May 2012 (UTC)
 * True. Stupid oversight on my side. The question stands that I'm not sure why we need to hardcode this in the first place. I mean, with the sheer amount of aligning that inevitably goes in table, I'm not clear it fixes a problem that genuinely needs fixing, and it clearly is causing problems elsewhere. Circéus (talk) 03:07, 19 May 2012 (UTC)
 * tweaking what WOSlinker just tried, the following worked for me in my vector.css (could add the same for plainlist?)

/* lists in data cells are always left-aligned unless they also use the hlist class */ .wikitable.hlist td ul, .wikitable.hlist td ol, .wikitable.hlist td dl { text-align: inherit !important; }
 * Frietjes (talk) 22:40, 18 May 2012 (UTC)


 * I've added that in now. -- WOSlinker (talk) 05:25, 19 May 2012 (UTC)
 * Why is the !important necessary?  already has a higher specificity than , and the !important makes it so you can't override it with   if for some reason you want to do that. Anomie⚔ 14:30, 19 May 2012 (UTC)
 * I wondered about that as well. I can't find anything that could override the inherit. Removed. — Edokter  ( talk ) — 14:40, 19 May 2012 (UTC)

Please undo the last change. It breaks functionality for one group for the aesthetic appeal of another
The people complaining about the button should deal with it until an alternative is in place, it's an aesthetic annoyance. Removing it entirely disables the ability for those of us who want to use this to mark pages, and functionally disables it. -  ʄɭoʏɗiaɲ  τ ¢ 16:19, 18 May 2012 (UTC)

After all the previous discussions and outcry, another unilateral step??? Seriously??? Please revert as per previous consensus. Nageh (talk) 17:56, 18 May 2012 (UTC)
 * If you have opted in by adding something to your custom CSS, then simply do the same with the button:

.mw-special-Watchlist #mw-watchlist-resetbutton { display: block; }
 * in the same way. If there is a gadget being used to opt in then add that code to the gadget. I like having the bolded watchlist too; but since the only way to get it is by editing your custom CSS, I'm ok with the fact that you need to add this too. If the decision by the community is for this feature to be unavailable by default, then we must not confuse new users with this meaningless button. ST47 (talk) 21:37, 23 May 2012 (UTC)
 * Thank you. I didn't know there was a code in place to make it reappear. -  ʄɭoʏɗiaɲ  τ ¢ 21:58, 23 May 2012 (UTC)
 * Glad I could help. Generally, anything CSS can be undone - it's called "cascading" because you can override absolutely anything, and I wouldn't have hidden it by default if it wasn't possible to override. ST47 (talk) 22:02, 23 May 2012 (UTC)
 * Why should I and every other user have to manually edit my CSS page every other day because someone else has had a bright idea about how to improve the default display? Just leave the damn thing alone until the RFC is finished, please. --R'n'B (call me Russ) 23:00, 23 May 2012 (UTC)
 * You could always create a CSS gadget that everyone could use, if it weren't for the absurd amount of bikeshedding going on. ST47 (talk) 01:54, 24 May 2012 (UTC)

If this page weren't already admin-edit-only, it would have been protected by now; I'm somewhat tempted to full-protect it anyway just to make the point. The feature is disputed and a discussion is underway. You do not have the magic answer that everyone involved with the discussion will certainly agree with. As RnB says, leave the damn thing alone, in the Wrong Version, until it's finished. Failure to do so is wheel warring. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 23:43, 23 May 2012 (UTC)
 * Can you present any reason why the current version is the correct version, other than the fact that it happens to be the current version? ST47 (talk) 01:52, 24 May 2012 (UTC)
 * Seconded. Why the hell do people keep reverting to the broken half-hidden state that exists only because the admins who first jumped the gun to hide the bolding in the face of whining on the Village pump did the job only half-way? Personally, I wish we would just remove the whole mess, leaving the feature at the MediaWiki default until the discussion concludes. Anomie⚔ 03:35, 24 May 2012 (UTC)
 * Thirded. I personally believe that the feature should remain disabled until the discussion concludes, but enabling it now would be vastly preferable to this bizarre mishmash.
 * Can someone please explain how it makes any sense to display a button that serves no absolutely purpose (unless a feature is manually added, in which case the button can be added simultaneously)?
 * This undoubtedly is causing a great deal of confusion. What's the benefit?  —David Levy 04:31, 24 May 2012 (UTC)
 * Did you not notice the link, capitalisation and trademark sign? Of course it's the Wrong Version.  Just like ST47's version, Anomie's version, and the versions of everyone else who's mucked around with this feature in the past few days.  This is a textbook example of when to drop the edit box and focus on building consensus; just because we don't have the technical means to enforce protection from edit warring here doesn't mean it can't happen.  The world is not going to end if an apparently-pointless button appears on the watchlist for a few days.
 * Or, of course, find consensus for the change; there's no need to be slaves to bureaucracy. You can add me to the list of people who agree that it should be hidden if the display is, making it four in favour and one against.  I'd suggest that with so much... high spirits... surrounding this issue, you need a consensus of a dozen or so editors to ensure that the change produces more light than heat. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 09:22, 24 May 2012 (UTC)
 * I'm in violent agreement with everyone that the current setup makes no sense. But it is the current setup and every time you change it, by adding a green star or adding a "C" or changing bold to underline, or making the button visible or invisible, or maybe using some of that damned blinking text that drove everyone crazy twenty years ago, you force every user who has personalized their CSS for this feature to go back and do it again.  That's just unreasonable, even if it means that we have to live with an illogical interface for a couple of weeks.  Like Happy-Melon said....  --R'n'B (call me Russ) 10:30, 24 May 2012 (UTC)
 * And you reverted to it anyway? I'm stunned.
 * The quantity of users who have "personalized their CSS for this feature" is infinitesimal in comparison with the quantity for whom a useless button now appears on the watchlist. You seriously advocate that we deliver an interface that you acknowledge "makes no sense" (thereby confusing countless users) to avoid mildly inconveniencing you and a handful of others?  Unreal.
 * What's "unreasonable" is a belief that this is about us (as opposed to the vast majority of editors with no knowledge of this dispute, who simply seek to utilize their watchlists without confusion). —David Levy 16:56, 24 May 2012 (UTC)
 * This isn't a "Wrong Version"-type scenario, given the fact that it primarily affects innocent bystanders (whose watchlists confusingly contain a button with no discernible purpose). When it comes to the site interface, this isn't about us.  —David Levy 16:56, 24 May 2012 (UTC)
 * Which is a wonderful argument for undoing all the changes that have happened to date, and restoring the default bolding that MediaWiki provides.--Jorm (WMF) (talk) 18:08, 24 May 2012 (UTC)
 * Agreed. As noted above, I personally favor leaving the feature disabled (pending consensus for its use), but either consistent setup is reasonable.  A random mishmash is not.
 * Can we please either re-enable the feature or remove the button? —David Levy 18:34, 24 May 2012 (UTC)
 * Which is a wonderful argument for undoing all the changes that have happened to date, and restoring the default bolding that MediaWiki provides.--Jorm (WMF) (talk) 18:08, 24 May 2012 (UTC)
 * Agreed. As noted above, I personally favor leaving the feature disabled (pending consensus for its use), but either consistent setup is reasonable.  A random mishmash is not.
 * Can we please either re-enable the feature or remove the button? —David Levy 18:34, 24 May 2012 (UTC)

This situation inspired me to write an essay: WP:NOTUS. —David Levy 00:13, 25 May 2012 (UTC)


 * I like your essay. The Greek god of hot air, er, wind, is a nice touch.
 * But let me offer you a parable to explain my view. Suppose you like to cook as a hobby, and every day you come home from work and you enjoy preparing a nice dinner.  One day, you come home and find that your spouse, partner, roommate, or whoever you live with has rearranged all the kitchen drawers and cabinets and none of your pots, pans, and utensils are where you expect them to be.  You protest, but the rearranger patiently explains that the new setup is much more logical and efficient than the old one, and you don't want to offend them, so you put up with it.  The next day, you come home, and everything has been rearranged yet again, and again the person who did it explains that this arrangement is even better than yesterday's and will enable you to get the implements you need even more quickly.  Tell me, for how many days in a row would you put up with this?  After two or three days, I suspect you would either move out, or pitch all the cooking tools in the trash and call in a pizza.  It wouldn't matter if the new arrangement was better or the old one was illogical, would it?  --R'n'B (call me Russ) 09:44, 25 May 2012 (UTC)


 * You're still making this about us.
 * Indeed, some administrators made a bunch of ill-advised changes, resulting in annoyance and frustration (to me too!). But your analogy is flawed in the respect that it focuses exclusively on your perspective.
 * In real life, the watchlist isn't your personal kitchen or anything comparable; it's used by many people around the world. By default, it currently contains a button that serves no apparent purpose, which undoubtedly is causing significant confusion.
 * You've acknowledged that this setup "makes no sense", but you nonetheless reverted to it to avoid mildly inconveniencing a handful of editors by forcing them to update their code again. You're putting the needs of a tiny minority (comprising expert users, the ones most capable of coping with such issues) before the needs of the vast majority (most of whom don't even know how to modify their CSS).  This is highly illogical.
 * Imagine that a wheel war over whether the heading should read "My watchlist" or "Watchlist" inadvertently leads to "y watchlist". Would you revert to this intermediate state and demand that we "leave the damn thing alone until the RFC is finished" (on the basis that a few dozen editors customized their CSS to convert "y watchlist" to their preferred wording)?  That's analogous to what you're doing.  The difference is that "y watchlist" probably wouldn't cause much actual confusion.  —David Levy 14:28, 25 May 2012 (UTC)


 * I think you're significantly overstating the amount of "confusion" this situation actually causes. It's a button that has no apparent purpose; people click it, wonder what happened, and then move on.  I hardly think you'd be able to find many people who have given it anything more than a passing thought.
 * When considering what we do on Wikipedia, I fully endorse the point you're making in WP:NOTUS, and I think it's something that is all too often overlooked. The consideration of other editors has primacy when dictating what we should not do, and TWV, WP:BRD and so forth are all demonstrating why: the principle that we are a community that works collaboratively and always resolves differences of opinion by discussion and consensus, is more important than, and independent of, any individual issue.  We have left far more visible areas of Wikipedia in far greater disarray for far longer (like, IMO, many of the pages linked to from the Main Page, for about five years now) while we debate how best to deal with them.  This is hardly the most egregious example.  <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 18:40, 25 May 2012 (UTC)


 * And that seems fine to you? For thousands of users to discover a new button, attempt to use it, and wonder why it doesn't do anything?
 * And that passing thought is one of confusion, followed by the realization that Wikipedia is sloppy enough to provide broken buttons (or a concern that something is wrong on their end).
 * This isn't the type of situation described at The Wrong Version (in which some editors prefer one setup, others prefer another, and protection invariably leads to assertions from one side that "the wrong version" has been favored).
 * In this instance, no one believes that the current setup should have existed in the first place. Even the editor who reverted to it has acknowledged that it "makes no sense".
 * To apply the BRD principle, "B" either was enabling the feature (in which case its removal constitutes "R") or the insertion of code suppressing the MediaWiki default (in which case the code's removal constitutes "R").
 * Have we ever deliberately retained a broken setup that everyone agreed made no sense? —David Levy 21:38, 25 May 2012 (UTC)
 * In this instance, no one believes that the current setup should have existed in the first place. Even the editor who reverted to it has acknowledged that it "makes no sense".
 * To apply the BRD principle, "B" either was enabling the feature (in which case its removal constitutes "R") or the insertion of code suppressing the MediaWiki default (in which case the code's removal constitutes "R").
 * Have we ever deliberately retained a broken setup that everyone agreed made no sense? —David Levy 21:38, 25 May 2012 (UTC)
 * Have we ever deliberately retained a broken setup that everyone agreed made no sense? —David Levy 21:38, 25 May 2012 (UTC)


 * I like this inline-quoting response method... :D
 * Of course it's not perfect. But Wikipedia isn't perfect.  And the sky isn't going to fall if it remains imperfect for a little while longer, whereas the sky might get a little higher if everyone is able to discuss what needs to be discussed without any unnecessary drama being stoked.
 * Cough RFA. Cough Main Page.  Cough ArbCom voting algorithm.  If we don't agree on how best to fix something, it tends to remain broken.  But if you want a more down-to-earth example, try A Simple Plan (novel).  Backwater stub that's been on my watchlist for years; can't even remember how it got there.  Endless ongoing edit war between a stupidly huge plot summary, a medium-sized summary that would be fine for a 'complete' article, and the insufficient few sentences that's there at the moment IIRC, and that everyone agrees is not 'correct'.  But it's sat there for years.  Every admin knows of an article like this; each insignificant individually, but collectively a huge phenomenon which is simply part and parcel of the way Wikipedia works, and has to work. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 22:16, 25 May 2012 (UTC)
 * Cough RFA. Cough Main Page.  Cough ArbCom voting algorithm.  If we don't agree on how best to fix something, it tends to remain broken.  But if you want a more down-to-earth example, try A Simple Plan (novel).  Backwater stub that's been on my watchlist for years; can't even remember how it got there.  Endless ongoing edit war between a stupidly huge plot summary, a medium-sized summary that would be fine for a 'complete' article, and the insufficient few sentences that's there at the moment IIRC, and that everyone agrees is not 'correct'.  But it's sat there for years.  Every admin knows of an article like this; each insignificant individually, but collectively a huge phenomenon which is simply part and parcel of the way Wikipedia works, and has to work. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 22:16, 25 May 2012 (UTC)
 * Cough RFA. Cough Main Page.  Cough ArbCom voting algorithm.  If we don't agree on how best to fix something, it tends to remain broken.  But if you want a more down-to-earth example, try A Simple Plan (novel).  Backwater stub that's been on my watchlist for years; can't even remember how it got there.  Endless ongoing edit war between a stupidly huge plot summary, a medium-sized summary that would be fine for a 'complete' article, and the insufficient few sentences that's there at the moment IIRC, and that everyone agrees is not 'correct'.  But it's sat there for years.  Every admin knows of an article like this; each insignificant individually, but collectively a huge phenomenon which is simply part and parcel of the way Wikipedia works, and has to work. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 22:16, 25 May 2012 (UTC)


 * The point isn't that it's imperfect. It's that it's dramatically inferior to an obvious alternative.
 * Those don't come close to fitting the question's criteria. There isn't consensus that they're broken, let alone that they make no sense.  Nor are there alternative setups that everyone agrees should have been implemented instead.
 * We all agree that the feature shouldn't have been disabled while leaving the button in place. The fix is clear-cut, and the only question is whether the collateral damage (occurring because the task was botched in the first place) is significant enough to stand in the way.
 * But I'm not trying to be stubborn. I want to alleviate the confusion, and I'm open to alternative approaches.  Please see my idea below.  —David Levy 22:58, 25 May 2012 (UTC)
 * We all agree that the feature shouldn't have been disabled while leaving the button in place. The fix is clear-cut, and the only question is whether the collateral damage (occurring because the task was botched in the first place) is significant enough to stand in the way.
 * But I'm not trying to be stubborn. I want to alleviate the confusion, and I'm open to alternative approaches.  Please see my idea below.  —David Levy 22:58, 25 May 2012 (UTC)
 * But I'm not trying to be stubborn. I want to alleviate the confusion, and I'm open to alternative approaches.  Please see my idea below.  —David Levy 22:58, 25 May 2012 (UTC)


 * Comment these >99.9% claims are bogus. Our readers don't have a watchlist; our editors do. The button being there causes as much confusion as any big red button: You push it, then try to figure out if anything happened. Not that much to it. Having it there until a FINAL outcome is decided upon will not cause the sky to fall, will not break functionality, and will not make things difficult to read as the bold may to some. It may perhaps confuse those who haven't encountered it yet, but our savvy editors can surely figure it out quickly enough. As RnB mentioned though, having to update my css every two or three days is far more annoying than a button could ever be. Are there no tech-savvy admins able to quickly slap the css into a gadget as a temporary stopgap? -  ʄɭoʏɗiaɲ  τ ¢ 18:57, 25 May 2012 (UTC)


 * You appear to have misunderstood. I don't assert that this issue impacts most readers.  While the essay is intended to be more general, in this discussion, I'm referring specifically to Wikipedia's editors.
 * Let's say that 300 people have enabled the feature via CSS (a very high estimate). If we consider only the registered English Wikipedians deemed "active" by the Wikimedia Foundation (those performing five or more edits per month), that amounts to less than 1% of them, leaving more than 99% for whom the button is useless.
 * And of course, the advanced users who have tweaked their CSS to enable the feature can easily do so for the button as well.
 * And I'm baffled as to how that scenario, unfolding for thousands of users, is preferable to the alternative of mildly inconveniencing a tiny handful of advanced editors.
 * I disliked the bolding, but at least it made sense.
 * Our "savvy" editors (a small minority) can figure out how to tweak their CSS. This includes those with the feature enabled (a much smaller minority).
 * Everyone else has a broken button.
 * Agreed. And I was among those criticising the back-and-forth-and-sideways changes.  But again, it's unreasonable to focus on ourselves at the expense of Wikipedia's editors as a whole.
 * Some administrators performed a bunch of ill-advised edits, thereby making a mess of things. The correct response, pending a long-term solution, is to clean up the mess (by either re-enabling the feature or removing its vestiges), not to draw an arbitrary line in the sand.  —David Levy 21:38, 25 May 2012 (UTC)
 * Our "savvy" editors (a small minority) can figure out how to tweak their CSS. This includes those with the feature enabled (a much smaller minority).
 * Everyone else has a broken button.
 * Agreed. And I was among those criticising the back-and-forth-and-sideways changes.  But again, it's unreasonable to focus on ourselves at the expense of Wikipedia's editors as a whole.
 * Some administrators performed a bunch of ill-advised edits, thereby making a mess of things. The correct response, pending a long-term solution, is to clean up the mess (by either re-enabling the feature or removing its vestiges), not to draw an arbitrary line in the sand.  —David Levy 21:38, 25 May 2012 (UTC)
 * Some administrators performed a bunch of ill-advised edits, thereby making a mess of things. The correct response, pending a long-term solution, is to clean up the mess (by either re-enabling the feature or removing its vestiges), not to draw an arbitrary line in the sand.  —David Levy 21:38, 25 May 2012 (UTC)

Idea
Is it feasible to insert a simple notation that the button is intended for use in conjunction with a feature currently disabled by default (accompanied by a link to instructions for enabling it)? While inelegant, that's vastly preferable to displaying a broken button without explanation. My primary objective is to eliminate the likelihood of confusion, one way or another. —David Levy 22:06, 25 May 2012 (UTC)


 * Since virtually everyone who has expressed a preference in the survey has said they want an on-off toggle of some kind, I'm hoping a better coder than I will build something to spoof an off switch (since the actual feature isn't togglable). If they do, they can take the button away at the same time if it's off, and leave it on if it's on. That's why we can't just "turn it on", because most editors seem to only want it turned on if it comes with an off switch. --Elen of the Roads (talk) 23:39, 25 May 2012 (UTC)


 * That would, indeed, be a good solution.
 * In the meantime, can we at least explain what the button is and why it's seemingly nonfunctional? —David Levy 23:44, 25 May 2012 (UTC)

Challenge accepted!
Remove any overrides you may have to restore the indicators (e.g. if you added green stars, remove the css for that). Then add this to your common.js: Then look near where the "Mark all pages visited" button was, and let me know what you think. Tested in Firefox and Chromium on Monobook and Vector, both with and without the "enhanced recent changes" option. Anomie⚔ 02:18, 26 May 2012 (UTC)


 * Excellent work! My only concern is that there are delays.  To my understanding, the initial delay (as the page is  loading) is unavoidable, but I'm also experiencing a significant delay between clicking the arrow and seeing the drop-down list appear (during which a white rectangle appears in its place).  This occurs consistently (no matter how many times I've clicked), but only in Chrome (not in Firefox, Opera or Internet Explorer).  —David Levy 03:07, 26 May 2012 (UTC)
 * Does Chrome do the same with the namespace dropdown? Anomie⚔ 03:09, 26 May 2012 (UTC)
 * Sure enough, it does. I normally use Firefox, so I'd never noticed.  —David Levy 03:13, 26 May 2012 (UTC)
 * Sounds like a browser issue then. One more good test would be to remove the script and see if it still does it. Works fine for me in Chromium, for what that's worth. Anomie⚔ 03:15, 26 May 2012 (UTC)
 * With the script removed, it still occurs with the namespace drop-down. Indeed, it must be an issue on my end.  —David Levy 03:19, 26 May 2012 (UTC)

Technical question, regarding the little arrow thingee (technical term)
Yesterday (I think), I noticed that I no longer have the small triangles that allow you to collapse and expand articles with multiple new edits (in ie9) in your watchlist. I have flushed my cache and rebooted to see if that was an issue, no change. It seems fine in Firefox still. Is this something that's been done by someone around here somewhere? Is it fixable? -- <b style="white-space:nowrap;text-shadow:#000 0em 0em 0.4em,#D00 -0.2em -0.2em 0.4em,#D00 0.2em 0.2em 0.4em;color:#ACF"> Despayre </b> tête-à-tête 23:11, 29 May 2012 (UTC)

Column-count usage across Wikipedia
The use of column-count css3 property causes [issues on the mobile version of the page] Please introduce the following styles so that classes can be used instead on these elements where needed so that these can be optimised for mobile:

— Preceding unsigned comment added by Jdlrobson (talk • contribs)
 * Didn't we use to advice against using a column count > 2 to begin with ? Column width should almost ALWAYS be used instead of or at least in combination with column-count in cases of more than 2 columns. Also what is the point of the .mobile class here ? I'm not really sure I understand its purpose. Perhaps some example uses might be a good idea ? —Th e DJ (talk • contribs) 20:39, 5 June 2012 (UTC)
 * Use of column-width might also be suitable for these definition. The mobile class simply targets the mobile specific site (which adds a mobile class to the body tag for browsers that do not support media queries). Apologies I omitted a space which added to that confusion... body.mobile might make more sense Jdlrobson (talk)
 * Column count of 3 or 4 or a column width of 30 em is well-used with ; see NBR 224 and 420 Classes. Reflist supports both  and   in the manner described by using column-count and column-width. The example image does not show the mobile browser and version, nor the specific article, but it does appear to be non-English. Other language Wikipedias may implement columns in a different manner. ---—  Gadget850 (Ed)  talk 09:51, 6 June 2012 (UTC)

Treeview
Hello, I would like to implement an addition to the common.css in order to enable "tree" style lists. It is used on other language versions of wikipedia:

Thanks --UnQuébécois (talk) 21:21, 14 June 2012 (UTC)
 * Red information icon with gradient background.svg Not done for now: please provide links to some example pages on these other language versions of wikipedia, so that we can see what the desired effect is. -- Red rose64 (talk) 15:47, 15 June 2012 (UTC)
 * No problem! The one I know for sure is French Wikipedia Line to British Throne, the "crowns" are not part of the templates, just the tree branches.--UnQuébécois (talk) 02:30, 16 June 2012 (UTC)
 * OK, so the tree is constructed as a regular bulleted list (with multiple depths as required), the difference in the wikicode being that it is topped with fr:Modèle:Arbre début (which is essentially a ) and tailed with fr:Modèle:Arbre fin (which is essentially a ). It actually looks quite good, and in visual terms is certainly easier to follow than our own Line of succession to the British throne. -- Red rose64 (talk) 13:24, 16 June 2012 (UTC)
 * It's not perfect for a non-visual user agent, of course, but it would be a big improvement on the markup used at Line of succession to the British throne, which is a mixture of pad in pixels and ':' indentation. Semantically, nested lists would render much better on any user agent (or for a re-user), so it would be worth implementing this if only to avoid the sort of kludges we currently use. Note that there's another bit of markup in the French template version,, which is applied to the last item in each sublist (changes the background image to one that does not continue downward). --RexxS (talk) 14:54, 16 June 2012 (UTC)
 * fr:Modèle:Arbre/Branche finale is essentially . I guess we would also need to add fr:Modèle:Arbre/Embranchement and fr:Modèle:Arbre/Embranchement final, to complete the set. Of course, all these would need English names. -- Red rose64 (talk) 15:46, 16 June 2012 (UTC)

This is not really the place to discuss how we want Line of succession to the British throne to look, but to discuss adding the requested script to the css page to implement this type of list, but yes that is where all this started. I have already created the templates needed. I see this tree list being used in many other articles. ,, , and. I will work on the documentation (Translating and/or creating new) once this gets moving.--UnQuébécois (talk) 19:36, 16 June 2012 (UTC)
 * On the contrary, this is exactly the place to examine how the proposed classes would look. CSS style definitions are not added to Common.css on demand, but through debate about their utility, and it is naturally expected that they would be used in many other articles. I'm all in favour of adding these classes, but we should allow consensus to develop, particularly as regulars like Edokter will often spot potential problems at this stage. --RexxS (talk) 20:11, 16 June 2012 (UTC)
 * Too bad we have to support IE<=8, or we could do away with the need for a "TreeList/Branch End" template by using the  pseudoclass. Or I suppose we could do away with it by running something like this from Common.js:


 * and include appropriate selectors targeting both the pseudoclass and the IE class. Anomie⚔ 22:02, 16 June 2012 (UTC)
 * If there is a better way to implement this, I am open to suggestions, for the time being however, it does work, as demonstrated on at least the french version of wikipedia. --UnQuébécois (talk) 20:00, 21 June 2012 (UTC)
 * How much longer do we support IE<8? These folks have the right idea: http://www.bbc.com/news/technology-18440979 --RexxS (talk) 01:23, 22 June 2012 (UTC)
 * The general consensus is "until it gets to less than 1% of traffic, and even then don't go out of your way to break it", last I heard. Recent stats are here. Anomie⚔ 10:42, 22 June 2012 (UTC)

. I will look into importing those templates from fr. &mdash; Martin (MSGJ · talk) 13:49, 22 June 2012 (UTC)
 * Thank you. What templates are you looking to import? --UnQuébécois (talk) 14:51, 22 June 2012 (UTC)
 * Done - please see Template:Tree list &mdash; Martin (MSGJ · talk) 14:54, 22 June 2012 (UTC)

Multiple issues with articles
We are discussing on Template talk:Multiple issues a better way to deal with multiple issues with articles, by having ambox collapse automatically to a more compact form when placed in a wrapper like article issues. If this goes ahead it will involve adding some amount of code, written by User:Anomie, to this page so I am mentioning this here. If anyone is inclined to comment, perhaps they could do so over there. Thanks &mdash; Martin (MSGJ · talk) 22:01, 14 June 2012 (UTC)
 * Now added. &mdash; Martin (MSGJ · talk) 11:55, 26 June 2012 (UTC)

Make selecting coordinate text easier
editprotected

The coordinate display at the top the of the page is uncopy/pasteable as there no click area to start selecting without activating the link. The fix is to simply transfer  value to   as  already. This works for the following skins: These skins will need another approach: Now the default skin, Vector, uses JavaScript adjusted padding between 16px to 24px. If we negative right alignments) are used (, it risks showing horizontal scroll bars. It may be worth the risk as ~15% of clicks on GeoHack are of people selecting the plain text coordinates. — Dispenser 21:22, 25 July 2012 (UTC)
 * MediaWiki:Chick.css [Done]
 * MediaWiki:Monobook.css [Done]
 * MediaWiki:Simple.css [Needs CSS]
 * MediaWiki:Modern.css [Done]
 * MediaWiki:Standard.css (Classic) -- Non-sense CSS: float
 * MediaWiki:Cologneblue.css -- Non-sense CSS: float
 * MediaWiki:Nostalgia.css -- Not displayed, not good
 * Not entirely true: the technique that I normally use is to click somewhere in the blank area to the right of the longitude, and drag left to just before the first digit of the latitude. Then go for . -- Red rose64 (talk) 21:49, 25 July 2012 (UTC)
 * Firefox use to not handle  correctly and WikiMiniAtlas use to included alt text that copy before I got Dschwen to fix it.  More importantly, Internet Explorer's glitchy selection behavior refuses to select the W, but works right to left.  — Dispenser 22:12, 25 July 2012 (UTC)
 * Be careful with that, there might be some topicon logic and edit section 0 scripts that depend on a certain behavior in terms of dynamic positioning. —Th e DJ (talk • contribs) 08:50, 26 July 2012 (UTC)
 * I've enabled an edit protected request to do the same to Chick, Simple, and Modern that was done on Monobook. If the admin wants, they can also attempt changing Vector. — Dispenser 00:16, 2 August 2012 (UTC)
 * Done for chick and modern. Not done for simple, since i see that as a separate issue. —Th e DJ (talk • contribs) 09:25, 2 August 2012 (UTC)
 * Added coordinates to the simple skin. —Th e DJ (talk • contribs) 09:48, 2 August 2012 (UTC)

Definitions for class="texhtml"
Please, add the line: span.texhtml, span.texhtml-big { font-family: MathJax_Math, serif; } It will improve math rendering for some users, see Wikipedia talk:WikiProject Mathematics for explanations. Incnis Mrsi (talk) 11:25, 27 July 2012 (UTC) 12:56, 27 July 2012 (UTC) P.S. Possibly, font-size should be increased too, we yet cannot decide it. It will become more clear when the change to font-family provided a feedback. Incnis Mrsi (talk) 13:25, 27 July 2012 (UTC)
 * Sorry, not that we want. The diff [] contains the correct proposal. Incnis Mrsi (talk) 22:14, 27 July 2012 (UTC)


 * ❌. The installed base of the MathJax fonts amongst our readers is virtually nil, so it makes no sense to put this in Common.css. That is why the default serif font is used, which is tuned to best match the default sans-serif font. — Edokter  ( talk ) — 18:33, 8 August 2012 (UTC)

Suppressing blank lines in notes at top of articles
Hi, please see the dicussion at:

http://en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&oldid=508714511#Compressing_notes_at_top_of_page — Preceding unsigned comment added by 86.179.6.55 (talk) 03:01, 23 August 2012 (UTC)
 * The hatnotes are essential separate paragraphs. Reducing their space in between may hurt readability. — Edokter  ( talk ) — 07:54, 23 August 2012 (UTC)


 * I tend to disagree. These things can stack up to quite a height, and I think space efficiency is more of a consideration than any readability issues. I can't think of any cases where readability would be impaired to any significant degree. 86.176.213.246 (talk) 13:24, 23 August 2012 (UTC)
 * I'm not going to remove the bottom margin; hatnotes can show up at any place, not just above text, and in such cases will be glued to the element beneath it. That's why the margin was added in the first place. — Edokter  ( talk ) — 16:08, 23 August 2012 (UTC)
 * There needs to be a margin between these notes and the main text or material below or above them. What I am talking about is a way of suppressing the space between the notes themselves. At the moment, the only way to do this seems to be to dispense with the templates altogether. It would be nice, for example, if putting the templates one after the other on the same line achieved that effect, but it seems to make no difference. 86.176.213.246 (talk) 17:04, 23 August 2012 (UTC)
 * That is because each hatnote is a paragraph (using a div element). There can be no distinguishing what's below the hatnote. — Edokter  ( talk ) — 19:57, 23 August 2012 (UTC)
 * Right, I see that now. I just remembered an article that I remembered seeing in a particularly problematic state, Normandy_landings, which I see someone has now doctored so that all the notes are in one paragraph under a "hatnote" template. I guess that is the way to go when the bumf at the top starts taking up too much space... 86.176.213.246 (talk) 20:11, 23 August 2012 (UTC)

Lists and left floating images
The bullets of lists that are to the right of left flowing images are problematic. I was thinking that perhaps we could introduce something like we did with hlist. I'm calling it .listfloatfix for now. If you wrap the list in a div with this class, then you should have less trouble. There is one drawback, and that is that if the list is longer than the image, it won't flow around it, but remain indented. See also 11782. —Th e DJ (talk • contribs) 13:01, 26 August 2012 (UTC)

Example content:
The following cultivars have gained the Royal Horticultural Society's Award of Garden Merit for growing in UK gardens:
 * Phormium colensoi subsp. hookeri 'Cream Delight' The text-indent hack is to work around the problem where otherwise when using list-style-position-inside, would lead to the 2nd line not being indented as most would expect it to be. That creates lists that are much less readable in my opinion, and this CSS styling should correct for that.
 * Phormium colensoi subsp. hookeri 'Tricolor'
 * Phormium 'Duet'
 * Phormium 'Sundowner'
 * Phormium tenax 'AGM'
 * Phormium tenax Purpureum group
 * Phormium tenax 'Variegatum'
 * Phormium 'Yellow Wave'

Example content with float fix class
The following cultivars have gained the Royal Horticultural Society's Award of Garden Merit for growing in UK gardens:
 * Phormium colensoi subsp. hookeri 'Cream Delight' The text-indent hack is to work around the problem where otherwise when using list-style-position-inside, would lead to the 2nd line not being indented as most would expect it to be. That creates lists that are much less readable in my opinion, and this CSS styling should correct for that.
 * Phormium colensoi subsp. hookeri 'Tricolor'
 * Phormium 'Duet'
 * Phormium 'Sundowner'
 * Phormium tenax 'AGM'
 * Phormium tenax Purpureum group
 * Phormium tenax 'Variegatum'
 * Phormium 'Yellow Wave'

Lazy example with inline styles
The following cultivars have gained the Royal Horticultural Society's Award of Garden Merit for growing in UK gardens: <ul style="overflow: hidden; list-style-position: inside; padding-left: 1em;"> <li style="padding-left: 1.0em; text-indent: -1.0em;">Phormium colensoi subsp. hookeri 'Cream Delight' The text-indent hack is to work around the problem where otherwise when using list-style-position-inside, would lead to the 2nd line not being indented as most would expect it to be. That creates lists that are much less readable in my opinion, and this CSS styling should correct for that.</li> <li style="padding-left: 1.0em; text-indent: -1.0em;">Phormium colensoi subsp. hookeri 'Tricolor' </li> <li style="padding-left: 1.0em; text-indent: -1.0em;">Phormium 'Duet' </li> <li style="padding-left: 1.0em; text-indent: -1.0em;">Phormium 'Sundowner' </li> <li style="padding-left: 1.0em; text-indent: -1.0em;">Phormium tenax 'AGM' </li> <li style="padding-left: 1.0em; text-indent: -1.0em;">Phormium tenax Purpureum group </li> <li style="padding-left: 1.0em; text-indent: -1.0em;">Phormium tenax 'Variegatum' </li> <li style="padding-left: 1.0em; text-indent: -1.0em;">Phormium 'Yellow Wave' </li> </ul>

Lists and left floating images (discussion)
Needs some tweaking, because ol and ul behave differently (the space for bullets in ul need to be accounted for. Also no padding required for each li, and text-indent is also unnecessary). Numbered lists are a different beast, as the items will be aligned as if the numbers are part of the list item. — Edokter  ( talk ) — 13:54, 26 August 2012 (UTC)
 * I think you missed my comment in the first list item regarding text-indent :D —Th e DJ (talk • contribs) 14:05, 26 August 2012 (UTC)
 * I missed that... That complicates matters a bit, especially for nested items. — Edokter  ( talk ) — 14:31, 26 August 2012 (UTC)
 * Another option might be


 * In a quick test using inline styles, it seems to work in Firefox 14.0.1, Chromium 21.0.1180.75, and IE8. Anomie⚔ 18:31, 26 August 2012 (UTC)

I'm sure you two already know this, but for anyone else following along: In a normal list, the blocks are laid out inside of the  block, with the bullets off the left edge of the first line inside the  block; the  is laid out with an extra margin outside of its content box so there is room for the bullets to be displayed where they're supposed to be. When a left-floated image is involved, neither the nor the  blocks are affected (they extend "under" the image) but the line boxes are shortened to not overlap. The problem with this is that the bullets wind up in the wrong position: either they're left of the edge of the first line box (missing the extra margin they need, because that margin is far to the left under the image) or they're left of the edge of the block (underneath the image).

We can keep the block from extending under the float by causing it to create a new "block formatting context", which in practice means we apply   to it and which has the side effect that the bottom of the list doesn't wrap around the image if the list is longer than the image. But this hides the bullets, because they overflow. TheDJ's proposal moves the bullets to be elements in the text flow inside of the, and then plays with the first-line indentation versus the padding to make it look somewhat like the normal display (but this seems like it will have trouble with numbered lists). My proposal moves the extra "margin" from the outside of the block's content area to the inside, but otherwise keeps the normal positioning of the bullet off the left of the first line of the  block. A third proposal would be to move the  to the  (keeping those from extending under the image) and otherwise use TheDJ's proposal.

Or people could just stop using left-floated images next to lists. Anomie⚔ 18:31, 26 August 2012 (UTC)


 * Very elegant and simple sulotion. I tested it and all lists behave as expected, even when indented. You can even remove the ">" selector and make IE6/7 happy too. In fact, the lists still behave without a floating element, so why not make it standard behaviour? — Edokter  ( talk ) — 20:38, 26 August 2012 (UTC)
 * And it wouldn't hurt .hlist either, as it already resets it's margins to zero. — Edokter  ( talk ) — 20:46, 26 August 2012 (UTC)
 * Elegant indeed. I'm not sure if i'm pro default however. Seems sort of dangerous to change the flow behavior of such a crucial element everywhere... —Th e DJ (talk • contribs) 20:50, 26 August 2012 (UTC)
 * If you're referring to the list not flowing around the image, I think that's kind of a bonus; lists should behave as a block IMO. Besides, how many list are there floating around a left floating element? — Edokter  ( talk ) — 21:09, 26 August 2012 (UTC)
 * Note that the  trick also prevents flowing around right-floated images ( [//en.wikipedia.org/w/index.php?title=User:Anomie/Sandbox&oldid=509314227 example] ), and infoboxes and such too. I see no good reason to disable that likely-much-more-common case. And then there's the possibility of someone doing something unusual and the   actually manages to hide something. Anomie⚔ 21:29, 26 August 2012 (UTC)
 * OK, that could be a problem. Though I really would like to avoid using extra classes and/or templates and make it plug-and-play instead. — Edokter  ( talk ) — 21:50, 26 August 2012 (UTC)


 * OK, I added the  class, and created flowlist and endflowlist, which can be used as a pair, or just use flowlist and pass the list as . —  Edokter  ( talk ) — 22:13, 26 August 2012 (UTC)

Syntax fix
Hi,

[ This change] is syntactically invalid and breaks tools like Recess and W3C CSS validator. Please undo it.

Regards, Od1n (talk) 20:27, 3 September 2012 (UTC)
 * I don't see it. The shorthand for the border property is "width style color", with any of them missing allowed. Solid is a valid style, and transparent a valid color. So... —Th e DJ (talk • contribs) 21:04, 3 September 2012 (UTC)
 * It is the first parameter that is omitted. You can omit parameters, but only the last ones; you cannot leave "gaps". Browsers deal with it, but that's completely invalid CSS and it breaks the analyzers I mentioned above. Od1n (talk) 21:12, 3 September 2012 (UTC)
 * My mistake, Recess fails on the French Common.css and I was sure the error was due to the above code, but it looks like the bug is somewhere else. Od1n (talk) 21:55, 3 September 2012 (UTC)
 * Okay, was due to a bug in Recess. I updated my installation, now it chokes on other things. I believed this tool was quite mature, but according to many statements, it seems not to be the case yet. Od1n (talk) 22:34, 3 September 2012 (UTC)
 * It is permitted to omit the value representing border-width from the  property, and has been permitted since CSS1 - indeed the examples provided by W3C for CSS1, for CSS2 and CSS3 do exactly that. Note that the syntax is shown as
 * Value: &lt;border-width&gt; || &lt;border-style&gt; || &lt;color&gt;
 * or something very similar. The double bar in the syntax indicates that there are two or more options, which may occur in any order. Thus, not only are  and   both legal, they may also be written   and   -- Red rose64 (talk) 11:36, 4 September 2012 (UTC)
 * Yep. These rules are at the end of the French Common.css, and Recess threw a rather disturbing error. I discover thereafter it was a bug in Recess (see my link above). Sorry for the inconvenience. At least, I had checked the W3C doc too and learned a new thing on CSS ;-) Od1n (talk) 17:19, 4 September 2012 (UTC)

hlist class and infobox wrapping
There are already some css entries to stop wrapping of indivdual list items in navboxes when they use the hlist class. Just thinking it would be good to include the same for infoboxes as well.

And reasons not to? -- WOSlinker (talk) 22:10, 7 August 2012 (UTC)


 * Is there any particular reasons to restrict these specifically to navboxes and infoboxes? Why not just have ? 「 ディノ 奴  千？！ 」? · ☎ Dinoguy1000 22:25, 7 August 2012 (UTC)
 * seems reasonable, unless there is a specific reason for restricting this to boxes. we had similar issues in the previous thread. Frietjes (talk) 22:29, 7 August 2012 (UTC)
 * on a semi-related note, see this edit. I had to add the "nowraplinks" to fix the issue with the links wrapping (e.g., the modern pentathlon link), but otherwise the hlist works great here. Frietjes (talk) 22:37, 7 August 2012 (UTC)


 * hlist was desinged for navboxes, and I don't see it being particularly usefull in any other context; infoboxes don't have a lot of room for horizontal lists. Any examples where this is demonstrating it's usefulness in infoboxes? — Edokter  ( talk ) — 18:37, 8 August 2012 (UTC)
 * see what links to Template:Infobox music genre. almost all of the transclusions are using horizontal lists with nowrap begin/nowrap end and ·wrap (for example Blues). Frietjes (talk) 19:04, 8 August 2012 (UTC)
 * Horizontal lists were never intended to be used only in Navboxes; their use in infoboxes is widespread, and they're also used in sideboxes, and in article prose. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 20:18, 8 August 2012 (UTC)
 * Fair enough... Just went through any potential misfires due to specificality changes, but can't find any off the bat. I will make the nowrap universal, but be on the lookout for any mishaps in other templates. — Edokter  ( talk ) — 20:46, 8 August 2012 (UTC)
 * We did in fact discuss using hlist inside infoboxes at Template talk:Infobox London station but never implemented it, don't remember why not. -- Red rose64 (talk) 13:17, 9 August 2012 (UTC)
 * I've given that conversation a nudge. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 16:51, 9 August 2012 (UTC)

Unexpected behavior
The definition of the hlist class was recently [//pt.wikipedia.org/w/index.php?diff=prev&oldid=31781875 copied to Portuguese Wikipedia] but when I [//pt.wikipedia.org/w/index.php?title=Especial:Contribuições/Helder.wiki&offset=20120815225000&limit=3&target=Helder.wiki&uselang=en changed] one of our templates the  made the table cells to be wider than the width of the browser window, as if the property was set to the   element instead of each of the  s. Does anyone knows how to fix that? Helder 00:33, 16 August 2012 (UTC)
 * IE version below 8.0 exhibits this behaviour. Also, did you copy the helper script from Common.js? — Edokter  ( talk ) — 19:09, 16 August 2012 (UTC)
 * Chrome, and Firefox are exhibiting this problem right now. Chico Venancio (talk) 19:53, 16 August 2012 (UTC)
 * I see the problem on Chrome 21.0.1180.79, Iceweasel 3.5.16 and Epiphany 2.30.6.
 * I don't know if that helps, but the problem is only visible on [//pt.wikipedia.org/wiki/Special:RecentChanges?uselang=en Special:RecentChanges] where the pt:Template:MRDebates is transcluded. On the template page itself the problem doesn't happen. Helder 23:46, 16 August 2012 (UTC)
 * I see pt.wiki's Common.css has ben updated, but it is missing the helper script in Common.js. This is needed for IE6/7/8. — Edokter  ( talk ) — 18:58, 2 September 2012 (UTC)
 * It is on [//pt.wikipedia.org/w/index.php?title=MediaWiki:Common.js/IEFixes.js&diff=32081322&oldid=28542449 MediaWiki:Common.js/IEFixes.js]. Helder 21:48, 4 September 2012 (UTC)
 * I see. The script has been updated btw. — Edokter  ( talk ) — 16:18, 5 September 2012 (UTC)

Nowrap doesn't really work well for long and narrow boxes. How to use hlist with wrapping turned off (like it was before)? GregorB (talk) 21:28, 16 August 2012 (UTC)

I've created a simple test case on test.wikipedia.org. To see the problem, first [//test.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets enable the <gadget-hlist-test>], so that [//test.wikipedia.org/wiki/Special:PrefixIndex/MediaWiki:Gadget-hlist-test the CSS and JS] related to the hlist class will be available. Then compare the following pages: Using (at least) Chrome 21.0.1180.79 or Firefox 14.0.1, the items in the table appear all in one line in the third case, but in the first two cases it is normal, and only one item is shown on each line.
 * 1) [//test.wikipedia.org/wiki/Hlist_test Hlist test] (ok)
 * 2) [//test.wikipedia.org/wiki/MediaWiki:Recentchangestext MediaWiki:Recentchangestext] (ok)
 * 3) [//test.wikipedia.org/wiki/Special:RecentChanges Special:RecentChanges] (wrong!)

For some reason, MediaWiki [//test.wikipedia.org/w/index.php?diff=prev&oldid=140930&diffonly=1 mess up the HTML code] when the MediaWiki:Recentchangestext page is added to the top of the Special:RecentChanges, and this breaks the formatting. Helder 15:25, 18 August 2012 (UTC)


 * Confirmed. In fact, the cause that triggers the issue is the list item tags separating the list items  not having a linebreak in between (instead outputting ). This is a parser issue, and even invalid html. —  Edokter  ( talk ) — 15:59, 18 August 2012 (UTC)
 * Having no linebreak between is perfectly valid HTML. HTML doesn't require linebreaks anywhere, and (except within the <pre ></pre> element) treats all linebreaks outside of attribute values as if they were simple spaces  ; they fall within the general category "whitespace". The <ul ></ul> element may contain only <li ></li> elements; whitespace between the <li ></li> elements is optional, not mandatory. -- Red rose64 (talk) 17:40, 18 August 2012 (UTC)
 * It's not how I remembered, however, after some research I can explain the behaviour... The nowrap applies to the entire element, including the tags. Without a space or linebreak between the list items, the browsers regards all conjoind <li ></li> tags as one word, hence it won't wrap in between. I don't know how to target only the textnode inside the list item in CSS; if someone can, I'd love to hear it. Until then, I think having to parser not strip the linebreaks in Special: pages is the most prudent way to go. — Edokter  ( talk ) — 20:21, 18 August 2012 (UTC)
 * Reported on bug 39617. Helder 13:46, 24 August 2012 (UTC)
 * It's not exactly "including the tags", the tags themselves when styled  have no independent existence. It's just that the whitespace between the list items is not inside any of the list items and so isn't affected by the nowrap on the list items. Also, it's not that the parser is stripping linebreaks between the  and the following item's, it's that the wikitext list processing never generates linebreaks there in the first place (see here ); actually, Tidy is inserting these linebreaks when it processes normal pages.
 * But there may be a workaround. Based on a quick test in Firefox, it seems might be possible to force a wrapping point even when the source has no linebreak using something like this:


 * (U+200B is the zero-width space; a plain space might work too). Not tested in other browsers. Anomie⚔ 03:59, 2 September 2012 (UTC)


 * After some tests on testwiki, I implemented a fix using  (linefeed). This also fixed the IE6/7 problem nowrapping the entire list. Still, if you encounter a misbehaving hlist in IE6/7, please let me know. —  Edokter  ( talk ) — 12:58, 2 September 2012 (UTC)
 * Ugh... This solution breaks  formatting! It depends on the entire list item to be no-wrap. I can't find a way around it. Either Mediawiki should let Tidy do Special: pages, or hlist should be banned from Special: pages. —  Edokter  ( talk ) — 21:45, 3 September 2012 (UTC)
 * Did you try something like


 * Otherwise, it looks like you worked around it for hnum at the expense of hnum not working in Special pages (unless you use HTML instead of wikitext list formatting).
 * Too bad  or   (ref) are too new to be well supported yet. Anomie⚔ 01:33, 4 September 2012 (UTC)
 * No luck there... .hnum is still broken because of unwanted spaces in Special: pages, of which I don't know where they come from, but are removed by Tidy otherwise. Or better yet, MediaWiki should output sanely formatted lists to begin with. — Edokter  ( talk ) — 16:15, 4 September 2012 (UTC)
 * Is there a test case somewhere I can look at? Anomie⚔ 19:18, 4 September 2012 (UTC)
 * See the links to test.wiki that Helder gave above. — Edokter  ( talk ) — 20:12, 4 September 2012 (UTC)
 * Oh, the "unwanted spaces" there being that it has e.g. "2 seven )" rather than "2 seven)" (and with the \a0, "2 seven )")? Hmm... About all you can do about that is use HTML list markup instead of wikitext lists in the system messages. MediaWiki outputs relatively "dirty" markup for wikitext lists, and .hlist/.hnum relies on clean markup. Anomie⚔ 20:57, 4 September 2012 (UTC)
 * That's why I reopened the bug, requesting some html to be sanitized (which should be very easy, and I would submit a change if I had setup Git on my PC). — Edokter  ( talk ) — 21:29, 4 September 2012 (UTC)
 * Until this is fixed in the parser, I think we should declare hlist 'unsafe' for use in pages where Tidy is not invoked. I really don't like this hack, and I will be removing it here (they are not in use in Special pages anyway). I'll also provide a note in the source. — Edokter  ( talk ) — 16:21, 5 September 2012 (UTC)
 * I think you're overreacting a bit in declaring it "unsafe" without any mention of the simple workaround: use a tidily-formatted HTML list. About the only place where it would really be unsafe would be if MediaWiki is generating the list itself (as opposed to the example used above, where it's a user-entered list in a MediaWiki-namespace message) and doesn't include the necessary whitespace. Anomie⚔ 19:30, 5 September 2012 (UTC)
 * True. I'll add that note. — Edokter  ( talk ) — 20:32, 5 September 2012 (UTC)
 * Well, the problem also happens on enwiki's [//en.wikipedia.org/wiki/Special:ExpandTemplates?input=%7B%7BNavbox%0A%7Cname++++%3D+Example%0A%7Ctitle+++%3D+Example%0A%7Cbodyclass+%3D+hlist%0A%7Cgroup1++%3D+First%0A%7Clist1+++%3D%0A*+A%0A**+A1%0A**+A2%0A*+B%0A%7Cgroup2++%3D+Second%0A%7Clist2+++%3D%0A*+A%0A**+A1%0A**+A2%0A*+B%0A%7D%7D&contexttitle=&removecomments=true Special:ExpandTemplates], so the special page may not be so useful when debugging templates with horizontal (sub)lists. Helder 00:40, 16 September 2012 (UTC)
 * Either the parser fails to include the second, or Tidy strips it. Either way, this is not strictly related to hlist, as the error also happens without the hlist class. — Edokter  ( talk ) — 08:46, 16 September 2012 (UTC)
 * The real problem there is that the template winds up including the markup closing the table cell and such inside the last list element. In this case Tidy seems to manage to fix it correctly, but Tidy isn't run on the Special:ExpandTemplates output and the browser may not handle the tag soup in the way we want. Anomie⚔ 14:13, 16 September 2012 (UTC)

For the record, I reported one more parser bug after doing some tests to fix a problem we found while trying to use this with [//pt.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:P%C3%A1gina_de_testes/1&oldid=32234126 nested lists] on ptwiki. Helder 19:40, 15 September 2012 (UTC)
 * That looks nasty, but fortunately that can be worked around by making sure that the cell contents is on separate lines from the HTML elements. Here, navbox ensures that. (This could be a Tidy issue though.) — Edokter  ( talk ) — 20:05, 15 September 2012 (UTC)

Trailing bullets with hlist
I'm sure this has been discussed, but is there no fix for the trailing bullets with hlist on IE8? For example there is a trailing bullet on every line in Template:US 2012 presidential elections series, and there are no closing parenthesis. So, it seems like this is an issue with Win7/IE8 not using the "last-child" part? 198.102.153.1 (talk) 16:15, 19 September 2012 (UTC)
 * If you see trailing bullets in IE, it means you probably have javascript disabled. Javascript is required for hlist to work properly in IE 8, as it has no concept of CSS'  selector (but oddly it does understand  ). —  Edokter  ( talk ) — 20:22, 19 September 2012 (UTC)

Class to override default valign
The switch to HTML5 has raised various problems with alignment inheritance, but there is a longstanding problem with aligning all the cells in a table.

At present, even with the  class, table cells use default vertical alignment. Since wikitext prohibits adding internal style sheets, and table cells do not inherit the vertical alignment of the table element, there is no way to change the vertical alignment for all cells in a table without adding a separate  attribute to each row.

A common desirable style is for all cells to be top-aligned (as is the default in typical spreadsheets, word-processing and DTP programs).

MediaWiki:Common.css currently applies this formatting only for. But it would be a useful option for non-infobox tables too.

I assume it would be too radical to change the default  styling. But some wikis apparently define an additional  class to allow the usual alignment to be overridden.

Presumably the CSS would be something like: or

Could something like this be implemented on enwiki?

— Richardguk (talk) 20:22, 21 September 2012 (UTC)


 * Comments, anyone? — Richardguk (talk) 18:32, 26 September 2012 (UTC)

Beatles RfC
You are invited to participate in an RfC at Wikipedia talk:Requests for mediation/The Beatles on the issue of capitalising the definite article when mentioning that band's name in running prose. This long-standing dispute is the subject of an open mediation case and we are requesting your help with determining the current community consensus. Thank you for your time. For the mediators. ~ GabeMc  (talk 23:35, 22 September 2012 (UTC)

@embed doesn't work
Per bug 40832, there is no point in [//en.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=459848693 using  here], because images loaded through an URL are not supported. Since the comment is inoffensive, maybe it is better to just add a link to the bug instead of removing it? Helder 12:44, 8 October 2012 (UTC)
 * Removed. — Edokter  ( talk ) — 16:35, 13 October 2012 (UTC)

Main Page hiding its h1 outside of ?action=view
Hi.

Currently MediaWiki:Vector.css and MediaWiki:Monobook.css contain:

This hides the page title (h1) while ?title=Main_Page. This snippet applies to (the implicit) ?action=view, but it also applies to ?action=history, ?action=info, etc. I think it would be nice to limit this display:none; to only ?action=view. The header is removed for aesthetic reasons at ?action=view, but on the other actions, it's expected and its absence is a bit bothersome.

Any idea how difficult or easy this would be to implement this idea? Is there a "view" class or something that can be used? Would it require JavaScript? Any help on this would be appreciated. --MZMcBride (talk) 15:28, 13 October 2012 (UTC)


 * That is trivially easy... the element also contains the   class. So all that is needed is to add that class to the selector. —  Edokter  ( talk ) — 15:51, 13 October 2012 (UTC)


 * Oh, wonderful. Thanks for the quick edits. :-) Can we also apply this limitation (action-view) to contentSub and siteSub? I've just noticed that ?action=history&title=Main_Page is missing its "View logs for this page" link, for example, because it sits in contentSub. --MZMcBride (talk) 16:03, 13 October 2012 (UTC)


 * Done. As a side question, do you know if the  is linked (or hidden) from anywhere? Do we need to create a gadget to add/enable this link? —  Edokter  ( talk ) — 16:17, 13 October 2012 (UTC)


 * When I look at <https://en.wikipedia.org/wiki/Main_Page?action=history> now, I can't see "View logs for this page". Your CSS changes look fine, but I think the bodyContent 1.3em hack thing is causing some kind of strange overlap. There's definitely a space above the tagline ("From Wikipedia...") that's being caused by that code.
 * Hmm... I see the link just fine in IE8, Chrome, Firefox and Opera, in both Monobook and Vector skins. Perhaps a caching issue? — Edokter  ( talk ) — 17:11, 13 October 2012 (UTC)
 * Some combination of me using Monobook and having some funky personal CSS. I think MediaWiki:Monobook.css will ultimately need another tweak (my personal CSS issues aside, there's a weird space when logged out), but it's by no means urgent. Thanks again for your work on this. --MZMcBride (talk) 18:10, 13 October 2012 (UTC)
 * #contentSub is inside #bodyContent, so that 1.3em hack can't be responsible for hiding the logs link. But I filtered the hack as well, so the history page should now look as any other. If it is still broken, I suspect your CSS for #lastmod is to blame. — Edokter  ( talk ) — 18:36, 13 October 2012 (UTC)
 * Aye, years and years ago, Firefox had a bug involving %s and the main page. I didn't like seeing "redirected from" text, so I hid contentSub for myself just on the Main Page. That was why "View logs..." wasn't showing for me still. The weird spacing issue is now fixed with your most recent edit to MediaWiki:Monobook.css. Everything looks perfect now. --MZMcBride (talk) 19:32, 13 October 2012 (UTC)
 * Regarding the info action, it'll show up in the toolbox as a "Page information" link on the English Wikipedia on Monday, October 22. You can see how it looks live at <https://translatewiki.net/>. --MZMcBride (talk) 17:02, 13 October 2012 (UTC)
 * Oh well, then I created my gadget for nothing :) — Edokter  ( talk ) — 17:11, 13 October 2012 (UTC)