MediaWiki talk:Common.css/Archive 14

Archive 10

←

Archive 12

Archive 13

Archive 14

Archive 15

Archive 16

→

Archive 19

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 nocontent class, which has the following properties:

.nocontent {
    speak: none;
}

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 said 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 position:absolute; set in the common.css but actually there is no mention of it. I guess it must be inherited? the only two absolute'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 /skins/vector/screen.css (loaded through ResourceLoader). And I have to recomment against fixed 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 . 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>
<html>
<head>
<style type="text/css">
#side-dish
{
	position:fixed;
	background-color:#ddd;
	border:1px solid #888;
	top:8px;
	float:left;
	width:150px;
	height:700px;
	font-size:70%;
	overflow:auto;
}
#main-dish
{
	margin-left:160px;
	border:1px solid #888;
}
p
{
	margin:5px;
}
p:hover
{
	color:#0f0;
	font-weight:bold;
}
</style>
<script type="text/javascript">
var str;
var count=0;
document.write("<div id=\"main-dish\"></div>");
var md=document.getElementById("main-dish");
if(md)
{
	while((++count)<201)
	{
		str="<p>"+count+"</p>";
		md.innerHTML+=str;
	}
}
document.write("<div id=\"side-dish\"></div>");
var sd=document.getElementById("side-dish");
if(sd)
{
	count=0;
	while((++count)<201)
	{
		str="<p>"+count+"</p>";
		sd.innerHTML+=str;
	}
}
</script>
</head>
<body>
</body>
</html>

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. fredgandt 03:39, 25 November 2011 (UTC)

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). — 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. fredgandt 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. —TheDJ (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. fredgandt 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 —TheDJ (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. fredgandt 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 @import url("http://wiki.riteme.site/w/index.php?title=User:Fred_Gandt/common.css&action=raw&ctype=text/css");. Alternatively, you can use importStylesheet("User:Fred Gandt/common.css"); 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.

#mw-panel
{
	position:fixed !important;
	max-height:500px;
	overflow:auto;
}

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. fredgandt 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 */
#userlogin, #userloginForm {
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_track] \\ 3 December, 2011 [20:32]

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_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). fredgandt 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#Patently useless. — 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. —TheDJ (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. —TheDJ (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 —TheDJ (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., {{hat}}) 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 text-align:center;, but a better solution is to have a seperate class for these archive templates. — Edokter (talk) — 22:59, 6 December 2011 (UTC)

(edit conflict) 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:

/* On wide screens, show these as two columns */

.portal-column-left {
  float: left;
  width: 50%;
}
.portal-column-right {
  float: right;
  width: 49%;
}

.portal-column-left-wide {
  float: left;
  width: 60%;
}
.portal-column-right-narrow {
  float: right;
  width: 39%;
}


@media only screen and (max-width: 800px) {
  /* Decouple the columns on narrow screens */
  .portal-column-left,
  .portal-column-right,
  .portal-column-left-wide,
  .portal-column-right-narrow {
    float: inherit;
    width: inherit;
  }
}

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 <gallery> 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 [1]) 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)

.portal-column-full {
  float: left;
  width: 100%;
}

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 width: 100% important; float: inherit !important; 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 listclass=hlist and bodyclass=hlist.

.navbox .hlist td dl,
.navbox .hlist td ol,
.navbox .hlist td ul {
    padding: 0.125em 0;       /* Adjust hlist padding in navboxes */
}

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 here 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#Resize_request 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://wiki.riteme.site/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: [2], 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

/* Generate interpuncts */
.hlist dt:after {
    content: " :";
}

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 Wikipedia:Village pump (technical) (line four: "See also:..."). -DePiep (talk) 19:37, 16 December 2011 (UTC)

Source lang="lsl2" isn't quite right + encodeURIComponent JS

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.

var foo=encodeURI("blahdiblah");
var bar=encodeURIComponent("blahdiblah");

I'm sure if one function is not correctly styled, there must be others (functions, methods etc.). fredgandt 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. fredgandt 05:42, 18 December 2011 (UTC)

I've reported encodeURIComponent. 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. fredgandt 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 td block, but the list css overrides that in the ul block right inside it, as shown by Chrome:

<tr>
  <td align="center">
    <ul>
      <li>

and

.mw-content-ltr .toc ul, .mw-content-ltr #toc ul, .mw-content-rtl .mw-content-ltr .toc ul, .mw-content-rtl .mw-content-ltr #toc ul {
  text-align: left;
}

--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 <code> is very small, as the second sentence in this example shows:

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. 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 <code></code> text. The font size, weight, and family (exact family member) is also dependent on browser settings (I think I'm right there), so not too much should be done to change it (take away control from the user's browser). fredgandt 23:56, 21 January 2012 (UTC)

"Technically it is the same size" meanwhile in reality, and with (AFAIR) default settings in Chrome or Firefox, the size of the letters is smaller in the second sentence. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 01:02, 22 January 2012 (UTC)

The x-height of monospaced fonts is usually smaller, but the cap height should be the same as that of normal text. With the default font settings in Vector (and Monobook), cap-height should be 13px for both proportional and monospaced fonts; even if you have specified different font sizes for monospace in your browser (which is 16px for propertional and 13px for monospace by default). That is because we made sure that monospace elements have their fonts specified in such a way that, size-wise, they are threated as a proportional font, thus evading the trap of having a too small monospace font due to the smaller browser default. You can see the how taht's done here.

If for some reason the monospace is really too small, it may be some custom CSS that is in the way. — Edokter (talk) — 01:32, 22 January 2012 (UTC)

Is there any way you know of to stretch a font in either direction (x or y) using css? fredgandt 02:13, 22 January 2012 (UTC)

http://www.w3schools.com/cssref/css3_pr_font-stretch.asp may become one way. fredgandt 02:20, 22 January 2012 (UTC)

Pending browser support for CSS3, the only way that I know of is to use the font-family property, if you can find a font which is unusually wide or narrow, and which is widely recognised. By way of demonstration, on my PC (Windows XP) I have Arial Narrow, which compared to normal Arial, looks like this: This is Arial font, and this is Arial Narrow, and back to Arial. Clearly Arial Narrow is not a monospace font, but you get the idea. --Redrose64 (talk) 14:03, 22 January 2012 (UTC)

The problem with monospace fonts are that they lack even the most basic styles, let alone the various weights that acompany some fonts. Courier is the only font that can be asumed to be present on any system which has all basic four style variants (bold and italics). — Edokter (talk) — 14:11, 22 January 2012 (UTC)

Sorry if I have caused a confusion. I wasn't suggesting we squash or stretch the <code> text, just asking a font styling question where the opportunity arose. My idle thought about stretching text is pure curiosity. I can read the <code> text just fine. I have styled <code> text to stand out (a lot!), but even with that styling disabled, it is quite clear for me to read (just not that clear that it is <code>, thus my own styling). fredgandt 14:22, 22 January 2012 (UTC)

pre tags

Does anyone know why we don't use "white-space:pre-wrap" or something similar to prevent text overflowing on the right? I have it in common.css on my MW installation, and I add it manually to any <pre> tags I use here without any ill effects I've noticed. I'm probably missing something obvious, though... Begoon ^talk 08:22, 25 January 2012 (UTC)

The default behaviour for <pre> is to format the text exactly as entered. If text breaks out, then it isn't formatted properly. (But I also have the pre-wrap in my CSS...) — Edokter (talk) — 11:22, 25 January 2012 (UTC)

Yes, you're right, but the problem, as you know, is that people don't format it correctly. Commonly, it's used as a quick way to dump sourcecode etc., just copied/pasted, and so long lines break out all the time, especially if you're viewing on a "smaller" screen like 1024x768. It looks fine to the guy when he pastes it on a bigger screen, so he's happy, and saves his edit. I guess forcing the css on all pre tags is a sledgehammer to crack a nut, but I'd like to think of a way we can avoid source code tumbling off the right when smaller screens are used. Guess I'm trying to avoid the "use a different tag/template" solution, since there is already so much existing content. Begoon ^talk 11:42, 25 January 2012 (UTC)

No, I think EDokter is wrong. An editor cannot format a text correctly for any User Agent (for example browser+screen). I'm still with the original question (-'s essence). -DePiep (talk) 23:35, 26 January 2012 (UTC)

It's just interpretation. I know what he means. If you put 150 character long lines in a pre, you get 150 character long lines, even if that means they overflow. That's how the bare tag is supposed to work - no formatting changes to what you put in it. If we put css in here, then anyone who wanted to use a true, bare pre tag would have to override it inline or locally. It's not an ideal way of doing things.

I just wish I could think of a clever solution that doesn't involve just using another tag/template, because there is still heaps of existing content using pre tags that would not help, and it's not an ideal thing, either, to see that overflow on the right all the time with a smaller screen/window or larger font etc. Begoon ^talk 06:41, 27 January 2012 (UTC)

Styling for dfn tags, redux

Per MediaWiki talk:Common.css/Archive 13#Styling for dfn tags, the following needs to be added, to prevent various browsers (not all – Chrome for one doesn't do it, but the change won't affect Chrome users at all) from auto-italicizing <dfn>...</dfn> instances, which aside from being inconsistent doesn't agree with any use of italics sanctioned by WP:MOS, and directly conflicts with a lot of things. The code:

/* Styling for defining instances of terms. */
dfn {
     font-style: inherit;
}

The dfn 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 <dfn> 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 <dfn> 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 <dfn> 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,[3][4] and they don't even use it in the default all-browsers style sheet that the entire Web's display is essentially based on.[5] 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 [6]. 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 <cite> 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 not 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. — Martin (MSGJ · talk) 13:11, 1 September 2011 (UTC)

So, 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)

 Done [7]. — 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 mw-collapsible (which force us to 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)

 Undone. Navframe is better off being build from scratch anyway. — Edokter (talk) — 19:06, 22 February 2012 (UTC)

Alternative

See MediaWiki talk:Common.js#Do not create NavFrame buttons if the new class "mw-collapsible" is used. 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#Age doesn't show up on mobile wikipedia. 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. —TheDJ (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#Small bug

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#HLIST. --Redrose64 (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:

‮)‬ → ‮)‬

-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 <li> 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 <ul> and <li> to be inline elements, not block elements. Consider the HTML output by MediaWiki for a fairly generic list:

<div class="hlist">
<ul>
<li>foo
<ul>
<li>bar</li>
</ul>
</li>
<li>baz</li>
</ul>
</div>

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 display:inline is given to the <ul> and <li> 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 <li> (the effective HTML with the generated parens is something like <li>foo (<ul> <li>bar</li> </ul>) </li>), 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 .hlist ul ul li:first-child:before and .hlist ul ul li:last-child:after instead (stupid IE<9), then the open/close parens would be after/before the newlines before/after the first/last <li> and everything would render correctly (the effective HTML with the generated parens would be something like <li>foo <ul> (<li>bar</li>) </ul> </li>). Or you could wait for browsers to support the CSS3 word-spacing property and then try to get the word-spacing on the <ul>s (but not the {{li}}s) set to -100%, causing the spaces to have zero width. Or you could wait for browsers to support CSS4 and the text-space-collapse:discard 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)

.hlist ul ul li:first-child:before and .hlist ul ul li:last-child:after 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 <ol>. 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 | 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). --Redrose64 (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. ~ ⇒TomTomN00 @ 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:

.ns-talk #content {background-color: #FFFFC0; }

gives a pale yellow. --Redrose64 (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 <body class="mediawiki ltr sitedir-ltr ns-9 ns-talk page-MediaWiki_talk_Common_css skin-monobook action-view"> <div id="globalWrapper"> <div id="column-content"> <div id="content"> - I picked the innermost id= (content) and the most likely-looking class which would catch talk pages (ns-talk), 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 #ffffff. --Redrose64 (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:

div#content {background-color: #FFFFFF; }

--RexxS (talk) 18:22, 19 March 2012 (UTC)

I agree about the div#content {background-color: #FFFFFF; } 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. --Redrose64 (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:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

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)

{| class="wikitable" style="width:30%; float:right; margin:13px 0px 13px 13px;"
|-
| {{Str left|{{Lorem ipsum}}|123}}
|}

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

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 13px top, 13px right, 13px bottom, and 0px left, just as the left floated table does. There may be another class that can be added to .wikitable to alter the margins of right floating tables. Is that what you're after? fredgandt 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.... —TheDJ (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 Bugzilla: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."[8] 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#MediaWiki 1.19. IE6 is listed as 2.22% use across projects per Wikimedia Analytics - User Agent Breakdown by Browser. — 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. —TheDJ (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. fredgandt 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! fredgandt 12:44, 17 January 2012 (UTC)

Hey, while we're about it, let's drop all IE support, force MS to get in line. --Redrose64 (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#Discharge. 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:

/* Allow parser function error to be shown by user CSS */
span.parserfunctionerror {
    display: none;
}

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 T34626 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 T22050 is resolved. ---— Gadget850 (Ed) ^talk 02:47, 3 May 2012 (UTC)

Changes to the interface messages are  Done. 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 .cite-backlink {display:none;} 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. Steven Walling • 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. Steven Walling • 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. ;) Steven Walling • 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 Wikipedia:Village_pump_(proposals)#Next_steps. 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

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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 ! scope="row" | coding. I've tested this in a table using class="wikitable plainrowheaders" 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 class="wikitable plainrowheaders-right" 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 <TH> (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 ! scope="row" | 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 ! scope="row" style="text-align:right;" | 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 class="wikitable plainrowheaders" 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 class="wikitable plainrowheaders". (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 class="wikitable sortable plainrowheaders" 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 class="wikitable sortable plainrowheaders", 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 class="wikitable sortable plainrowheaders", you're applying three separate classes in turn: first the wikitable class is applied, then sortable, then plainrowheaders. 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 plainrowheaders overrides some or all of sortable. Try exchanging the last two - class="wikitable plainrowheaders sortable" - to see if that helps. --Redrose64 (talk) 21:25, 15 May 2012 (UTC)

Didn't work for either "wikitable plainrowheaders" or "plainrowheaders wikitable" - [9] 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 class="wikitable sortable plainrowheaders" that matters, it's the specificity and the order they're defined in the CSS files or <style> tags. Anomie⚔ 01:24, 16 May 2012 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Centering an hlist in a wikitable

(Original thread: Template talk:Flatlist#Centering) Basically, the question is if we can add some functionality to make it possible to center a flatlist in a wikitable. For example, compare

item1 item2

with

item1 item2

or with

or with

item1 item2

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? .wikitable.hlist td ul already has a higher specificity than .wikitable td ul, and the !important makes it so you can't override it with <ul style="text-align:left"> 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. Happy‑melon 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. Happy‑melon 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)

I'm in violent agreement with everyone that the current setup makes no sense.

And you reverted to it anyway? I'm stunned.

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.

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.

That's just unreasonable, even if it means that we have to live with an illogical interface for a couple of weeks.

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)

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. Happy‑melon 18:40, 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.

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?

I hardly think you'd be able to find many people who have given it anything more than a passing thought.

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).

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.

This isn't the type of situation described at meta: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").

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.

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

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?

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.

Have we ever deliberately retained a broken setup that everyone agreed made no sense?

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. Happy‑melon 22:16, 25 May 2012 (UTC)

Of course it's not perfect. But Wikipedia isn't perfect.

The point isn't that it's imperfect. It's that it's dramatically inferior to an obvious alternative.

Cough RFA. Cough Main Page. Cough ArbCom voting algorithm.

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.

If we don't agree on how best to fix something, it tends to remain broken.

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)

• 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)

these >99.9% claims are bogus. Our readers don't have a watchlist; our editors do.

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.

The button being there causes as much confusion as any big red button: You push it, then try to figure out if anything happened.

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.

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.

I disliked the bolding, but at least it made sense.

It may perhaps confuse those who haven't encountered it yet, but our savvy editors can surely figure it out quickly enough.

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.

As RnB mentioned though, having to update my css every two or three days is far more annoying than a button could ever be.

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)

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:

importScript('User:Anomie/watchlist-change-style-selector.js'); // Linkback: [[User:Anomie/watchlist-change-style-selector.js]]
importStylesheet('User:Anomie/watchlist-change-style-selector.css'); // Linkback: [[User:Anomie/watchlist-change-style-selector.css]]

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? -- Despayre  ^{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:

	.column-count-2 {
		-webkit-column-count:2;
		-moz-column-count:2;
		column-count:2;
	}

	.column-count-3 {
		-webkit-column-count:3;
		-moz-column-count:3;
		column-count:3;
	}

	.column-count-4 {
		-webkit-column-count:4;
		-moz-column-count:4;
		column-count:4;
	}

	.mobile .column-count-2,
	.mobile .column-count-3,
	.mobile .column-count-4 {
		-moz-column-count:auto!important;
		-webkit-column-count:auto!important;
		column-count:auto!important;
		-webkit-column-width:auto!important;
	}

— 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 ? —TheDJ (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 Shortened footnotes; see NBR 224 and 420 Classes. {{Reflist}} supports both column-count and column-width 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:

Extended content

/* TREEVIEW */ .treeview ul { padding: 0; margin: 0; } .treeview li { padding: 0; margin: 0; list-style-type: none; list-style-image: none; zoom: 1; /* BE KIND TO IE6 */; } .treeview li li { background: url("//upload.wikimedia.org/wikipedia/commons/f/f2/Treeview-grey-line.png") no-repeat 0 -2981px; padding-left: 20px; text-indent: 0.3em; } .treeview li li.lastline { background-position: 0 -5971px } .treeview li.emptyline > ul { margin-left: -1px; } .treeview li.emptyline > ul > li:first-child { background-position: 0 9px }

Thanks --UnQuébécois (talk) 21:21, 14 June 2012 (UTC)

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. --Redrose64 (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 {{Arbre début}} (which is essentially a <div class="treeview">) and tailed with {{Arbre fin}} (which is essentially a </div>). It actually looks quite good, and in visual terms is certainly easier to follow than our own Line of succession to the British throne#Line of succession. --Redrose64 (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#Line of succession, 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, {{Arbre/Branche finale}}, 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)

{{Arbre/Branche finale}} is essentially <li class="lastline">. I guess we would also need to add {{Arbre/Embranchement}} (<li class="emptyline">) and {{Arbre/Embranchement final}} (<li class="lastline emptyline">), to complete the set. Of course, all these would need English names. --Redrose64 (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#Line of succession 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. {{TreeList start}}, {{TreeList end}}, {{TreeList/Branch}}, {{TreeList/Branch End}} and {{TreeList/Terminal Branch}}. 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 :last-child pseudoclass. Or I suppose we could do away with it by running something like this from Common.js:

  if($.browser.msie && parseInt($.browser.version, 10) <= 8) {
      $('.treeview li:last-child').addClass('last-child');
  }

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)

 Added. I will look into importing those templates from fr. — 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 — 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 — Martin (MSGJ · talk) 22:01, 14 June 2012 (UTC)

Now added. — 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 right: value to padding-right: as was done for Monobook already. This works for the following skins:

• MediaWiki:Chick.css [Done]
• MediaWiki:Monobook.css [Done]
• MediaWiki:Simple.css [Needs CSS]
• MediaWiki:Modern.css [Done]

These skins will need another approach:

• MediaWiki:Standard.css (Classic) -- Non-sense CSS: float
• MediaWiki:Cologneblue.css -- Non-sense CSS: float
• MediaWiki:Nostalgia.css -- Not displayed, not good

Now the default skin, Vector, uses JavaScript adjusted padding between 16px to 24px. If we negative right alignments) are used (right:-15px;, 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)

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 Ctrl+C. --Redrose64 (talk) 21:49, 25 July 2012 (UTC)

Firefox use to not handle display:none; 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. —TheDJ (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. —TheDJ (talk • contribs) 09:25, 2 August 2012 (UTC)

Added coordinates to the simple skin. —TheDJ (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#texhtml 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 [10] contains the correct proposal. Incnis Mrsi (talk) 22:14, 27 July 2012 (UTC)

 Not done. 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://wiki.riteme.site/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 bugzilla:11782. —TheDJ (talk • contribs) 13:01, 26 August 2012 (UTC)

.listfloatfix ol,
.listfloatfix  ul,
.listfloatfix  dl {
    overflow: hidden;
    list-style-position: inside;
    padding-left: 1em;
}

.listfloatfix  li,
.listfloatfix  dd {
    padding-left: 1.0em;
    text-indent: -1.0em;
}

Example content:

Phormium tenax flowers have the same curvature as the beak of the nectar eating Tui seen in the photograph.

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

Phormium tenax flowers have the same curvature as the beak of the nectar eating Tui seen in the photograph.

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

Phormium tenax flowers have the same curvature as the beak of the nectar eating Tui seen in the photograph.

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'

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 —TheDJ (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

.listfloatfix > ul {
    overflow-x: hidden;
    margin-left: 0em;
    padding-left: 1.6em;
}
.listfloatfix > ol {
    overflow-x: hidden;
    margin-left: 0em;
    padding-left: 3.2em;
}
.listfloatfix > dl {
    overflow-x: hidden;
}

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 <li> blocks are laid out inside of the <ul> block, with the bullets off the left edge of the first line inside the <li> block; the <ul> 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 <ul> nor the <li> 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 <li> block (underneath the image).

We can keep the <ul> block from extending under the float by causing it to create a new "block formatting context", which in practice means we apply overflow:hidden 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 <li>, 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 <ul> 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 <li> block. A third proposal would be to move the overflow:hidden to the <li> (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... —TheDJ (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 overflow:hidden trick also prevents flowing around right-floated images (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 overflow:hidden 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 .flowlist class, and created {{flowlist}} and {{endflowlist}}, which can be used as a pair, or just use {{flowlist}} and pass the list as {{{1}}}. — 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... —TheDJ (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 border: 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: <border-width> || <border-style> || <color>

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 border: solid transparent; and border: solid #000001; both legal, they may also be written border: transparent solid; and border: #000001 solid; --Redrose64 (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.

.infobox .hlist dd,
.infobox .hlist dt,
.infobox .hlist li {
    white-space: nowrap;      /* Nowrap list items in navboxes */
    white-space: normal !ie;  /* IE < 8 no-wraps entire list, so disable it */
}
.infobox .hlist dd dl,
.infobox .hlist dt dl,
.infobox .hlist li ol,
.infobox .hlist li ul {
    white-space: normal;      /* But allow parent list items to be wrapped */
}

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 .hlist dd, etc.? 「ディノ奴千？！」^{? · ☎ 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#Formatting snafu? but never implemented it, don't remember why not. --Redrose64 (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

Tracked in Phabricator
Task T41617

The definition of the hlist class was recently copied to Portuguese Wikipedia but when I changed one of our templates the white-space: nowrap; made the table cells to be wider than the width of the browser window, as if the property was set to the <ul> element instead of each of the <li>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 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 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 enable the <gadget-hlist-test>, so that the CSS and JS related to the hlist class will be available. Then compare the following pages:

1. Hlist test (ok)
2. MediaWiki:Recentchangestext (ok)
3. Special:RecentChanges (wrong!)

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.

For some reason, MediaWiki 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 ...</li>[linebreak]<li>... not having a linebreak in between (instead outputting ...</li><li>...). This is a parser issue, and even invalid html. — Edokter (talk) — 15:59, 18 August 2012 (UTC)

Having no linebreak between </li><li> 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. --Redrose64 (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 display:inline 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 </li> and the following item's <li>, 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:

.hlist dd:before,
.hlist li:before {
    content: "\200b";
    white-space: normal;
}

(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 content: "\a" (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 .hnum 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

.hlist.hnum ol li:before {
    content: "\0a" counter(list-item) "\a0";
}
.hlist.hnum ol ol li:first-child:before {
    content: "\0a(" counter(list-item) "\a0";
}

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 .hlist.hnum ol li::before(2) or .hlist.hnum ol li::before::before (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 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 <ul>, 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 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' :last-child selector (but oddly it does understand :first-child). — 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 wikitable class, table cells use default vertical alignment (vertical-align: center;). 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 style 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 .infobox td, .infobox th. But it would be a useful option for non-infobox tables too.

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

Presumably the CSS would be something like:

.toptextcells td,
.toptextcells th {
    vertical-align: top;
}

or

.wikitable.toptextcells td,
.wikitable.toptextcells th {
    vertical-align: top;
}

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|contribs)} 23:35, 22 September 2012 (UTC)

@embed doesn't work

Per bug 40832, there is no point in using @embed 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:

body.page-Main_Page h1.firstHeading { display:none; }

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 <body> element also contains the action-view 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 ?action=info 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://wiki.riteme.site/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)