MediaWiki talk:Common.css/Archive 12

Archive 5

←

Archive 10

Archive 11

Archive 12

Archive 13

Archive 14

Archive 15

Second font-family "inherit" declaration

font-family /**/: inherit;

is declared after font-family for the Unicode, IPA, etc. classes. The comment explains that the second declarations reset the styles for all browsers except IE6, which chokes on the empty comment tags, but I don't understand. What does this exactly do? --Paul_012 ^(talk) 13:16, 31 January 2010 (UTC)

The function of the declarations are to apply extra CSS styles for IE6 only; for whatever reason we determined that they improve the behaviour of that particular browser. We exploit the fact that IE6 cannot correctly parse declarations with comment tags between the attribute name and the colon: all other browsers apply the new styles, then immediately reset them to the default; IE6 applies the new styles, but never resets them, so uses the new behaviour. Happy‑melon 15:40, 31 January 2010 (UTC)

So these classes associated with {{Unicode}} and related templates are supposed to apply only to IE6? (My concern is the broken display of Sanskrit transliterations using {{transl}} in Firefox because it does not recognise the sa-Latn lang value and chooses a non-Latin font family for the text.) --Paul_012 ^(talk) 15:31, 1 February 2010 (UTC)

Background-color for mw-headline:target

span.mw-headline:target {
    background-color: #fbe54e;
    display:block;
}

I would like this code to be added to MediaWiki:Monobook.css to highlight targeted heading (e.g. clicked links from the TOC). The span need to be set to a block element, which is the parent h2 element, so the background extends across all the way. We can also use other CSS properties (color:maroon; border-bottom:1px dashed blue;) if this is going to break custom styles. — Dispenser 18:11, 7 February 2010 (UTC)

The principle is ok, but 1) that colour is utterly vile, and 2) I'm suspicious that we can really get away with adding display:block without screwing up the editsection links in some browsers. Can you check that that doesn't cause a problem? I'm also not too keen on the way the box doesn't have much/any padding around the text; the bottom of the 'g's actually breaks out of the bottom on my browser. Happy‑melon 18:38, 7 February 2010 (UTC)

We've used display:block; for inline elements elsewhere, the only problem I've noticed is in IE6 on {{skip to talk}}. I only bring it up because <h2 style="display:inline;">section</h2> breaks when highlighted (:target isn't supported on IE). This would be easier if the H2 had the ID, but then <h2 id="... The whole thing, by the way, is stolen from the new python documentation interface. Which also has this nifty thing to permalink to section. — Dispenser 19:21, 7 February 2010 (UTC)

I've tested this a bit, and though I like it in the Python documentation interface, it just doesn't feel right for me in Wikipedia. And indeed the color would definitely need work. But mostly.... What good does it do ? Most Wikipedia pages are so long you almost always will jump to the right section regardless, so why emphasize it with a colored bar ? —TheDJ (talk • contribs) 20:55, 7 February 2010 (UTC)

I think this might be a good thing, but I'll have to think more about it. (Provided that it doesn't cause any problems in older browsers etc.) I often want to go back to the section that I arrived at, and it sometimes is hard to find that section again in a long page.

Right, the dirt yellow colour in Dispenser's code is not nice. To me Wikipedia's base colours are black, white and blue. As in black text, grey borders, white page background, blue links both in the page text and in the menus, slightly blue page background in all non-article namespaces, and blue navboxes.

So I suggest we use a light blue. I did some testing and I like #dfe6ff; best. It has the exact same hue as the blue links, but is lighter so the text is easy to read. I show some example headings below.

Regarding the g's hanging out: I don't mind that. But I tried to add some padding to fix it, but it looked strange, so better to let the g's hang out.

Sometimes we add extra anchors to the headings, usually to keep old links working or because the heading has complex content. I noticed that when we link to those extra anchors then we don't get the background colour. But if we change the code to this:

.mw-headline span:target,
span.mw-headline:target {
  background-color: #fbe54e;
  display: block;
}

And then make the header anchors surround the whole heading text like this:

== <span id="An example">An <nowiki>{{example}}</nowiki> heading</span> ==

Then also links to "#An example" will get the target colour.

I know how to make this CSS only work for one page, so we can make a real live test page. Then everyone can test that one, and we can test that the gadgets and scripts that do stuff with headings still work, and we can do runs at browsershots.org to check how it works in many different browsers. I'll set that up if it seems people want this heading feature.

--David Göthberg (talk) 02:22, 8 February 2010 (UTC)

display:inline-block for ol's, ul's

Could "display:inline-block" be added to the styles for ol's and ul's? When either an ordered or unordered list is to the right of a left-floated image or other div, the numbers or bullets run into the image. (Effect can be seen on any stub article with a picture that extends into the references section.. off the top of my head, one can be found here.) By adding the inline-block display setting, the problem is fixed. I probably haven't done as much cross-browser testing as I should, but it works in Firefox, Safari, Opera, and Camino.. those are the only ones I have (Mac OS X). Can someone test it in IE and possibly some other browsers? --Dudemanfellabra (talk) 07:47, 4 February 2010 (UTC)

This has been discussed before, I'm sure.

If you have an image

• If
• you
• have
• a
• long
• list
• it
• runs
• over
• the
• bottom
• of
• the
• image
• and
• leaves
• a
• nasty
• blank
• space
• underneath
• it

If one of the list elements contains a lot of text, the whole block is pushed down below the image, preventing any wrapping at all. Happy‑melon 08:50, 4 February 2010 (UTC)

I didn't see anything about "inline-block" in the archive search above.... and I guess "nasty" is a relative word.. I'm fine with that space to the left of the list.. I actually like it better than what we have now. I think it looks crappy when the list wraps under the image. Maybe it's just OCD, but I like when all the bullets (or numbers) line up in a single column; it makes the list easier to read. The only articles (that I've seen) that would make use of this are normally very short, stubby articles that probably won't have long reference lists anyway. I don't think this is that big of a problem.. --Dudemanfellabra (talk) 15:54, 4 February 2010 (UTC)

What do you mean by "The only articles […] that would make use of this"? Your suggestion would apply to every article. Also, IMO it looks pretty ugly if the list is hanging there instead of wrapping like it should. —Ms2ger (talk) 16:01, 4 February 2010 (UTC)

I mean most articles don't have lists beside images like that unless the images extend into the reference section, which normally only happens in stubs (though of course there are exceptions). Changing the display to inline-block for lists that aren't anywhere near images doesn't change their display at all, so there would be no visual difference on those articles. The hanging list thing is apparently a matter of opinion, of which we don't agree. That is just an aesthetic preference, but the fact is that right now, the numbers are overlapping left-floated images (especially multi-digit numbers), and this problem fixes that. If you have a better solution (such as setting a margin on the lists, but that would screw up ALL of them) that would keep the numbers from overlapping with the images, I'm all ears. --Dudemanfellabra (talk) 18:56, 4 February 2010 (UTC)

If you have an image

• This
• looks
• fine
• to
• me

1. So
2. does
3. this

I'm aware that multi-digit numbers will overlap; but I don't see any serious problem with the example above on FF3.5. What browsers do you see a problem on? Are you really saying that left-floated images in the middle of multi-digit ordered lists, are a sufficiently serious problem to require us to impose this fix on all lists? More seriously, have you tried with a long line?

If you have an image

• If
• you
• have
• a
• very long line with lots and lots of content that extends over the whole width of the page and will break onto multiple lines even on very wide monitors (and especially on smaller monitors given how much text it contains)...

The list simply wraps underneath the image, defeating the purpose of the exercise. As I said before. Happy‑melon 23:07, 4 February 2010 (UTC)

I agree with Happy-Melon. This fix has as many disadvantadges as the original problem has. This issue needs the attention of the HTML working groups, I fear. I don't see how we can fix this problem on our own. —TheDJ (talk • contribs) 11:14, 8 February 2010 (UTC)

Testing heading colour 1

background-color: #fbe54e; display: block;

Testing heading colour 2

background-color: #dfe6ff; display: block;

Testing heading colour 3

background-color: #dfe6ff;

Testing heading colour 4

color: #008040;

End of test headers. The below discussion is a continuation of the discussion above the test headers, and is about all the above headers and more.

--David Göthberg (talk) 19:32, 8 February 2010 (UTC)

I like the idea, but I'm using FF 3.6 on Mac OS X with an extension installed on Wikipedia to display the edit links next to the heading text. Setting display=block makes the edit links go to the next line.. maybe using display:inline-block will work? --Dudemanfellabra (talk) 04:44, 8 February 2010 (UTC)

Ok, I just tested it, and inline-block kept the edit link by the heading text, but it didn't allow the background color to stretch across the page. Anyone that has this extension installed will not be happy with this. Any other ideas? --Dudemanfellabra (talk) 04:45, 8 February 2010 (UTC)

Ouch, you are right, the "my preferences - Gadgets - Moves edit links next to the section headers" breaks. But we can update that gadget so it removes the "display: block;". Or we can make the gadget insert the [edit] button inside the "<span class="mw-headline"></span>" thus we will still have the full width colour bar. (We'll have to test to see which looks best, but both should at least work technically.)

Another option is to instead insert an icon before or after the heading. Before looks better to me. I have just tested that and it works fine even when using that gadget. Here is the code I used for testing it:

/* Add an icon before a targeted heading (e.g. clicked links from the TOC). */
.mw-headline span:target, 
span.mw-headline:target {
  background: url("http://upload.wikimedia.org/wikipedia/en/0/00/Lock_icon_blue.gif") center left no-repeat;
  padding-left: 18px;
}

My above example code uses the padlock since I happened to have that code handy, we of course should use another icon. But I currently have no idea what icon would be fitting.

That is the same way MediaWiki inserts the external link icon and secure link padlock , and it seems very robust so shouldn't interfere with anything.

But I prefer having the background colour on the heading. So I think we instead should update the "Move edit links" gadget so it doesn't break.

--David Göthberg (talk) 06:50, 8 February 2010 (UTC)

I don't know how the gadget works (and I don't really know how to look up the source code), but it seems to me that making it display the edit link inside the span would work. I would prefer a background color over an icon of some sort... but it may be easier just to change the text color, kind of like a visited or highlighted link in IE? --Dudemanfellabra (talk) 17:36, 8 February 2010 (UTC)

Dudemanfellabra: Right, only changing the text colour should not cause any technical problems. I tested it: Using blue made the header look like a link, yellow was to light, red was to intense, so that pretty much left dark green. I added an example heading with dark green above. It looks fairly okay.

But if we add the background colour without the "display: block;" then it also should not cause any technical problems. And that also looks fairly okay. (See heading 3 above.)

But having the full width background colour is nicer. (Heading 2 above.)

The code for the gadget is at MediaWiki:Gadget-lefteditlinks.js. And changing that code so it coexists nicely with the "display: block;" is simple for us that code javascript, even for a beginner like me. I have already made such a version that I have tested in my personal sandbox, it works fine.

--David Göthberg (talk) 19:32, 8 February 2010 (UTC)

Noarticletext

The div.noarticletext rule is for the MediaWiki:Noarticletext message. I am planning to change that rule to instead have no border, margin, padding, and transparent background. (I can't just simply remove the rule since it is also declared in monobook/main.css.) The reason is that we need to be able to control the border and background from code in MediaWiki:Noarticletext. If anyone wants to know more, see MediaWiki talk:Noarticletext#More notices.

--David Göthberg (talk) 08:37, 15 February 2010 (UTC)

Y Done - Unfortunately many users will see double borders on the "no article" message during the time the CSS is decaching. But I feel slightly silly since after I deployed it I realized I could have made the transition smoother, but too late now.

--David Göthberg (talk) 07:09, 18 February 2010 (UTC)

IE zoomfix

I am considering adding the following:

.iezoomfix div,
.iezoomfix table {
  zoom: 1;
}

This would allow people to fix the rendering of right floating elements inside a div block, under Internet Explorer (see Template_talk:Documentation#Problem_with_right-aligned_images). This code does nothing on standards compliant browsers. We can also add it through JS, as IE only code of course. —TheDJ (talk • contribs) 22:23, 5 March 2010 (UTC)

Now added trough JS at MediaWiki:Common.js, like all the other IE only CSS. —TheDJ (talk • contribs) 19:39, 8 March 2010 (UTC)

WP:ACTOR and non-standard Filmographies (redux)

Hi. There is a discussion at:

• Wikipedia talk:WikiProject Actors and Filmmakers#Filmography

that may concern this page. One of the possible solutions to the issues at hand (re-coloring wikitables and reducing their font-size) might be implemented by adding some new classes and/or options to the site-wide css. class="wiki-filmograpy-table" or some such. And if this precedent is set, expect hundreds of more requests for things like "wiki-Hannah-Montana-colors". I'm posting here per a suggestion there by Ms2ger. I've expressed my views in the discussion, already. There is a related prior discussion at:

• MediaWiki talk:Common.css/Archive 9#Header color in wikitables

Cheers, Jack Merridew 20:03, 8 March 2010 (UTC)

I can say one thing, and that is that i find it very unlikely that 100s of requests to do something specific to a few articles will be accepted. Which makes it hard for me to believe that a something that would set a precedent for that will be accepted. Unless it is for technical reasons, I don't think it is a good idea to add per-project CSS to site-wide css or js. Where needed, templates can provide separate styling. I'd use a template with class=wikitable style="what you want" in this case. Perhaps we could have two styleset extensions for wikitable in the site-wide CSS (an extra tight, or a more distinct view or something). The most important thing to get something like that, is to clearly define WHY and where this differing styles should be used. Basically create a MoS, that describes which layout situations might require which style. That kind of clarity will be needed I fear. —TheDJ (talk • contribs) 20:42, 8 March 2010 (UTC)

Unfortunately, the "why" in this instance is "because our WikiProject is entitled to control its articles and wants to make them pretty" (scare quotes). Whether accomplished via CSS or templates, it isn't unrealistic that many other WikiProjects will want to act in kind (and perhaps even compete against each other for the flashiest styles). —David Levy 20:53, 8 March 2010 (UTC)

(edit conflict) I certainly do not favor adding this sort of thing to the site css and have expressed my opposition in that discussion. I've also repeatedly asked a 'why' question along the lines of yours and have not gotten a response. It seems to merely be a personal preference of s few editors. Cheers, Jack Merridew 20:56, 8 March 2010 (UTC)

Please note that this effects over 32,000 articles, not just a few. A variation of this style has been in place since the advent of that project in mid-2007 and it is not as trivial as "wiki-Hannah-Montana-colors". Wildhartlivie (talk) 22:04, 8 March 2010 (UTC)

When you are talking about adding something to Common.js you add it to 15.000.000 pages, so compared to that, 32.000 is 'just a few'. And please be careful with calling something 'trivial'. —TheDJ (talk • contribs) 22:13, 8 March 2010 (UTC)

latinx

{{latinx}} was recently deleted. Perhaps we should remove its accompanying class ? It seems to be hardly in use as far as I can determine. —TheDJ (talk • contribs) 11:18, 8 February 2010 (UTC)

 Removed. What's the situation with MediaWiki:Common.css/IEFixes.css?? Happy‑melon 15:21, 14 March 2010 (UTC)

references-2column

{{Reflist-2}} has been deleted and was the last major use of references-2column. I did a standard search and see no uses in article or template spaces, but we need to verify this with a dump search. ---— Gadget850 (Ed) ^talk 16:21, 28 February 2010 (UTC)

 Removed This isn't a crucial-enough piece of styling to necessitate digging out 100% of instances; it makes only an asthetic difference. Since (as you say) there are no search results, that's good enough for me. Happy‑melon 15:13, 14 March 2010 (UTC)

Coloring of the cited source missing

Proposal: Add the folllowing code

cite:target {

background-color: #ddeeff;

}

If this is added, the line with the text vos Savant, Marilyn (2006). "Ask Marilyn" column, Parade Magazine p. 6 (26 November 2006). will be light blued in the back ground when pressing this link: Monty_Hall_problem#refWhitaker1990.

It has been implemented at the Norwegian Wikipedia [1] and it works there.

See also proposing it here Template_talk:Citation#Coloring_of_the_Cited_source.3F. Nsaa (talk) 14:35, 5 March 2010 (UTC)

Already implemented. Try Security_question#cite_note-1 for instance. —TheDJ (talk • contribs) 15:04, 5 March 2010 (UTC)

That article is using raw HTML, which it really shouldn't. We have {{Ref}} and {{cite}} for a reason. One of those reasons, is that <cite> is actually an incorrectly used here, considering it's latest HTML5 definition. We use {{Ref}} in order to be able to change such things. —TheDJ (talk • contribs) 15:10, 5 March 2010 (UTC)

I notice btw, that even {{note}} still does this wrong... Related discussion was here: MediaWiki_talk:Common.css/Archive_10#reference:target. Will look into it. —TheDJ (talk • contribs) 15:29, 5 March 2010 (UTC)

Ok, the whole old footnotes system was a bit of a mess. Had to make a few changes there for sure. Also the span.citation:target we added in MediaWiki_talk:Common.css/Archive_10#reference:target is basically useless. It's never triggered, because span's with citation classes are never link targets (and should not be either) and <ref> uses ol.references li:target. We could start using them by adding the citation class to {{cnote}}, though I think in that case, it is better to call the class span.footnote. {{note}} cannot even be a link target, because it does not wrap the text of the footnote. Regardless, the page you referenced initially should be swapped to use the new grouped <ref and not using inline <cite>'s. —TheDJ (talk • contribs) 22:51, 5 March 2010 (UTC)

I have been looking at referencing templates, and it is a bloody mess. See User:Gadget850/Reference templates for other issues. ---— Gadget850 (Ed) ^talk 00:04, 6 March 2010 (UTC)

I added some notes to that talk of that page. —TheDJ (talk • contribs) 15:28, 6 March 2010 (UTC)

"Also the span.citation:target we added in MediaWiki_talk:Common.css/Archive_10#reference:target is basically useless. It's never triggered, because span's with citation classes are never link targets (and should not be either…": This is incorrect. See the examples at {{harvnb}} for example. —Ms2ger (talk) 17:41, 8 March 2010 (UTC)

OK, of all 20 or so templates, one supports it. —TheDJ (talk • contribs) 19:40, 8 March 2010 (UTC)

TheDJ, You said, "That article is using raw HTML, which it really shouldn't. We have {{Ref}} and {{cite}} for a reason." However, WP:CITE#Citation templates and tools says, "The use of citation templates is neither encouraged nor discouraged. ..." Many editors prefer to hand-craft cites. I'm not among them, but WP editors are constrained by WP:CITE to use the existing citation style in articles which they edit -- to hand-craft cites in articles which use hand-crafted cites. There are now some number of articles out there with handcrafted <cite id=whatever>...</cite> in them which now have the cite highlighting broken. I vaguely recall that there is an issue there with later versions of HTML, but don't recall the details and don't have time to re-research that at the moment. Anyhow, I'm wondering what approach you would suggest for applying citation highlighting to hand-crafted cites.

There are discussions related to this going on in several places, notably at Wikipedia talk:Citing sources/Example edits for_different methods#Highlighting Wtmitchell (talk) (earlier Boracay Bill) 23:31, 7 March 2010 (UTC)

Per the HTML5 definition, <cite>...</cite> is supposed to be used only for the title of a work.[2] We use it for full citations and notes. Wikipedia does not use HTML5 as yet, but there is a push towards it. ---— Gadget850 (Ed) ^talk 02:17, 8 March 2010 (UTC)

The ref templates might not be 'encouraged nor discouraged' but the usage of templates over RAW HTML in an articles definitely is. And the reason is exactly, that we are able to FIX what a template does (if needed by bots), and that raw html in an article is a lot harder to correct throughout Wikipedia. I fully agree that there should be a new highlight method. I'm proposing we highlight all li elements that are subelements of a .references element. We can then use the div of {{refbegin}} for instance to add a .references class around such lists. Alternatively, we make sure that all reference templates use a span.citation to wrap the entire citation (excluding the bullet). Does someone have a better idea ? —TheDJ (talk • contribs) 13:50, 8 March 2010 (UTC)

Either one of these proposal sounds very good. How can we discourage using the <cite>...</cite> elements directly in articles? Nsaa (talk) 13:46, 14 March 2010 (UTC)

The draft spec for HTML 5 says that the <cite>...</cite> element is to be used for, and only used for, the title of a work. (see here). Given the guidance in WP:CITE that "The use of citation templates is neither encouraged nor discouraged", I would say that discouraging the use of the <cite>...</cite> element in articles implies encouraging the use a template which would take a title and do whatever special handling is needed for titles (i.e., wrap it in a <cite>...</cite>). The alternative to that would seem to be to change the guidance in WP:CITE and encourage templated vs. hand-crafted citations.

Incidentally, see here for a list of links to places where <cite>...</cite> elements appeared as of 2010-Feb-03 (about 75 templates and 2500 articles). Wtmitchell (talk) (earlier Boracay Bill) 05:48, 18 March 2010 (UTC)

CSS striped for .wikitable

Here is the CSS for striped tables, with a minor color adjustment. This will work in Firefox, Safari, Chrome, Opera and Internet Explorer 9. Dread Lord CyberSkull ✎☠ 13:26, 12 March 2010 (UTC)

/* wikitable/prettytable class for skinning normal tables */
table.wikitable,
table.prettytable {
    margin: 1em 1em 1em 0;
    background: #f9f9f9;
    border: 1px #aaa solid;
    border-collapse: collapse;
}
.wikitable th, .wikitable td,
.prettytable th, .prettytable td {
    border: 1px #aaa solid;
    padding: 0.2em;
}
.wikitable th,
.prettytable th {
    background: #f1f1f1;
    text-align: center;
}

.wikitable tr:nth-child(odd),
.prettytable tr:nth-child(odd) { /* The striping is handled by the :nth-child pseudo-class, with the odd row adjusted. */
    background: #f5f5f5;
}
.wikitable caption,
.prettytable caption {
    font-weight: bold;
}

Standard wikitable

Header
Table
Cells
All the same
Colour

Proposed new style

Header
Table
Cells
Alternating
Colour

I can't tell the difference between the stripe colours, but I can tell that the table cells are less differentiated from the header cells. Why is this considered a good idea? Happy‑melon 18:26, 12 March 2010 (UTC)

I agree fully with that assessment Happy-Melon. —TheDJ (talk • contribs) 21:32, 12 March 2010 (UTC)

Is there any discussion about this? Locos epraix ~ Beastepraix 23:18, 14 March 2010 (UTC)

This is the discussion :D Happy‑melon 11:28, 15 March 2010 (UTC)

Well, in that case, why should the cells alternate its color? Locos epraix ~ Beastepraix 16:36, 15 March 2010 (UTC)

No idea. Happy‑melon 16:40, 15 March 2010 (UTC)

There are tables that would benefit from this. It would be nice to have this as an option, but not as the standard. ---— Gadget850 (Ed) ^talk 16:44, 15 March 2010 (UTC)

A few points; the two colors are too close to each other and a bit more differentiation would be needed to deploy this. Also, it's likely that the even/odd arrangement is backwards and that it would be better to have the first (odd) rows be the ones with the lighter cell color. And I do believe this would be best as an option on wikitables, not the norm; i.e. invoke it with:

{{ class="wikitable striped"

Wandering a bit, I think the the bolding of th-elements should be made explicit rather than relying on the typical browser default styling. This would be something like:

.wikitable th,
.prettytable th {
    background: #f1f1f1;
    text-align: center;
    font-weight: bold; /* added */
}

Cheers, Jack Merridew 18:35, 3 April 2010 (UTC)

another take:

'zebra'

×	1	2	3
1	1	2	3
2	2	4	6
3	3	6	9

.wikitable.zebra tr:nth-child(odd)
{
 background-color: yellow;
}
.wikitable.zebra tr:nth-child(even)
{
 background-color: pink;
}

If we add something like the above, we'll have an optional version of this. I'm not advocating yellow or pink, they're just for clarity in the example (which is all hard-coded). I've omitted "prettytable" as we want to be deprecating that and should not offer any new features under the old name. I've also used the class name 'zebra' per zebra striping, but would be fine plain "striping", although we might want that for non-even/odd striping, someday. nb: the keywords odd/even and this multiplication table example are a bit at odds, as the heading row counts as row '1' while row '1' is the second row ;)

Cheers, Jack Merridew 22:01, 6 April 2010 (UTC)

(sound of lead balloon hitting floor)

ok. The pink and yellow sucks. Let's float something more realistic.

'zebra striped table'

xyzzy	Plover	Get Axe	Fee Fie Foe Foo
Little maze of twisting passages	Little maze of twisty passages	Little twisty maze of passages	Little twisting maze of passages
Maze of little twisting passages	Maze of little twisty passages	Maze of twisting little passages	Maze of twisty little passages
Twisting little maze of passages	Twisting maze of little passages	Twisty little maze of passages	Twisty maze of little passages
Little maze of twisting passages	Little maze of twisty passages	Little twisty maze of passages	Little twisting maze of passages
Maze of little twisting passages	Maze of little twisty passages	Maze of twisting little passages	Maze of twisty little passages
Twisting little maze of passages	Twisting maze of little passages	Twisty little maze of passages	Twisty maze of little passages

.wikitable th
{
 background-color: #e9e9e9; /* changed */
 text-align: center;
 font-weight: bold; /* added */
}
/* new: */
.wikitable.zebra tr:nth-child(odd)
{
 background-color: #f1f1f1;
}
.wikitable.zebra tr:nth-child(even)
{
 background-color: #f9f9f9;
}

This example darkens the header cells a tad (to #e9e9e9) and uses the former header color (#f1f1f1) for the odd rows and is explicitly setting the usual data cell background-color to the normal (#f9f9f9); 'even' could be omitted and allowed to inherit from the ambient table styles.

Any interest?

Cheers, Jack Merridew 05:08, 15 April 2010 (UTC)

Is the bit about being supported in "Internet Explorer 9" a joke? --MZMcBride (talk) 21:36, 18 April 2010 (UTC)

The CSS3 nth-child selector is supported in FF 3.5, Safari 3.1, Opera 9.5, Chrome 2.0 and yes, the forthcoming Internet Explorer 9 (reflist columns should work as well). ---— Gadget850 (Ed) ^talk 21:53, 18 April 2010 (UTC)

Ya, all the modern browsers support this, and Microsoft may-well have one, too; next year (or moar;). And it should all degrade gracefully. I'm not too fussed about just what shades of gray are used and there may be a bit of concern about changing the header cell background. It would also bee goodness to offer a bit of guidance about when this is appropriate to use. Tables with rowspans would get odd effects, for example. Cheers, Jack Merridew 22:09, 18 April 2010 (UTC)

on toclimits

Hi. I believe the following css would be cleaner as it avoids displaying empty <ul> elements (i.e. those with 0 visible <li> elements):

status quo	suggestion
.toclimit-2 .toclevel-2, .toclimit-3 .toclevel-3, .toclimit-4 .toclevel-4, .toclimit-5 .toclevel-5, .toclimit-6 .toclevel-6, .toclimit-7 .toclevel-7 { display: none; }	.toclimit-2 .toclevel-1 ul, .toclimit-3 .toclevel-2 ul, .toclimit-4 .toclevel-3 ul, .toclimit-5 .toclevel-4 ul, .toclimit-6 .toclevel-5 ul, .toclimit-7 .toclevel-6 ul { display: none; }

Rather than affecting the list items directly, it invisiblizes whole lists starting at the previous depth. ―AoV² 09:25, 18 March 2010 (UTC)

Bump to avoid archive-bot. ―AoV² 03:57, 4 April 2010 (UTC)

No objections from me. Anyone else have an opinion ? —TheDJ (talk • contribs) 23:54, 5 April 2010 (UTC)

 Done —TheDJ (talk • contribs) 23:23, 6 April 2010 (UTC)

Table header inheritance in IE8

Discussion moved from Template talk:Infobox UK place#Centred text?

Microsoft recently removed en.wikipedia.org from its IE8 compatibility-mode list, so IE8 clients with the latest list now see Wikipedia rendered in standards-mode by default. This seems to have caused <TH> table-header content to render with centered text even where the parent <TABLE> table tag has inline CSS style="text-align:left". For example, the infobox headings at Template:Infobox UK place/testcases now render center-aligned in IE8.

The problem appears to be that table-header elements do not inherit the text-align style of their parent TABLE element in IE8 standards mode, as documented here. Should MediaWiki:Common.css be amended to include a workaround?

— Richardguk (talk) 21:50, 13 April 2010 (UTC)

I guess we could make that change yes... —TheDJ (talk • contribs) 22:24, 13 April 2010 (UTC)

Should go into MediaWiki core, we have IE80Fixes.css now. — Dispenser 00:50, 14 April 2010 (UTC)

This is not really a bug in IE8 at all. Both the HTML5 and CSS2.1 specs recommend this result. I've filed bugs against Gecko and WebKit. Apparently this weird behavior of th (that alignment is mysteriously inherited from the parent element sometimes but not always) is due to some kind of pre-CSS legacy constraints.

Bug or not, the suggested fix will hurt far more than it helps. It will make all th elements left-aligned, not just ones with text-align:left specified on a parent. I'd recommend you code for the (standards-compliant, CSS-based) IE8 behavior and explicitly specify left alignment on your th's when you want it. —Aryeh Gregor (talk • contribs) 18:30, 14 April 2010 (UTC)

Interesting. Ok then do we want to just define it for infoboxes ? —TheDJ (talk • contribs) 19:28, 14 April 2010 (UTC)

So the code in Common.css would be changed from:

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

to:

.infobox td, .infobox th { vertical-align: top; text-align: left; }

? — Richardguk (talk) 20:38, 14 April 2010 (UTC)

No, that will affect all infoboxes, and not all infoboxes are left-aligned. The relevant fix would be to add a rule like:

.infobox.geography th { text-align: left }

Geography infoboxes are the only ones that are left-aligned at present in Common.css, so they're the only ones that need this fix. Note that this will change behavior if someone does something like <table class="infobox geography"><tr align="center"><th>...; the change I suggest isn't free of side effects. The only side effect-free solution would be to alter all the templates by hand. —Aryeh Gregor (talk • contribs) 17:08, 16 April 2010 (UTC)

Why not set

.infobox th { text-align: inherit; }

 ? Then we standardize behavior for a specific case. —TheDJ (talk • contribs) 13:19, 18 April 2010 (UTC)

You could, but that will left-align all th inside infoboxes, while currently they're mostly center-aligned. —Aryeh Gregor (talk • contribs) 18:00, 18 April 2010 (UTC)

I think you′ll find more of them have an over-ridden style attribute text-align:left;. Perhaps only the <th> cells on the first row of a table (or those whose colspan is such that it occupies an entire row) should have text-align:center; as a default, something like:

th { font-weight:bold; text-align:left; }
tr:first-child th, th:only-child { text-align:center; }

Typical arrangement in rendered infobox:

<tr><th>Population </th><td>Over 9,000</td></tr> <!-- th should be text-align:left; -->
<tr><th>Power level</th><td>Over 9,000</td></tr> <!-- th should be text-align:left; -->
<tr><th colspan="2">Politics</th></tr>         <!-- th should be text-align:center; -->

In wikitable:

{| class="wikitable"
! Year 
! Foo !! Bar !! Baz <!-- should all be text-align:center; -->
|-
! 1979 <!-- should be text-align:left; -->
| Lorem || Ipsum || …
|-
! 1980 <!-- should be text-align:left; -->
| … || … || …
|}

―AoV² 19:10, 18 April 2010 (UTC)

code tag within link

[[Main Page|Foo <code>Bar</code> Baz]]

→

Foo Bar Baz

→

see screen-shot

For whatever reason the <code> tag interrupts the under-lining of a link which contains it, at least on my screen (see above):

Recommend:

a code { text-decoration:inherit; }

―AoV² 02:15, 14 April 2010 (UTC)

Can't we just recommend that people not use <code>? --MZMcBride (talk) 19:57, 14 April 2010 (UTC)

<tt> is a deprecated element. What are we supposed to recommend they use instead? Happy‑melon 10:23, 15 April 2010 (UTC)

Isn't <s> also deprecated? There's a reason people ignore these standards. <tt> is preferable to <code> in my view. --MZMcBride (talk) 15:30, 15 April 2010 (UTC)

This is because of Mozilla bug 365970, and a similar bug in WebKit. Opera behaves correctly, and it seems so does IE. text-decoration: inherit will not work quite right in general, because the underlines will be inherited instead of drawn from the parent element: this can produce weird results in cases like ABC. In Firefox, this displays with a noticeably different underline for "B", because the underline is redrawn with the different font size. (WebKit seems to use the same underline thickness independent of font size.)

This oddity might not be serious enough to be worried about, though. Probably

a code, a tt { text-decoration: inherit }

is a reasonable addition to the site CSS for skins that use different backgrounds for code. Or just doing

code, tt { background: none }

would solve the problem, too, removing the barely-visible gray background. —Aryeh Gregor (talk • contribs) 16:57, 16 April 2010 (UTC)

I suppose we could remove the background from all matter within a link:

a * { background: none !important; }

Then hide when people complain that their sigs suddenly look normal. ―AoV² 20:36, 16 April 2010 (UTC)

Support !! :D —TheDJ (talk • contribs) 20:41, 16 April 2010 (UTC)

Clarify: <tt>...</tt> is not deprecated for HTML 4 and XHTML,[3] but CSS is recommended instead. It is not supported in HTML 5, nor are center, big, small and s.[4] We are moving toward HTML 5, so this is something to keep in mind, ---— Gadget850 (Ed) ^talk 19:33, 18 April 2010 (UTC)

I've been recently informed that <small> is supported in HTML5. And while I support AoV2's addition, I do not think it goes far enough. We need something to nullify the color and face properties of <font> so that users will use proper CSS based style attributes. — Dispenser 21:54, 18 April 2010 (UTC)

You are right— not sure how I added it. Here is a full list showing unsupported tags.[5] ---— Gadget850 (Ed) ^talk 22:04, 18 April 2010 (UTC)

Wrapping on UserLogin

I propose to add

page-Special_UserLogin .mw-label { white-space : nowrap; }

This avoids that the labels of the input fields on Special:UserLogin are spread over two lines ("retype password" and "E-mail (optional)". This is especially notable on the Signup page, when you are not logged into Wikipedia. I think it makes it a lot more readable. —TheDJ (talk • contribs) 18:07, 3 April 2010 (UTC)

This doesn't seem unreasonable, as it will only widen the form a bit and it's not very wide as it is. I'm thinking you may want to tweak the selector used to:

page-Special_UserLogin .mw-label label { white-space : nowrap; }

to directly target the label-element instead of the td containing it. I've not looked closely at just what's inheriting what from where, so this might not actually work if there is other code intent on other levels of the markup structure. Cheers, Jack Merridew 18:22, 3 April 2010 (UTC)

 Done —TheDJ (talk • contribs) 23:47, 5 April 2010 (UTC)

{{editprotected}}

It's not working for me in Firefox. I think the code is missing a dot, so the correct code should be:

.page-Special_UserLogin .mw-label label { white-space : nowrap; }

Svick (talk) 14:00, 6 April 2010 (UTC)

Correct. ―AoV² 14:10, 6 April 2010 (UTC)

I agree; someone should add the dot; it was missing from the initial example and I didn't notice when I added the 'label' suggestion. I've tested this via Firebug and it's fine. Cheers, Jack Merridew 21:32, 6 April 2010 (UTC)

Damn copy paste. Had it right in my own monobook, so never even noticed. —TheDJ (talk • contribs) 21:44, 6 April 2010 (UTC)

{{editprotected}} Not to be a nudge, but where did the "_signup" come from?

body.page-Special_UserLogin_signup .mw-label label { white-space : nowrap; }

it should be:

body.page-Special_UserLogin .mw-label label { white-space : nowrap; }

(or both, if the _signup form is used somewhere). Cheers, Jack Merridew 00:27, 7 April 2010 (UTC)

Both are required. Seems there are two variants of the signup page. (Man that thing is a mess). —TheDJ (talk • contribs) 12:04, 7 April 2010 (UTC)

It would also leave less width for the <div class="prefsectiontip"> which follows. I think we′d address this best by putting it in its own cell on a separate row with colspan="2", either directly below the wpEmail row or below the mw-submit buttons. Also the asterisk in that message invokes an unordered list rather than matching the literal asterisk in “E-mail (optional)*”. ―AoV² 00:03, 4 April 2010 (UTC)

I fixed the asterisk —TheDJ (talk • contribs) 13:20, 18 April 2010 (UTC)

That could work; I'd be inclined to keep it just below and not all the way down below the buttons. fyi, while looking further at this, I notice that the text "Already have an account? Log in." is invalidly wrapped in two levels of p-elements, so if someone edits this wherever it is in the MediaWiki namespace, it should be looked into. Cheers, Jack Merridew 00:19, 4 April 2010 (UTC)

That would require a software change though, wouldn't it ? —TheDJ (talk • contribs) 12:20, 4 April 2010 (UTC)

It might, I'm not sure where that text/markup originates. I was thinking that it's just UI wikitext that could be edited with a mop. The generated markup I'm referring to is:

<p id="userloginlink"><p>Already have an account? <a href="/w/index.php?title=Special:UserLogin&amp;type=login">Log in</a>. </p></p>

(there's a newline where the space is before the pair of /p-elements)

I'll nose-about and see if I can find it. Cheers, Jack Merridew 19:59, 4 April 2010 (UTC)

This was fast, but unsatisfying; MediaWiki:Gotaccount appears to be the text itself, but there's no markup, so the issue may well be in MediaWiki itself :( Jack Merridew 20:02, 4 April 2010 (UTC)

We could file a bugreport on this, because in my opinion that entire special page needs some work, but I don't think we can do anything about it here. —TheDJ (talk • contribs) 23:47, 5 April 2010 (UTC)

Sure, I'm not seeing a local fix, so the MW-folks should be poked about this, and whatever else you have in mind. Cheers, Jack Merridew 21:32, 6 April 2010 (UTC)

The differing body-class appears only when you use url with a slash after the title of a special page, not in the default link which uses a separate parameter, viz. title=Special:UserLogin&type=signup. See also bugzilla:23315. ―AoV² 12:14, 28 April 2010 (UTC)

RecentChanges color certain users?

Hi there, I have my own MediaWiki set up, and I saw another has this code.

.page-Special_RecentChanges [title="User:<USERNAME>"]
{
    font-weight: bold;
    color:#70B04A;
}

I'm wondering why this isn't working for me. I placed it near the end of my Common.css. If someone could get back to me I'd be much obliged. Smashman2004 (talk • contribs • email) 10:34, 27 April 2010 (UTC)

Obviously I've replaced <USERNAME> with the user's username. Smashman2004 (talk • contribs • email) 10:35, 27 April 2010 (UTC)

This should do the trick. —TheDJ (talk • contribs) 10:38, 27 April 2010 (UTC)

body.page-Special_RecentChanges a[title="User:<USERNAME>"]

If your browser supports attribute selectors. —TheDJ (talk • contribs) 10:43, 27 April 2010 (UTC)

Actually, the above's working now. Very odd. Thanks for the prompt response. Smashman2004 (talk • contribs • email) 10:46, 27 April 2010 (UTC)

Proposed change because of Template:Portal box

I proposed a change to {{portal box}} that requires also a change of this page. See the discussion at Template talk:Portal box#Better syntax. Svick (talk) 20:58, 3 May 2010 (UTC)

Missing wikitable styles for print

I just noticed that since the wikitable move, there is no longer wikitable css for print. See this. We need to follow that up. —TheDJ (talk • contribs) 02:54, 13 May 2010 (UTC)

Added to MediaWiki:Print.css for now. Should be added to core software. See bugzilla:23507. —TheDJ (talk • contribs) 17:01, 13 May 2010 (UTC)

Simple line, major proposal

From the indications at the VP and many other related pages, it is clear that the new logo is much despised. I therefore suggest the unusual, but possibly warranted inclusion of the following line:

#p-logo a {background-image: url(http://upload.wikimedia.org/wikipedia/en/6/6b/Wiki.PNG) !important;}

--Ipatrol (talk) 20:25, 13 May 2010 (UTC)

"Much despised" is a highly subjective term. Let's do this by the mathematical numbers: we have roughly 371 million unique visitors per month. Can you point to a proportion of them that you believe "despise" it, and the validation for that argument? Philippe Beaudette, WMF (talk) 20:41, 13 May 2010 (UTC)

WP:VPT#New logo AON. Also, lack of complaints from readers does not mean approval. It usually means that they don't know how to or want to get involved with us. Consensus of the interested should decide this.--Ipatrol (talk) 01:50, 14 May 2010 (UTC)

Add class="rellink" to MediaWiki:Print.css

{{editprotected}} Since the talk page of MediaWiki:Print.css (edit | talk | history | links | watch | logs) redirects here, I'm putting my request here. Please add .ns-0 .rellink, to the first CSS item there. {{Rellink}}, which uses this class, is a meta template for showing links to related articles. The template and its derivatives are currently in the category "Exclude in print", but this only prevents the templates from being shown in the book tool. To make it work with the usual printing, skinning it here would be needed. An alternative would be to add class="noprint" to the template itself, but there might be situations in which one might want to print it, possibly in other namespaces. Thanks, --The Evil IP address (talk) 15:31, 19 May 2010 (UTC)

I've disabled the request because this page is watched by many, and all changes need to be discussed anyway. — Martin (MSGJ · talk) 16:21, 19 May 2010 (UTC)

Do we really want to exclude this from print however ? Unlike navboxes etc, rellinks can be quite bound to the following content. Without them, some sections can be really sparse, and I have even seen cases (especially in developing content) where it was the only element to follow a sectionheader. —TheDJ (talk • contribs) 22:41, 23 May 2010 (UTC)

I agree that it's often not desirable to hide these in print; so I'm not sure that this is a good idea. Happy‑melon 09:50, 24 May 2010 (UTC)

I just yeesterday thought of this problem. Probably, simply using CSS doesn't suffice to fix this problem. --The Evil IP address (talk) 11:24, 24 May 2010 (UTC)

references-small

See Wikipedia:Requests for comment/May 2010 skin change/Bug reports#Reflist template. ---— Gadget850 (Ed) ^talk 21:16, 7 June 2010 (UTC)

How to add borders to <source> tags

==Question==

I wanted to ask how to do the line around the code when you add the <syntaxhighlight> or <SOURCE> tags to show the code? I wanted to know so that i can add it for pa wiki, i think it looks better that way, with code separated from rest of article. Thank You. Also is there a better place to ask these sort of questions? Gman124 ^talk 14:03, 14 July 2010 (UTC)

See discussion at WP:Village pump (technical)/Archive 62#GeSHi update, then more specific proposal at MediaWiki talk:Monobook.css#restore GeSHi borders?, the code was added in June 2009. — AlexSm 15:08, 14 July 2010 (UTC)

Ok Thank You Alex. :) Gman124 ^talk 16:10, 14 July 2010 (UTC)

Latest changes made a problem

[6] That latest change disabled my Firefox (3.6.7) browser (using Windows 7) from choosing the fonts I have specified for IPA in my own user:Mahmudmasri/vector.css. I need help. The latest change made it only possible for my browser to choose my specified fonts if there were texts written as {{IPA|/tekst/}} only after I wrote that: span[class|=IPA] rather than .IPA, but still I have a problem: all the IPA wikitables such as Help:IPA conventions for English#Vowels don't choose my specified font for IPA. Please, help me overcome the problem. --Mahmudmasri (talk) 07:39, 24 July 2010 (UTC)

span.IPA or adding !important before the ; should work as well. Because the CSS is now added by Javascript, it is higher in importance than things in your skin css. —TheDJ (talk • contribs) 14:21, 24 July 2010 (UTC)

Would you please edit my page, because I tried in accordance to your advice & failed? Thanks. My trials: [7], [8], [9], [10], [11]. --Mahmudmasri (talk) 10:10, 25 July 2010 (UTC)

Wikitable

Wikitable is now defined in shared.css.[12] ---— Gadget850 (Ed) ^talk 17:55, 27 April 2010 (UTC)

So what will we do with prettytable ? —TheDJ (talk • contribs) 18:20, 27 April 2010 (UTC)

The style that MediaWiki is using is simpler, I think. I'm in the "if it ain't broke, don't fix it" camp, personally. --MZMcBride (talk) 18:27, 27 April 2010 (UTC)

You sure ? They look identical to me.... —TheDJ (talk • contribs) 19:48, 27 April 2010 (UTC)

Huh, guess you're right. Looks like it was just copied and pasted directly from en.wiki (diff). Must've been the lack of prettytable that threw me. I've searched the database in the past for instances of "prettytable." It probably needs another pass-through before this code can safely be removed. --MZMcBride (talk) 19:57, 27 April 2010 (UTC)

I did a search from the February dump: User:Gadget850/dbsearch/prettytable 2010-Feb-03. Looks like 495 uses. ---— Gadget850 (Ed) ^talk 20:50, 27 April 2010 (UTC)

I just tackled all the uses that were not in article or Wikipedia namespace. Still many uses remaining of course. —TheDJ (talk • contribs) 23:45, 27 April 2010 (UTC)

I removed the wikitable definitions and left the prettytable ones until we get the above list sorted out. —TheDJ (talk • contribs) 23:57, 27 April 2010 (UTC)

Could we do something like using CSS's content property or just break it like with .hiddenStruct? Its been on the /to do list for the last ten months. I fear the stalemate will continue. — Dispenser 04:12, 28 April 2010 (UTC)

You might have added the opening phrase above ("Wikitable is now defined in shared.cs") in your edit comment at the removal from common.css. You gave me quite a scare. Wikitable is used all over the place. −Woodstone (talk) 05:52, 28 April 2010 (UTC)

Hmm, reading back the history page, I see your concern :D. —TheDJ (talk • contribs) 13:34, 28 April 2010 (UTC)

I have updated uses of prettytable in all articles, all templates (except for some TfDs) and Wikipedia pages (except for archives). Also fixed a number of uses of {{prettytable}} that were still hanging around and other odd uses, such as those stuffed into ref tags. ---— Gadget850 (Ed) ^talk 14:21, 28 April 2010 (UTC)

OK, so we only have uses in some archives and in userpages left now right ? How much do we care about those ? —TheDJ (talk • contribs) 12:05, 29 April 2010 (UTC)

Not much. I still have the February dump, so I might have missed some new uses. There were no userpage uses. That leaves a handful of archives that I am not going to worry about and a number of discussions about prettytable that should not be updated. That leaves common.css and the catalogue. ---— Gadget850 (Ed) ^talk 13:04, 29 April 2010 (UTC)

Anyone else care to comment ? I'm in the remove the prettytable rules camp. —TheDJ (talk • contribs) 22:15, 3 May 2010 (UTC)

I'll pitch my tent there, too. Long overdue. Happy‑melon 22:20, 3 May 2010 (UTC)

Me, too. This has been years in the making. Salt template:prettytable, too? Cheers, Jack Merridew 22:25, 3 May 2010 (UTC)

I pulled the trigger on this one. It was about time. —TheDJ (talk • contribs) 17:10, 13 May 2010 (UTC)

Will somebody update Wikipedia:Catalogue of CSS classes? Should be done by those who revised those classes to be as correct as possible, I think. Best regards -- JörgM 84.156.149.151 (talk) 08:45, 5 August 2010 (UTC)

Get lang sa-latn to display in normal font

Because of a long-standing Firefox bug, marking up transliterated text as such results in ugly output, e.g. consider {{IAST|thiṣ}}, rendered as "thiṣ" when it really ought to look the same as "thiṣ". This happens because the transliterated text is marked up by the CSS as being in a <span lang="sa-Latn">…</span>, which the browser is failing to understand is still in Latin script. As the comment on the Firefox bug says, we're "left with the choice of forcing a latin compatible font on the user, or removing lang tags for transliterated text". Could we do something in CSS to fix this? For further details please see MediaWiki_talk:Common.css/Archive_7#Ugly_fonts_for_transliteration_templates, Template talk:IAST#Font selection and Template talk:Transl#Font for translated words. As dab suggests there, it may be possible to fix this by introducing a pseudo-class for sa-latn, ar-latn, and a few others. Shreevatsa (talk) 17:57, 30 July 2010 (UTC)

I guess we can explicitly set a specific font, that does seem to work. However we have no idea of what kind of font users are using for their text, so it will still not match the surrounding text in many cases (especially on differing browsers). I'd prefer it to just remove the lang options from these templates. —TheDJ (talk • contribs) 19:24, 30 July 2010 (UTC)

Argh! That would be a huge regression accessibility-wise. I really hope we can avoid it somehow.

Even if the font difference would still be visible, it might be less disturbing for users. So I'd say we should give a chance to this solution. Let's try it and see how users react.

If the above doesn't work, we can still make a huge commotion about this Firefox issue, and get it solved somehow. Wikipedia made a partnership with Firefox about Ogg Theora, why not about language fonts?

Or let's ask Jimmy to talk to the Firefox guys! :D At Wikimania, he did say he'll meet with Bill Gates to complain about Microsoft issues that, in the end, made it very hard for users from underdeveloped countries to edit Wikipedia. Too bad it was a joke. Yours, Dodoïste (talk) 22:31, 30 July 2010 (UTC)

Is there any software in the world though, that understands that this is a language transliterated to latin script though ? (Other than perhaps Google's searchengine or something) There is a title attribute on the span, that will probably at least help the screenreader folks. —TheDJ (talk • contribs) 22:38, 30 July 2010 (UTC)

Hmmm... I'm using Firefox 3.6.6 on Ubuntu 10 now (was previously using Chrome and Konqueror), and I don't get the issue mentioned. All the samples "thiṣ" looks exactly the same to me, both in Firefox and the two other browsers I was using. Is it because I'm using Linux, or is the latest version of Firefox fixed somehow?

I suppose they have implemented this functionality. However, I do not know exactly know wich screen readers implement what, and how they work exactly. I'm trying to use Orca (assistive technology) (which may not be as good as JAWS) as of now. Like other screen readers, it has TONS of shorcuts that every day user know by heart, but I only know one of them (which activate: "start reading page"). You'd better ask user:Graham87 how he can make use of lang tags with JAWS.

The one thing I do know, is that we should follow the standards and not the implementation from screen readers. Screen readers are often lacking here and there, depending on their priorities for development, and actual use of the functionalities. If a standard gets widely used on the Web, it will become a priority for Screen readers to implement it. Wikipedia, as a top 5 website - and the third most favourite website for screen reader users (early 2009) - plays a important role in it. What I want to say is: even if it was not currently implemented, if Wikipedia were to use those lang tags, screen readers would implement it as well sooner or later. Dodoïste (talk) 02:17, 31 July 2010 (UTC)

No, it's not fixed in the latest version of Firefox, at least on Mac. See the examples at Template:Transl#Examples: do all of them appear in a normal font? I see at least five different fonts! I also do think it's better to fix this with CSS somehow without losing the metadata, especially if screen readers can make use of the metadata. Shreevatsa (talk) 02:46, 31 July 2010 (UTC)

I agree with you about the metadata. Sometimes a picture is better than a thousand words : here is what I see with Chrome 5, and what I see in Firefox 3.6.6. It looks messed up in Chrome, but Firefox seems to be doing fine. Yours, Dodoïste (talk) 03:58, 31 July 2010 (UTC)

Hmm, this is what it looks like on my Firefox on Mac OS X: I added the word in plain text in each case, so that it's easier to compare. In nearly every case, it is displayed in a different font from normal text, and the displayed font is often distracting when used in a sentence. Shreevatsa (talk) 04:51, 31 July 2010 (UTC)

Firefox has different preference orders in different scripts. With the sa-Latn tag on a span, Firefox will consider the language Sanskrit to be enclosed, and will try to use fonts that it knows offer better support for Indian scripts (how it does that exactly, i'm not sure). It does however not recognize the -Latn extension, which is called a script manipulator tag. This tag says, "Sanskrit language in Latin script". Like I said, since this is a only 4 years old RFC, I doubt ANYTHING in the world supports this, other than wikipedia at this time. I'm a big fan of promoting new standards like this, but when it is at the expense of messed up rendering for 20% of our readership, I'm not so sure anymore. I see the same issue as Shreevatsa in Firefox. I wonder what the Windows users get (i doubt it's much better). Using fixed css will hardly improve this I think and more importantly, it will break the rendering for all the platforms that currently don't have this issue. Thus, although consistent, the results would be worse. —TheDJ (talk • contribs) 12:51, 31 July 2010 (UTC)

When JAWS encounters a lang tag, it tries to make the speech synthesizer speak the enclosed text in the indicated language. By default, it can only speak in English, Finnish, French, German, Italian, Portuguese, and Spanish, all of which use the Latin alphabet. However in recent versions, other languages can be added, some of which do not use the Latin alphabet. I don't have the correct JAWS version to try these additional languages, but I'm guessing from the samples that languages like Chinese use an English voice when they are reading text in the Latin alphabet, such as transliterations. Therefore the language tag would be unnecessary and downright confusing for transliterations with JAWS. JAWS users can also use ESpeak, which behaves in the same way for most languages which do not use the Latin alphabet. Graham87 15:14, 31 July 2010 (UTC)

Here's the problem as it appears for me (Firefox 3.6.8 Vista) in Clay Sanskrit Library. The surrounding font is Gentium (according to my style sheet), whereas the Template:IAST text is an atrocity. The bottom line is that, if there is nothing I can do to get a correct result here, then I would be far better off with the template scrapped. Wareh (talk) 18:19, 5 August 2010 (UTC)

I have just disabled the language tag on these transliterations. It is a shame, but it's simply too annoying at this time, with too few benefits. —TheDJ (talk • contribs) 19:11, 5 August 2010 (UTC)

Thanks for the effort, but at Template:Parami (which I've never viewed before, so no cache issues), prajñā, kṣānti, paññā, and adhiṭṭhāna still have the poor font selection. So somewhere under the rubric of Template:IAST & its transcluded tools, there is some ill-advised font selection going on still. Sorry I'm not technically proficient enough to give more information about where the problem remains. Wareh (talk) 13:54, 6 August 2010 (UTC)

All those pages look fine to me now (those using {{IAST}}). Maybe you can try clearing your cache and reloading the page? Shreevatsa (talk) 16:52, 6 August 2010 (UTC)

No, the problem really persists for me. See my screenshot above for exactly what I'm still seeing. I just cleared my cache and visited Otto von Böhtlingk, a page I've never viewed before. No need to look in the source code to find Template:IAST -- it's the single ugly word Aṣṭādhyāyī (Aṣṭādhyāyī), sticking out at me in that funny font like a sore thumb. I'm using the old Wikipedia interface (i.e. I didn't adopt the new one that was rolled out very recently), so that I can continue to use User:Wareh/monobook.css. This isn't enough of an annoyance to make me change my global display preferences, but I do wish Template:IAST would be swept into the dustbin if it can't use available or standard attractive fonts. Wareh (talk) 18:09, 6 August 2010 (UTC) P.S. I can be more specific. <span title="International Alphabet of Sanskrit Transliteration" class="Unicode" style="white-space:normal; text-decoration: none">Aṣṭādhyāyī</span> renders on my display in Code2000, a true abomination of a font. Maybe I will consider going as far as deleting Code2000 from my system. Can Gentium be put ahead of Code2000 in the font selection priority for everyone? Or does some generous soul want to change User:Wareh/monobook.css so that Gentium overrides for class="Unicode"? Wareh (talk) 18:12, 6 August 2010 (UTC)

This is a seperate issue with the Unicode font, and not with the script overrides of the lang attribute. I welcome any suggestions for a more useful order of the fonts. (Of course most people won't have Gentium). —TheDJ (talk • contribs) 19:54, 6 August 2010 (UTC)

Where can I find the existing font order? Not in the Common.css whose discussion page we're discussing on, according to a search I tried. Most people won't have Code2000 either, and it is a sub-standard display font whose only virtue is character coverage, so I would suggest its demotion to the bottom of the list, as a fall-back only if nothing better is available. In any case, there's no harm in putting better but rarer fonts ahead, since they will simply be skipped for those who lack them. Of course, Gentium does not pretend to cover every Unicode range--so another question is whether the software does a good job picking "the top-ranked font that the user possesses that provides coverage of all the characters needed here." As I said, my technical understanding of this is limited, though I can see what doesn't work for me. If there's another free font ranked ahead of Code2000, which I happen to lack, which does have proper display characteristics, then I'd love to install it. Within the ranges IPA, Greek, Euro-diacritics, Gentium is actually pretty popular. Wareh (talk) 15:56, 7 August 2010 (UTC) P.S. I found what looks like the font-list here, with a declaration it has been moved to commons.css (but I can't find it there). There is a complaint about Code2000 similar to mine there also (from years ago), with the false assurance that these selected fonts only apply to MSIE and not Firefox. The bottom line for me is that I wish my own font preferences wouldn't be touched at all. My computer and browser are typical of modern set-ups in being perfectly capable of displaying any conceivable character with my available fonts according to my preferences, without any guidance/overrides from the MediaWiki style sheet. Can I simply opt out of any MediaWiki font overrides? Wareh (talk) 16:19, 7 August 2010 (UTC)

I apologize for being so long-winded about my own needs. I managed to fix my problem by adding " .Unicode { font-family: 'Gentium', serif; }" to User:Wareh/monobook.css. The only defect here is that the transliteration should really be italicized, but I'll take that as a defect in Template:IAST, unless there is a way I can also give instructions to italicize anything with title="International Alphabet of Sanskrit Transliteration." Wareh (talk) 16:28, 7 August 2010 (UTC)

Move div.noarticletext to skins

The code discussed at MediaWiki talk:Common.css/Archive 12#Noarticletext should be moved into Monobook.css and Modern.css because all other skins do not have CSS for this class. — AlexSm 04:01, 6 September 2010 (UTC)

I'm not entirely clear on this. Are you saying that only the Monobook and the Modern skins have elements with the noarticletext class ? —TheDJ (talk • contribs) 11:58, 30 September 2010 (UTC)

Change to listenlist

{{edit protected}} Could a sysop replace http://upload.wikimedia.org/wikipedia/commons/thumb/a/a6/Gnome-speakernotes.png/30px-Gnome-speakernotes.png

with

http://upload.wikimedia.org/wikipedia/commons/3/3f/Gnome_speakernotes_30px.png

And also protect the new image? I've losslessly compressed it to save 101 bytes.Smallman12q (talk) 13:20, 8 September 2010 (UTC)

Think you will need a commons admin for that. Can you post the request on the commons talk page? — Martin (MSGJ · talk) 12:15, 10 September 2010 (UTC)

Done —TheDJ (talk • contribs) 11:56, 30 September 2010 (UTC)

External links proposal

• I've propose the contents of User:Gadget850/ExternalLinkIcons.css be added to MediaWiki:Common.css to supplement the existing PDF icon and identify other formats (namely doc, docx, xls, xlsx, rtf, and txt) that are not html.

To keep discussion centralised please comment at Wikipedia:Village pump (technical)#Proposal, Rambo's Revenge (talk) 11:51, 4 October 2010 (UTC)

Permalink: http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=389777733#Proposal --MZMcBride (talk) 22:15, 9 October 2010 (UTC)

Add -webkit-text-size-adjust: none; to MediaWiki:Handheld.css

Proposed: Add the following code to MediaWiki:Handheld.css in order to stop unwanted font size transformations on devices like the iPhone when the non-mobile site is used.

body {
    -webkit-text-size-adjust: none;
}

Thoughts? --MZMcBride (talk) 17:43, 9 October 2010 (UTC)

Unwanted font size transformation ? Can you describe that a bit more extensively ? I have no real objections, though I doubt that the iphone recognizes/uses the handheld media stylesheets, so it would have to be done using useragent detection and javascript instead. —TheDJ (talk • contribs) 18:58, 9 October 2010 (UTC)

I thought we had a "Mobile.css". If mobiles/handhelds aren't loading Handheld.css, that's a separate problem that definitely needs to be resolved.

I made a quick page showing the difference between the current code and the proposed code: http://pruebita.com/unwanted-text-transfrom.html

Let me know what you think. --MZMcBride (talk) 22:31, 9 October 2010 (UTC)

Oh my. Are you saying that text size on IPhone is bigger, and you want it reduced by default? Hell no! You are about to cause eye strain to readers. I'm not even mentioning readers with low vision and elders. Please read Wikipedia:WikiProject Usability/Readability guidelines, the first part concerning the text size. Bigger text size is one of the core techniques to improve readability.

In short, Apple and the IPhone are doing a great job usability-wise - and they are renown for it. Dodoïste (talk) 23:25, 9 October 2010 (UTC)

No.

There's a mobile site for a reason. People who want to use the regular site ought to see the regular site as it looks, without unexpected manipulation. Neither version is very readable without zooming. The difference is that one version doesn't have different font sizes that are the same size in almost every other browser.

If you look at the CSS that the mobile site uses (<http://en.m.wikipedia.org/stylesheets/webkit.css>), you'll notice it's using this code. There's no reason to not use it on the regular site. --MZMcBride (talk) 06:12, 10 October 2010 (UTC)

I know you guys love small text size. But there is one thing you don't realize: Wikipedia's default text size is way too small. Usability experts recommend a text size of 12 points (about 16 pixels) to ensure a good readability. For example, take a text with comfortable size (12 or 14 points) that is read by average users in 15 seconds. The same text in 10 points (Wikipedia is 9 points) is read in 27 seconds, per usability studies.

You are simply going to waste the time of readers by forcing them to zoom into the page more than needed.

Oh, and Wikipedia:WikiProject Usability/Progressive enhancement: DoWebsitesNeedToLookExactlyTheSameInEveryBrowser.com. Dodoïste (talk) 11:39, 10 October 2010 (UTC)

People who want no zoom and a larger font size should use the mobile site. People who want the regular site ought to see the regular site as it looks. I'm not sure what's confusing about this. --MZMcBride (talk) 20:26, 10 October 2010 (UTC)

Oh, upon examining further you screen shot, I finally understand. The issue is the font size adjustment is inconsistent; bigger here, and smaller the line afterward. OK, then. It really is an unwanted bug, I support this proposal. Sorry for all the fuss I made. :p Dodoïste (talk) 03:47, 11 October 2010 (UTC)

@MZMcBride, "If mobiles/handhelds aren't loading Handheld.css"; This is unfortunate yes, but the iPhone specifically chose to function as a "full capabilities" browser, instead of a "mobile device". Since then many have followed, largely rendering the whole "handheld" media set of the CSS standard useless. I don't see how we can do anything about that. jQuery does add CSS classes to the body i believe to identify browsers, I'm not sure if there is a dedicated iphone class that we use, but if there is, then that might avoid having to use Javascript. —TheDJ (talk • contribs) 12:30, 11 October 2010 (UTC)

body.iphone {
    -webkit-text-size-adjust: none;
}

I guess this could work. —TheDJ (talk • contribs) 21:23, 11 October 2010 (UTC)

I don't really have an objection to making it iPhone specific as long as class="iphone" is real and works. :-) I do wonder if other browsers support WebKit, though. --MZMcBride (talk) 23:54, 11 October 2010 (UTC)

I think that only on the iphone and android, the default value of this option deviates from normal. It seems there is no class for Android devices that is added by jquery. —TheDJ (talk • contribs) 18:55, 12 October 2010 (UTC)

some wikitable ideas

Hey. I've floated a few ideas on a number of talk pages and I'd like some feedback from the regulars here.

I know that wikitable went to shared.css, which is great, and what I'm taking about might be better discussed on whatever meta page goes with that. But I'm thinking that a trial here might precede that; talk first, of course. Below are some snippets. They arose out of discussions that are still underway regarding accessibility.

• Wikipedia talk:Manual of Style (accessibility)#How to make accessible tables and
• Wikipedia talk:WikiProject Discographies/style#Accessibility issues being the main ones.

/* existing: */
.wikitable th
{
 background: #f2f2f2;
 text-align: center;
}


/* new override: row-headers get left-aligned */
.wikitable th[scope=row]
{
 text-align: left;
}

/* new override: lists in data cells are always left-aligned */
.wikitable td ul,
.wikitable td ol,
.wikitable td dl
{
 text-align: left;
}

/* new explicit rule; most browsers do this for us */
.wikitable th
{
 font-weight: bold;
}

/* new explicit rule; but don't bold refs */
.wikitable th sup
{
 font-weight: normal;
}

If the new practice of scope-tagging row-headers sticks in the MOS, I believe the center-alignment will produce push back because many will not like the presentation applied to row headers; I expect the centering is primarily about targeting column headers, which are far more common. The paucity of row-headings is likely due to people not liking the current styling.

The DISCOG people like lists in data cells and lists really look terrible when not left aligned. This has resulted in huge amounts of align="left" getting baked into tables. User agents typically center table header cells, so we're getting that effect for the most part, already; I think we should make it explicit. The final snippet is a special case for refs that appear in headings; they're getting bolded and it is not a nice effect. FWIW, I'm not too keen on refs in headings, and things really get messy when there are sorting controls present, too. Comments?

Cheers, Jack Merridew 00:37, 15 August 2010 (UTC)

These are excellent ideas. Actually, I was just trying to get a template changed ({{infobox shopping mall}}) to be able to patch a few of these in an example at Central Plaza Latphrao, where centered lists are a mess. −Woodstone (talk) 03:59, 15 August 2010 (UTC)

Thanks. Changes such as this will have wide effect, and more than a few opinions will be needed before there's sufficient consensus to deploy something like this. I peeked at your links; first off, you should add {{edit protected}} to your post at Template talk:Infobox shopping mall, to get attention. It looked reasonable, to me. To get the lists in infoboxes doing the left-aligned thing would take code in the same vein as my examples above, but with 'infobox' in there. It would need a bit of looking into, which I'll try and get to tomorrow. Cheers, Jack Merridew 04:39, 15 August 2010 (UTC)

.wikitable th[scope=row] looks like CSS3. How is this going to render on older browsers? Happy‑melon 23:54, 15 August 2010 (UTC)

It is; an attribute selector. It should be fine in all but IE6; they'll get the row-headers centered, like we all are today; no biggie ;) Jack Merridew 03:04, 16 August 2010 (UTC)

I support this change. It's a nice attempt to reduce the reluctancy of users in producing accessible content. :-) And it would improve readability as well. Having a list of text in rows centered looks messy and unstructured, and is disturbing for the eye because the structure is not regular. Dodoïste (talk) 19:39, 29 September 2010 (UTC)

This is now live on fr.wiki. Dodoïste (talk) 22:20, 22 August 2010 (UTC)

By principle, I do not like code that behaves different in different browsers, especially when it can be done in code that all browsers understand. — Edokter • Talk • 21:39, 29 September 2010 (UTC)

Was I day-dreaming or were you the one who suggested all these CSS3 improvements at the village pump/technical today? ;-)

Web quality and accessibility experts agree that we should not hesitate to use this attribute because of a backward compatibility issue with IE6. It is used solely for a small layout change, and as such is negligible. It is important to ensure backward compatibility of the contents and functionalities. But ensuring backward compatibility for small layout enhancements is useless.

In this case, it cannot be "done in code that all browsers understand". Except for inline CSS but this is extremely suboptimal, from a performance point of view as well as from an editor point of view. As of now, users must repeat ! style="text-align:left;" at every row. Hey, the Usability initiative is trying to make it easier to edit by removing excessive code from articles (template folding), and we are only increasing the quantity of code we use? That just won't do. Even worse, users are now starting to use the deprecated align="left". Now which one is more important? Compatibility to IE6 who will eventually die sooner or later, or future-proof code? I'd say we should aim for future-proof code. Kind regards, Dodoïste (talk) 23:59, 29 September 2010 (UTC)

The new toys are a different matter; they are purely experimental. But we are dealing with tables, which is one element that needs backward compatibility in order to avoid unexpected relults in IE6 ("Why are my headers suddenly centered?"). Tables themselves are also regarded as prehistorically obsolete. A better solution would be to assign a class or id to row headers (this may require a small change in MediaWiki), so we don't need CSS3 selectors. — Edokter • Talk • 01:51, 30 September 2010 (UTC)

• Support, Jack (above) will tell you that him and I have discussed all of the issues in discogs to a horrifically bad extent LOL. It will defo reduce the objection of others in the project. I agree with all the comments about how centre aligned table lists look awful and because list tables are used everywhere on wikipedia it is a good change that will not hamper the accessibility changes. -- Lil_℧niquℇ №1 | talk2me 20:49, 29 September 2010 (UTC)
• Strongest Moderated support and something I hope will be urgently implemented, WP-wide, as music discographies (among other articles) could be moving along rapidly in this direction right away, if not too many people see the "ugly" centered vesion. And geez, I wish I'd realized this discussion was here earlier. Good work, Jack Merridew. Nice touch with the not-bold reflinks. — JohnFromPinckney (talk) 21:08, 29 September 2010 (UTC)

• Actually, we don't need to unbold <sup>; that would unbold all supped text. The .reference class already has has font-weight: normal; assigned. You won't see a bold reference anywhere, even in table headers. For that matter, we don't need to explicitely need to bold headers; they are already bold by default. — Edokter • Talk • 02:02, 30 September 2010 (UTC)

So if we had a column (or row) heading of "y=x^2π + C" (for some reason), the existing CSS leaves it bold (y=x^2π + C) by not setting any font-weight property on it, and the new CSS as currently shown and proposed above would de-bold the 2π (y=x^2π + C)? Meanwhile, superscripted ref links wouldn't be bold either way, as I understand you. My tests with the current code suggest I've got this right.

I have to upsize my text to detect the difference but it is there, and so it seems I was hasty in supporting the code as is. Maybe you can work out with Jack what situations or problems he was thinking of that requires the approach (and apparently, extra code) he used. I still strongly support the left-alignment-of row-headers-via-CSS idea, and I don't consider the use of CSS3 to be a problem. — JohnFromPinckney (talk) 05:04, 30 September 2010 (UTC)

You got it exactly right; we do not need to touch font-weight at all. I am still moderately opposed to use CSS3 if it can be achieved another way; it would be trivial to asign a class or id from within MediaWiki. — Edokter • Talk • 08:43, 30 September 2010 (UTC)

I agree concerning the wikitable sup, I didn't pay much attention to that. I just removed as it seems useless (but maybe Jack was thinking of a particular configuration (browser) where this was necessary?

Removed the th bold too, as it wasn't explained for which browsers it is necessary. Dodoïste (talk) 10:36, 30 September 2010 (UTC)

Please don't remove stuff from my posts; comments are appreciated. Anyway, the 'ref' rule was unnecessary; I'd been looking at a mock-up that had faked (bold) refs. Cheers, Jack Merridew 17:09, 5 November 2010 (UTC)

OK, can you take me through this again? After examining the proposed code again, I feel that all but the [scope=col] selector is redundant to existing behaviour. As I partly described above, reference tags are already unbolded in common.css, and we don't want all <sup> text unbolded. And since header cells are bold by default and data cells are left-aligned by default, I fail to see the purpose of declaring it all again. — Edokter • Talk • 09:22, 30 September 2010 (UTC)

I'll reply later concerning the [scope=col] selector (don't have time anymore) but you're missing the point. The point is to reduce the amount of code editors have to use. That's what CMS are for, we're doing the right thing here. Dodoïste (talk) 10:40, 30 September 2010 (UTC)

Edokter, if one runs through your text quickly, and speeds though your phrase "and since header cells are bold by default and data cells are left-aligned by default...", one might well miss an important part of the rationale (and maybe this is what you have done). It's true (AFAIK) that header cells are bold by default (and again, I don't know why Jack thought that specifying it was necessary).

But that only gets us halfway there. It's also true that data cells are left-aligned by default, but this is the other half of the problem: we're not talking about data cells. We're talking about facilitating the use of proper semantic markup in tables, where a row has a header cell (bold by default, as agreed). The default centering behavior for <th> row headers is what we're trying to twiddle, because the WP consensus (poorly represented though it may currently be) considers center-aligned row headings to look weird or ugly. And editors will resist/avoid using heading markup for row headings if it doesn't "look nice". But perhaps you already understood that, in which case, my apologies while you explain yourself to me again. — JohnFromPinckney (talk) 14:28, 30 September 2010 (UTC)

Thank you. I understand that aligning the text in row headers is the main problem. After having read up on [scope=row] specifications and CSS3 selectors, I do still have one question: If we include the .wikitable th[scope=row] selector here, do we not also need to manually put scope=row into every row header of every table in Wikipedia, thereby defeating the purpose of this proposal? Or is it the intention that Mediawiki automatically insert that into generated wikitables? If that is the case, what is the reasoning for using CSS3 selecrors over equally effective CSS2 cell IDs? — Edokter • Talk • 17:03, 30 September 2010 (UTC)

We're getting out of my area, but it was my understanding that, yes, scope="row" would be added (by hand, as I believe I took it) to every such cell. That sounds awful, to be sure, and it's not great, but very often it'd be replacing align=left or similar. As I understand it, the scope attribute tells UAs something important (useful for assistive technology, I think) whereas the align attribute just says "show it to the left". I believe some discussion touched on classes and as I recall, Jack Merridew had strong reasons for preferring the scope approach. However, I may very well have this backwards, and maybe Jack didn't passionately hate the idea of adding a new class to the CSS (and we'd still have to add them to all the wikitables); the best thing to do would be to invite Jack over to clear things up for us. Certainly my memory and understanding of these bits are rather foggy. — JohnFromPinckney (talk) 20:24, 30 September 2010 (UTC)

From the earlier discussions I've been able to locate here, mainly, Jack didn't have anything much against classes, he just seemed ready to select based on the scope attribute. And if we're adding scope anyway, it'd be extra work (and extra code) to add CSS classes in addition when we didn't have to. If IE6 shows centered row headings, then nothing's broken; table headings default to centered bold. IE6 users are lucky they see anything at all, sometimes, and in this case, they'd see all of the content, just slightly less attuned display-wise to that which we find most pleasing. — JohnFromPinckney (talk) 21:20, 30 September 2010 (UTC)

@Edokter: Aha, now I understand why you are confused. It's our fault as we assumed some information were already known (they are explained in the links at the top, but it's not enough apparently). So let's explain thoroughly.

Concerning table accessibility, headers must be marked manually as either row headers or column headers. As explained in the data tables tutorial I recently made according to W3C's WCAG 2.0 techniques. Sighted users can visually deduce from context which headers are supposed to be column headers or row headers. But a machine can't, thus blind users using a screen reader can't either and will have a hard time to navigate the data. And machines reusing the content will also have a hard time to associate cells to their headers.

Thus, this scope attribute is a semantic attribute that must be added manually. When CSS are disabled, the scope must still be there. Users must add row headers - ! scope="row" | - themselves, and they will do so only if the layout result is appropriate. Thus the CSS selector and the align left by default.

Now about the class or id idea. Adding manually a class to every row header would be adding extra code, and would not be significantly different to our current style="text-align:left;" or deprecated align="left". Actually, I really doubt any class could be shorter than the deprecated code.

Finally, about the MediaWiki solution. As previously said, MediaWiki isn't able to know when it should add a scope row attribute or not. But when the scope row is present, it could sure add a corresponding CSS class to left align it. But, that would pretty much mean "do it yourself, if you can change the MediaWiki core software". As you may now, developers have thier hands full now, and pretty much did not care about most of the accessibility bugs I have reported. Even when they were top priority. Now if you're confident you can manage to get a developer to work on it, that's fine. But it will be long before it's even deployed. It can be done instantly in this Common.css, and we need this layout as soon as possible. So I suggest to go for this .wikitable th[scope=row] at least temporarily, and when a developer makes the corresponding change to MediaWiki we will simply remove it in favor of MediaWiki.

Does this approach seems more sensible to you Edokter? Kind regards, Dodoïste (talk) 02:17, 1 October 2010 (UTC)

@Edokter: I just made a page to explain what progressive enhancement is, and why the fact that this layout doesn't work with IE is no problem. See Wikipedia:WikiProject Usability/Progressive enhancement. Dodoïste (talk) 17:28, 1 October 2010 (UTC)

• This change only facilitates how (marked) row headers look. It does not actually any effect screen readers. And since row headers must be marked manually, this change has very little impact. There are possibilities for MediaWiki to assign scopes and IDs, for example, every header followed by a data cell can be automatically marked a row header, and rows with no data cells should have their headers marked as column headers. If that were to happen, then this change would have more effect, and I would support it. But with this change alone, layout would behave inconsistently between tables that have their headers marked and those that haven't. I can't really support that. — Edokter • Talk • 11:44, 10 October 2010 (UTC)

  Noooo! You still don't understand this proposal! What am I going to do? Dodoïste (talk) 12:02, 10 October 2010 (UTC)

  I understand the effect of this change, and it is minimal. Adding the scope to the tables helps screen readers; that I understand. Adding this CSS changes the appearance on screen; I assume screen readers couldn't care less about alignment. If your goal is to promote the use of scope tags in tables, I believe that this change also has minimal impact. You need to sell the broad advantages of this proposal. — Edokter • Talk • 12:23, 10 October 2010 (UTC)

  I'm moving this discussion here, since the section below is supposed to be a summary.

  1. I already told you the scope attribute can only be added manually. If it could be automatized, screen reader software could do it themselves. You proposal to automatically marked headers looks good at a first glance. But it will be wrong in about 30% of the tables in Wikipedia (as I guess from my experience). For example, every collapsible table has a header at the top that is supposed to be a table caption. But in order for the script to work it must be a header instead. An automatized process would mark this header as a column header, but it's not a table header. And that's just one example, there are plenty of similar cases.
  2. "layout would behave inconsistently between tables that have their headers marked and those that haven't": yes, but rarely. Most existing row headers have style="text-align:left;" already. The issue is, most of the time editors are not making row headers.

  There are plenty of benefits from this change. But I can understand you consider them as negligible. I don't believe that meeting W3C's accessibility guidelines is trivial, though. How about you find any problems that this change would cause, instead? Dodoïste (talk) 18:03, 10 October 2010 (UTC)

• I need to make the point that providing a scope for table headers is an essential part of accessibility. There's nothing optional about that. To make tables as accessible as possible for visually-impaired readers, we need to mark up tables with both column and row headers as far as possible, as it enables a screen-reader to announce the column and row headers for each cell if the user chooses to navigate the table in a non-linear way. There's no problem with column headers, as editors will use '!' wikimarkup because they are used to it. It is not a difficult task (even automatable) to convert these to '! scope="col"' and no visual change occurs. However, the situation is different when we consider row headers. Most editors only see the first column as data, even though each cell in that column often actually represents a row header. To improve accessibility, we need to convert those 'td's to 'th's and give them the row scope; in other words, we want editors to write '! scope="row"', rather than '|' whenever it is semantically appropriate. But this also produces a visual change, the first column becomes centred, unlike the cells in the rest of the row, and many editors baulk at that change. It is that resistance to improving accessibility, which arises purely from an aesthetic viewpoint that is so difficult to overcome. By making the change to common.css to left align 'th[scope=row]' cells, we remove this obstacle at a stroke. There is no simpler and more efficient means of achieving this goal, and it is unfortunate that this much-needed change seems to be stalled. --RexxS (talk) 20:24, 10 October 2010 (UTC)

Summary of the proposals and request for comments

{{editprotected}} This proposal was refined through the discussion. This proposal seems almost consensual, since Edokter is the only one to oppose. 6 users support this proposal, and this proposal is much needed that the WikiProject discographies (and later on other projects, when they will try to improve their accessibility).

A few changes happened during the discussion, and the explanation of this proposal is dispatched here and there. So here is a summary.

The main proposal to left align row headers

Concerning table accessibility, headers must be marked manually as either row headers or column headers. As explained in the data tables tutorial I recently made according to W3C's WCAG 2.0 techniques. Sighted users can visually deduce from context which headers are supposed to be column headers or row headers. But a machine can't, thus blind users using a screen reader can't either and will have a hard time to navigate the data. And machines reusing the content will also have a hard time to associate cells to their headers.

So users must make row headers and mark them with scope="row". But row headers are centered by default, which makes them look messy. So users have to add extra code in every row header (style="text-align:left;") to have them left aligned. This makes the table more complicated to newbies and more complicated to produce. Thus, users are reluctant to make row headers. This proposal is about adding a single line of code into MediaWiki:Common.css that does the job for them.

This code works in every major browsers, except IE6. But it's not a problem since this is only a minor layout bonus: no lost of content or important info happens when this is not supported. IE6 users will simply have their row headers centered as they are now anyway. This proposal complies to the Progressive enhancement best practice.

As explained above, other solutions are either impossible or suboptimal. This one is very simple and much needed to encourage the users to improve accessibility. This proposal is much needed in a ongoing improvement of the accessibility of WP:DISCOG tables, and will be necessary when reaching to other projects.

/* row-headers get left-aligned */
.wikitable th[scope=row]
{
 text-align: left;
}

Dodoïste (talk) 17:17, 2 October 2010 (UTC)

Not done for now: I have disabled this request due to lack of consensus. While it is just one editor who is expressing concern about this change, Edokter does seem to have valid points which do not seem to have been fully addressed. As edits to this page cannot easily be reverted due to caching, we must be completely sure that all changes correct. Therefore I ask that you continue to discuss this issue and work around the issues. — Martin (MSGJ · talk) 17:38, 10 October 2010 (UTC)

Well, Edokter is mostly saying that this change could be achieved by other means. If it was right, I'd sure support his approach. But unfortunately, it's impossible. Dodoïste (talk) 18:03, 10 October 2010 (UTC)

• Request to reconsider – as I've outlined above, this change is sorely needed to encourage editors to mark up row headers as headers, and to overcome the resistance that is generated by the visual effect of so doing. I can see no compelling argument why this should not be implemented as the correct semantic markup is essential to improving accessibilty for visually-impaired users. I therefore desire to see this request re-enabled and carried out. --RexxS (talk) 20:29, 10 October 2010 (UTC)

If it's any help to see an example, I've created User:RexxS/Table headers to illustrate the problem we are continually encountering. --RexxS (talk) 21:44, 11 October 2010 (UTC)

• I support this change because it will make it easier for users to create accessible tables. Graham87 00:16, 11 October 2010 (UTC)
• I'm eagerly awaiting the implementation of this change so that work can begin on modifying tables to conform with WP:ACCESS and appropriate HTML mark-up. The delay here causes a delay in updating the tables, because the sudden appearance of bold centered labels when td cells are converted to th headings will doubtless cause great displeasure, which will surely be demonstrated by reversions and refusal to take on the change rationale or consider explanations about accessibilty, usability, etc. Please let's not delay further. — JohnFromPinckney (talk) 03:20, 11 October 2010 (UTC)
  • There is nothing here that is preventing users from updating the tables by adding a scope to existing headers. As for changing table cells to headers, well, that's a choice each editor has to make for him/herself; if explained properly, reverts should be minimal. However, common.css is not ment as an instrument to encourage or promote certain editing practices. While I see the pro's, this change needs a broad consensus. — Edokter • Talk • 22:22, 11 October 2010 (UTC)
    • Right, we can, right now, add the scope="col" to <th> column headings. I have started doing this already. So far (as I've noticed, anyway), nobody has reverted or removed this somewhat strange and unfamiliar addition. As for changing table cells to headers, well, that's just good common sense and how all Web sites on the planet should be coded. That one of the ten most-visited sites (based on the ease of editing by such smart people from all over the world) has incorrect mark-up is a large embarrassment. I know that other sites, including large and popular ones, often have inappropriate mark-up or invalid HTML or JavaScript errors or rely on colors or assume a certain window size or exhibit any of a zillion other dumb mistakes, but we don't have to do that. We can do it right, and this change is about making doing the right thing more attractive. — JohnFromPinckney (talk) 23:08, 11 October 2010 (UTC)
• I have no objection to this change. It isn't supported by IE6, but I think we about shelved supporting IE6 when it comes to such small visual glitches. As long as {{infobox}} continues to add text-align to each header cell, there is not really much of a problem in practice, even for IE6 users. —TheDJ (talk • contribs) 23:01, 11 October 2010 (UTC)

• (edit conflict) @Edokter: On the contrary, adding scope to 'td' is storing up problems for the future, since this is deprecated in HTML5. To ensure proper interoperability with screen-readers both 'th' and 'scope="row"' need to be enforced for row headers. That is not a choice that each editor is free to make, if we want to improve accessibility on Wikipedia. I frankly find it upsetting to hear that "if explained properly, reverts should be minimal"; that claim is simply untrue, as anyone who has been working to improve accessibility will testify. Common.css is meant to encourage good editing practices. When used to lessen the amount of inline styles hard-coded into pages, it also helps to minimise the learning curve for editors, and reduces the maintenance cost of Wikpedia's presentation. I've given an example of the problem at User:RexxS/Table headers, please feel free to add a third table to that page, using the markup you feel would meet the objections that are currently encountered, and we can compare your solution to the proposal here. --RexxS (talk) 23:18, 11 October 2010 (UTC)

• I never mentioned adding scopes to data cells. But anyway... this change is a simple cosmetic change that is only applied to row headers that have a scope tag added. While I don't mind adding a scope tag to tables (I even believe this can be done automatically), I do mind that this change introduces inconsistent behaviour between tables with and without the scope tags applied. I agree that left aligning text in row headers looks better, but it does go against default table behaviour, and is not relevant to screen readers, so the accessability argument is not really an issue here. This change also requires table documentation to have explicit information about the use of scopes, which also complicates matters for new editors. — Edokter • Talk • 00:16, 12 October 2010 (UTC)

• But the answer to inconsistent behaviour between row headers with and without the scope tags applied is to apply the scope tags! It's a job that needs to be done anyway, unless you think it it's acceptable to have a row header without a 'scope="row"'? If that's the case, it is very much an accessibility issue. The documentation is at WP:Manual of Style (accessibility)#Data tables and the tutorial is at WP:Manual of Style (accessibility)/Data tables tutorial (courtesy of Dodoïste's efforts). Has that answered your objections? --RexxS (talk) 00:51, 12 October 2010 (UTC)

• You know as well as I do that that is a near-impossible task; we have over three million articles, so this is by no means an easy feat. I already said I have no problem with the tags, but I do not see this change having a positive effect, only introducing inconsistent behaviour. This is better adressed with a fundamental solution, like having Mediawiki apply the scope tags on the fly. We could file a Bugzilla report, or head over to the test-wiki. Either way, I stand by my opinion that you are going about it the wrong way around; first make sure the scope is applied properly, then let's worry about the CSS. — Edokter • Talk • 11:39, 12 October 2010 (UTC)

• This is an improvement we do on the long run. Most users produce tables by copy-pasting those they have seen, or those they believe to be good examples. The key is to improve the guidelines, to reach key projects and featured articles. This scope tag is fairly easy to add, so it's OK. Users able to learn wiki syntax are able to learn that. We already reached this stage at fr.wiki, which is proof enough that it is feasible.
  The addition of the scope="col" can be automated on a per-project basis. For example, the discographies tables are consistent, so a bot could do it and we'll definitely try this approach. But in order to produce relevant row headers, the DISCOG tables must be restructured, so this can't be automated.
  Also, Template:Infobox artist discography is a good example of why we need to have the row headers left aligned by default before we start changing articles. The left cells are supposed to be row headers, but are cells because they are left aligned by default. I'll fix it soon, now that this request has been approved. Oh and having the styles in the style sheet is a good practice because it reduces bandwidth too. :-) Dodoïste (talk) 17:06, 12 October 2010 (UTC)

 Done. We seem to have consensus that this change is warranted. If a better solution turns up, we can modify this later. — Martin (MSGJ · talk) 12:11, 12 October 2010 (UTC)

Thanks MSGJ. :-) Dodoïste (talk) 17:06, 12 October 2010 (UTC)

The second proposal to left align lists in a table

The WP:DISCOG people like lists in data cells. Their cells have often centered text applied to the whole table, so the list get left aligned by default. And lists really look terrible when not left aligned. This has resulted in huge amounts of the deprecated align="left" getting baked into tables, instead of the longer but correct style="text-align:left;". There are similar other cases where cells are added manually these codes, which makes the table more complex, especially for newbies.

Not to mention it is suboptimal regarding bandwidth too because these styles are contained in every cell, instead of being once in MediaWiki:Common.css as proposed. This proposal seems consensual. It is about adding:

/* lists in data cells are always left-aligned */
.wikitable td ul,
.wikitable td ol,
.wikitable td dl
{
 text-align: left;
}

Dodoïste (talk) 16:59, 2 October 2010 (UTC)

• While technically sound, I cannot help but to think that this proposal only benefits one WikiProject, and then only to fix what I think is, in principle, bad use of table markup; it counteracts an action that should otherwise not have to be corrected, as data cells default to left-alligned text. However, I see the benefit and I won't object this change. — Edokter • Talk • 11:55, 10 October 2010 (UTC)
• Since there is virtually no case where a list inside a table cell should be anything other than left-aligned, then making it so implicitly can cause no harm. On the other hand, there are many examples of tables that are set to display data centred, which is often bad markup, but this is then compounded by use of inline styles on cells containing lists in order to left-align them again. This change, while not eliminating poor markup, at least mitigates some of the consequences. I support it --RexxS (talk) 20:37, 10 October 2010 (UTC)
• I don't see that this benefits only one WikiProject (and Edokter didn't say which one), but it seems like it would benefit all WikiProjects as well as the spaces in between projects. It's hard to imagine when bulleted list items in a table wouldn't be better left-aligned. — JohnFromPinckney (talk) 03:25, 11 October 2010 (UTC)

 Added — Martin (MSGJ · talk) 12:14, 12 October 2010 (UTC)

Latin Sanskrit and "Unicode" class font selection in MediaWiki:Common.css/WinFixes.css

{{editprotected}} I've been bothered by the font selection for IAST Sanskrit transliteration, chosen by Template:IAST. It looks like it isn't defaulting to something that is totally unreadable and hideous anymore, but the selection of "Free Serif" as a top choice is troubling. I have been working with web design that involves Sanskrit transliteration, and I spent a fair amount of time digging through fonts and CSS settings, finding exactly which fonts can support it, and will render well on Windows (and Mac OS X and Linux too, for that matter). Now today I finally dug into the matter and inspected the CSS being applied to the IAST template, using the Firebug add-on in Firefox. The exact CSS class that chooses these fonts is part of a Windows-specific CSS file: MediaWiki:Common.css/WinFixes.css, and in here it is the "Unicode" class. I am proposing the following change to the "Unicode" class in this file, which I will explain.

.Unicode {
    font-family: "Microsoft Sans Serif", "Arial Unicode MS", "Free Sans",
                 "Gentium Basic", "Gentium", "GentiumAlt", "DejaVu Sans",
                 "DejaVu Serif", "Free Serif", "TITUS Cyberbit Basic",
                 "Bitstream Cyberbit", "Bitstream CyberBase", "Doulos SIL",
                 "Code2000", "Code2001";
    font-size-adjust: 0.54;
}

Arial Unicode MS and Microsoft Sans Serif are probably the best available fonts widely available on Windows for this Unicode class. They harmonize with the default Arial font, and they are both very full-featured. Neither has a real oblique or italic, but the faked oblique is legible and clear. Most importantly, Arial Unicode MS is installed on every system with MS Office, and Microsoft Sans Serif is installed on every Windows system, at least since Windows XP. Free Sans is a similarly good font in the same exact style as the other two, also full-featured, albeit with less hinting. The rest go on to Gentium and the DejaVu fonts, which are each good in their own right and Open Source, and can display acceptably, but are not well hinted. Then come the other Unicode fonts that are in general a bit ugly, but can cover a larger range than some of the other Unicode fonts. Therefore, everything goes by aesthetics and functionality, generally from better to worse.

The second line is very important, which is a CSS font-size-adjust directive. Without this directive, fonts such as Gentium and FreeSerif will appear too small to be legible. This is because fonts display at very different sizes even if the point size is calculated the same. This is due to the difference in x-height and the general difference in metrics between fonts. This can be very pronounced between sans-serif and serif faces. Without this directive, a serif fallback such as Gentium, Free Serif, or one of the others, would be too small to be legible. This is currently happening with the "Unicode" class when it falls back to Free Serif, which is one of the current top choices. Adding this directive will fix the problem. The setting of 0.54 is tuned for the top choices and tested in the major browsers, so they will display at sizes that are even with the rest of the text.

Those are my two rationales for the changes to the "Unicode" class in MediaWiki:Common.css/WinFixes.css. If an administrator could help make that change to the page, it would be much appreciated. Tengu800 (talk) 01:58, 24 August 2010 (UTC)

I have already achieved a private solution with this edit to my style sheet, but I strongly support anything that will demote Code2000 in the font selection order for all users to its rightful position (an emergency fall-back), and I gather that Free Serif should be treated the same way. As Tengu has said on another talk page, if you don't have these fonts (with all their display problems) installed, you can't appreciate how inappropriate it is to have them in the senior position on the font list. Wareh (talk) 13:59, 24 August 2010 (UTC)

I point out that Arial Unicode MS apparently has a lot of issues with IPA characters for instance. It is not as capable as some might think. The problems with Ariel Unicode MS was actually one of the reasons some of these classes were created apparently. I think we need to consider this a bit longer and discuss and test it some more. —TheDJ (talk • contribs) 21:21, 30 August 2010 (UTC)

Isn't IPA already handled by a separate "IPA" class rather than the "Unicode" class? In articles using IPA, I get Gentium (IPA), and in articles using IAST, I get Free Serif. If so, then Arial Unicode MS and IPA would not actually be a problem. (MediaWiki:Common.css/WinFixes.css) Tengu800 (talk) 15:10, 31 August 2010 (UTC)

Are there any objections to this request? — Martin (MSGJ · talk) 11:32, 9 September 2010 (UTC)

 Done — Martin (MSGJ · talk) 12:05, 10 September 2010 (UTC)

{{rfctag|policy}}

When it comes to choosing the font that most widely support unicode, the default font should be set for Arial Unicode MS. It has tenfold more glyphs then Microsoft Sans Serif, which is basically a replacement for MS Sans Serif, and not very geared toward universal unicode; it is actually missing several key geometric shapes, which becomes appearent in Google Chrome (IE and Firefox revert to the next available font). So I propose swapping the two fonts. — Edokter • Talk • 20:58, 31 October 2010 (UTC)

.Unicode {
    font-family: "Arial Unicode MS", "Microsoft Sans Serif", "Free Sans",
                 "Gentium Basic", "Gentium", "GentiumAlt", "DejaVu Sans",
                 "DejaVu Serif", "Free Serif", "TITUS Cyberbit Basic",
                 "Bitstream Cyberbit", "Bitstream CyberBase", "Doulos SIL",
                 "Code2000", "Code2001";
    font-size-adjust: 0.54;
}

Since there have been no comments for a week, i have implemented the change. — Edokter • Talk • 17:16, 7 November 2010 (UTC)

Styles for unbulleted lists

Can we move the in-line styles from {{Unbulleted list}} to the main stylesheet? The current markup is:

<ul style="list-style:none none; padding:0px; margin:0px">

I propose to change that to

<ul class="unbulleted-list">

or, if a shorter name is needed, class="ublist".

This template is used (primarily in infoboxes) to create lists such as:

• cat
• dog
• mouse

using the correct HTML list mark-up, currently:

<ul style="list-style: none outside none; padding: 0px; margin: 0px;">
<li>cat</li>
<li>dog</li>
<li>mouse</li>
</ul>

with styles to hide the bullets, replacing the common but unsemantic markup:

cat<br />
dog<br />
mouse<br />

It will be increasingly and very widely deployed; often multiple times on one page. It's also intended that the style should be available to other templates, not necessarily by calling this one. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:46, 16 August 2010 (UTC)

I'm not familiar with en.wiki yet so I'd like to see some examples where this unsemantic markup can be found. If it's in templates, it's fine. If it's in articles I'm hesitating because it would be best to avoid uses of complicated HTML-like syntax in articles. For simplicity's sake.

I support the principle of this proposal as it would improve accessibility.

I'd rather see an implementation of display: inline; to produce more semantic and accessible list in Navboxs. Like ul#inline li { display: inline; }. Yours, Dodoïste (talk) 20:01, 16 August 2010 (UTC)

A great many infoboxes have the unsemantic markup. Look at the template's "what links here", then find the versions of the article before the edit where the template was deployed. But here's one; see |primeminister= and |party= in the Infobox on Charles de Gaulle. I created {{Flatlist}} and its class="horizontal" some time ago, for your other use-case. It still needs a little polishing. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:03, 16 August 2010 (UTC)

Then, I agree if it's meant to be used in the said templates (as opposed to articles). :-) Dodoïste (talk) 19:54, 30 September 2010 (UTC)

Technology wise the styling is acceptable, since it is supported by all major browsers for ages [13]. My one problem is that mixed usage of ul and * is not possible with mediawiki, which is why I'd rather see this behavior limited to templates, and i'm not sure if having more than one template for this behavior is useful. But it's not really a dealbreaker for me. I would like to see more opinions however on that one. —TheDJ (talk • contribs) 20:44, 16 August 2010 (UTC)

The class will be needed, for example, where the functionality is hard-coded in, say, infoboxes, rather than calling {{Unbulleted list}}. Noone is proposing "mixed usage of ul and *". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:03, 16 August 2010 (UTC)

I'm not saying that is the proposed usage, i'm just being careful, because adding stuff like this usually ends with people using it in unexpected and unintended ways. —TheDJ (talk • contribs) 23:40, 16 August 2010 (UTC)

So how do we actually make this happen. Is there an equivalent of {{Editprotected}}? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:18, 21 August 2010 (UTC)

Where were we on this guys ? all issues solved ? What name should we pick for the class ? I personally favor a more descriptive name like: "unbulleted-list" —TheDJ (talk • contribs) 12:01, 30 September 2010 (UTC)

I don't see any outstanding issues listed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:59, 9 November 2010 (UTC)

I'm not entirely convinced of the advantages of creating a class here; the ammount of data saved is minimal, and I can only see use for templates, short of using HTML in the article itself. An "unbulleted list" does not even exist as such in HTML. Only if more templates would use this class would inclusion be justified, but that is not the case yet. So I propose we let it stay in the template for now, and if more templates start using this markup, then we can reconsider. — Edokter • Talk • 17:28, 30 September 2010 (UTC)

It's always preferable to have styles in CSS rather than inline. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:59, 9 November 2010 (UTC)

That entirely depends on the scale of use. There is no inherent advantage to using CSS over inline, other then centralizing the CSS code. That's why I proposed evaluating it's use first before putting it in common.css. — Edokter • Talk • 17:23, 9 November 2010 (UTC)

Bold row headers

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

I feel that it would be better that table row headers did not display in bold on Wikipedia and that we should impose normal font weight. This overwhelms the lists it has been used on, such as on Fantasia Barrino discography. I am not aware of the reasoning behind the use of bold in row headers, but would be keen to find out. The Rambling Man (talk) 15:34, 4 November 2010 (UTC)

Some reasoning: I believe table headers have been presented as bold by graphical browsers since they were implemented in 1994 or thereabouts. Presenting headers in some unexpected way would be like restyling hyperlinks to not be blue and underlined; they can still be used, but first you have to figure out how this site does it. It slows people down, the opposite of accessibility. — JohnFromPinckney (talk) 16:08, 4 November 2010 (UTC)

Column headings (let's use a language I understand) have been in bold forever and a day, and that's logical (and commonplace) while row headings have suddenly become bold. This may not have happened overnight, but suddenly the featured list community are being presented with lists with stacks of bold and not much else. This may be accessible to some, but I suggest it has become a lot less accessible to the majority. The Rambling Man (talk) 16:11, 4 November 2010 (UTC)

1. There is a confusion about the word "accessibility" that we need to address. See the introduction Wikipedia:WikiProject Accessibility/What is accessibility? Accessibility in this context means that people with disabilities and elders can use the website.

2. The bolding itself is useless to meet accessibility standards. Only the "! scope="row" |" is necessary. Headers a simply bolded by default by browsers, as it was already explained.

3. The bolding of row headers may appear ugly, confusing, or reduce usability. I believe it's only a matter of time, until you get used to it. But anyway, it won't reduce your accessibility to the tables, as you can still use the tables.

4. Usability-wise, it can be argued that bolding row headers can make people more efficient in using the table. And that's what JohnFromPinckney meant. As a member of the usability project, I can tell it does. Bolding the important keywords is common practice. And regarding a table, the headers are the structure of the table. When row headers are bolded, you can see immediately the row headers, and understand that cells on the same line corresponds to this header. It makes you more efficient when using the table.

Concerning the fact that you are not used to this new layout, I suggest that you don't rush things and wait for a while. You'll probably get used to it, and see things differently. It's not the end of the earth, it's just a little bit of bolding, come on! It's not worth such a lengthy debate, on my opinion. ;-) Kind regards, Dodoïste (talk) 16:38, 4 November 2010 (UTC)

1. I understand what accessibility means, thanks.

2. Rows should not be bold, it looks awful, and doesn't make any sense.

3. It reduces my accessibility because I find it much harder to read. Especially since you appear to rely on the keyword being bold. See below...

4. So you're now going to reorganise lists so keywords must come first? Look at List of Knight's Cross of the Iron Cross with Oak Leaves recipients: 1942, Grammy Award for Best Polka Album, 1994 College Baseball All-America Team etc, all current FLCs, none of their "keywords" are in the first column. And look at the mess that is now Rihanna discography#Music videos which was re-organised to fit in with ACCESS, making it much less accessible to all.

I don't appreciate the patronising tone. It's not that I'm "not used to this new layout", it's that it looks poor, appears to have been "agreed" without any discussion with the list community and is clearly flawed.

1. Well then, if you do understand the meaning of "accessibility", use it correctly in order to prevent misuses and confusions. Don't say that bolding title makes it less accessible for people without disabilities, it's nonsense.

It makes the table less clear to read to someone without disability. Is that clear enough? The Rambling Man (talk) 18:25, 4 November 2010 (UTC)

2. That's way too simple. "It doesn't fit my personal taste". First, we have to see if there is any consensus about this. If most users agree that row headers should not be bolded, OK. But we won't change the whole website according to your personal taste.

Not my personal tastes, there are a number of editors who have said that this change is unacceptable. It needs to be discussed centrally. The Rambling Man (talk) 18:25, 4 November 2010 (UTC)

3. Just like I said, you mean "usability", or rather "readability". Completely different.

No, not readability. I find it difficult to access information now tables have been re-organised and text has been modified per this "update". The Rambling Man (talk) 18:25, 4 November 2010 (UTC)

4. I was just giving an advice from a usability point of view. Nothing else.

So please comment on those FLCs. The Rambling Man (talk) 18:25, 4 November 2010 (UTC)

You know, your reaction is absolutely typical of the end-user. You see a slight change that you don't like, so you're going to shout it everywhere and make a huge mess. Just for a slight layout change. It's just like with the Vector theme. Users got all heated-up for a while, and now they have either accepted it or are strongly attached to it. That's normal, it's part of the life of a website to evolve.

And please stop replying in the middle of my reply. I used numbers especially to improve readability. And you're just breaking it in pieces. Dodoïste (talk) 18:19, 4 November 2010 (UTC)

I get all "heated-up" when changes occur without involving key stakeholders one bit. You need to involve the people who this affects the most, that's people at WP:FLC. You know that, and it must be embarrassing now to realise that you haven't. We tried to evolve with WP:ALT and look where that took us. You want us to "buy in" to your ideas? Then involve us. It's pretty simple. And I reply, like everyone else here, inline, with direct answers to your direct points. Cheers. The Rambling Man (talk) 18:25, 4 November 2010 (UTC)

• I think that The Rambling Man has a legitimate concern, albeit an aesthetic one. But that's what style is about, isn't it? There is no doubt that to maximise accessibility for visually-impaired users, most (but perhaps not all) data tables that previously had no row headers need to have them. We have already agreed that this change would have less stylistic impact if row headers remained left-aligned – .wikitable th[scope=row] {text-align: left;}. The Rambling Man is only asking that the same consideration be given to removing the stylistic impact of the bolding; in other words, could we add: .wikitable th[scope=row] {text-weight: normal;}. I think it is worthy of proper discussion here, as it would resolve multiple concerns at FLC, but obviously we need to take into consideration its potential impact in other areas of the project. --RexxS (talk) 17:59, 4 November 2010 (UTC)
• At the moment, we're not specifying normal or bold for table header cells; we're all getting bold from our browser defaults:

th
{
 display: table-cell;
 font-weight: bold;
 padding: 1px;
 vertical-align: inherit;
}

• That's Firefox html.css↑
• This is bog-standard behaviour in html. We need to determine when we wish to explicitly set bold and when we should deviate from that. Semantically, row headers should often be used. We might consider rules that typically set bold but omit it when italics have been specified. Jack Merridew 21:48, 4 November 2010 (UTC)

Hello Jack, thanks for that. I'm trying to understand why, suddenly, there's a push to bold everything in column one of a table (that's in "simple speak"). It's causing issues, and I'd like to see the justification for it. As of a few days ago, this didn't happen, nor did it seem to need to happen. However, things appear to have changed and featured content is being modified to reflect this "new style". I want to know why, how, etc! Cheers! The Rambling Man (talk) 21:53, 4 November 2010 (UTC)

It's not a push to bold col-one, it's an effort to use header syntax (!) in col-one where it is semantically appropriate, which it often is. Because we're 'neutral' on font-weight on headers, we're getting the html-standard styling: bold. There's long been a pattern of editors avoiding the header syntax where it is appropriate because they're put-off by the bold headers entail. What should come out of this, is that an explicit specification of bold be added to common.css (and then pushed towards shared.css). Additionally, rules for a few exceptions can be devised, such as not bolding when italics were given in the wiki-text. Editors should be encouraged to use row-header syntax where it is appropriate. nb: about the same sort of thing happened recently re centering header cells (a recent change to common.css). In the Fantasia Barrino discography page, the bold-italic is explicit with five apostrophes, not the general cases out there. Cheers, Jack Merridew 22:34, 4 November 2010 (UTC)

Ok, I sort of get it. However, we need to know more about this at WP:FLC if it's a mandate via MOS. Would appreciate some technical advice, if required, at the centralised discussion at WT:FLC. Cheers! The Rambling Man (talk) 22:37, 4 November 2010 (UTC)

I've attempted to start a centralised discussion here. Thanks. The Rambling Man (talk) 19:03, 4 November 2010 (UTC)

Solution

We can't just change the bolding of row column headers to non-bold. There are probably many tables that depend on this. The problem here is that ACCESS team is adding header fields to tables for the sake of semantics and not for visual effect. As such our current visual effect for such headers is applied, while that is not really appropriate. Suggest adding adding a new class.

table.wikilist th[scope=row] {
 background: #F9F9F9;
 font-weight: normal;
 text-align: left;
}

This would give you "plain layout" when you use class="wikitable wikilist", while still being semantically correct for screenreaders. —TheDJ (talk • contribs) 23:10, 4 November 2010 (UTC)

I believe it is the best solution. I does not break the cases where row headers may be purposefully bold (I haven't yet seen about such a case, but there are way too many different tables to know).

Since it will be only used by several featured lists in the upcoming weeks, it is the appropriate solution to get feedback on the use of this class. This feedback will indicate if we need to extend this layout to all wikitables, or not. Yours, Dodoïste (talk) 23:29, 4 November 2010 (UTC)

The only problem I foresee is that some editors want to have the cell that is the natural row header in the second (or later) column. There is no accessibility bar to doing this, and I'd rather accommodate them, than argue for the row header to be the first column. Therefore setting the grey background (which is #F2F2F2 for a wikitable, I believe?) would create the odd effect of an interior column having the background. It may therefore be better to forego the background for row headers and use:

table.wikilist th[scope=row] {
 background: transparent;
 font-weight: normal;
}

Thoughts? --RexxS (talk) 23:43, 4 November 2010 (UTC)

Making it transparent should be fine i guess.. —TheDJ (talk • contribs) 23:44, 4 November 2010 (UTC)

Apologies, I was confusing #F2F2F2 which is the wikitable header background, with #F9F9F9 which is the wikitable cell background. Most of what I said above doesn't apply. Although, having a transparent background for the proposed wikilist class would allow us to use it with tables that are not wikitables as well, if needed. --RexxS (talk) 23:59, 4 November 2010 (UTC)

OK. I only hope the presence of row headers in the second column (or various places) won't confuse editors about how they should mark row headers. For example, in discographies conform to the old style, we have two cases. Some cells at the second position have content that can be used as a table header, like the singles and music videos tables: "So Yesterday" is a good example. But others are far too long to be a header: "The Lizzie McGuire Movie * Released: April 22, 200 * Label: Walt Disney * Formats: CD, digital download". These tables should be restructured anyway.

OK, but we must be careful and watch what users are doing with row headers. Since this extends to the featured lists, we can observe and see if it works. Yours, Dodoïste (talk) 00:11, 5 November 2010 (UTC)

So, if for some reason an editor wants bold row headings, the three possibilities are:

1. use th (!) mark-up, but omit the scope="row" that we're supposed to be adding; or
2. use th (!scope="row"), which we've cranked down to normal weight, and add ''' to add bold mark-up on the header cell contents (assuming that'll work, of which I'm not sure); or
3. not use a wikitable at all.

Is that what we want? Also, how does this play on non-CSS3 browsers? — JohnFromPinckney (talk) 00:33, 5 November 2010 (UTC)

Incorrect. If you want bold row headers, you use "wikitable". If you DONT want bold row headers, you use "wikitable wikilist". And this isn't CSS3, it's plain CSS2. Only IE6 and lower don't support attribute selectors. —TheDJ (talk • contribs) 00:43, 5 November 2010 (UTC)

Okay. And because .wikitable already has text-align:left; we'll get left-aligned row headers in either case. — JohnFromPinckney (talk) 02:54, 5 November 2010 (UTC)

Actually, text-align for this case should probably be reset to "inherit". So final code proposal:

.wikilist th[scope=row] {
 background: transparent;
 font-weight: normal;
 text-align: inherit;
}

—TheDJ (talk • contribs) 03:44, 5 November 2010 (UTC)

I just tested it, and using it in a table with class="wikitable wikilist" it appeared to have centered the row headers. Is it intentional? I understand the need to have a different layout for row headers. But in this case I'd rather keep the gray background, since the centered header is strongly disliked by the community. Yours, Dodoïste (talk) 19:04, 5 November 2010 (UTC)

That's because your own vector.css overrides the common.css declaration that left-aligns text on th[scope=row] for a wikitable (the one we argued for above). In other words 'inherit' does not mean it takes its value from an overridden declaration. You just leave it out if you don't want it to override anything. It would be the same if that line were added to common.css, as then we'd be defining text-align on th[scope=row] twice – once for .wikitable and once for .wikilist, and the last one we use wins! If we want normal weight and normal background, just declare those; text-align is already defined for a wikitable. --RexxS (talk) 23:41, 5 November 2010 (UTC)

Solution 2 edit-point-Merridew

This began months ago. I began experimenting with more explicit row headers (!) in things like filmography tables and Dodoïste began advocating explicit scope attributes in table header-cells. This all kicked-up some dust when Kelly Rowland discography became a FLC. The WP:DISCOG crowd's style-guidance was sharply at odds with the MOS, and the proposals above at #some wikitable ideas emerged in my talks with them.

I'm not keen for the "wikilist" solution. First, the name is poor; that should be for the list elements, such as OL, UL, DL. Second, it amounts to a purely presentational option, a fork of our table-styling. The word 'list' would seem to be simply an artifact of where the fuss originates. If this route is pursued, name it 'plain'. Consider the following rule to simply force normal weight for scope-tagged row headers:

/* row-headers get normal-weight */
.wikitable th[scope=row]
{
 font-weight: normal;
}

or the following to de-bold when someone's explicitly italicized the contents of a scope-tagged row header:

/* row-headers get normal-weight when italics on-offer */
.wikitable th[scope=row] i
{
 font-weight: normal;
}

These won't sort all cases, notably the quoted-but-not-italic stuff at: Rihanna discography#Studio albums and Fantasia Barrino discography#Singles. In the above #some wikitable ideas thread, Edokter had some valid concerns about the futility of attempting to hard-code millions of pages with proper scope attributes. The approach of having them generated needs to be explored as it is the only way to get consistency. This may even entail a tweak to our wiki-text syntax for table. Cheers, Jack Merridew 18:24, 5 November 2010 (UTC)

In cases where tables are consistent, like discographies, a bot could be used to add the scope tag. And several template-based tables can easily be updated. Anyway, we're not in a hurry, and this accessibility improvement may take years to reach completion and it's OK.

As for generating them automatically through the wiki parser, it is impossible. The scope tag is necessary because the structure of the table cannot be programmatically detected without it. Dodoïste (talk) 19:04, 5 November 2010 (UTC)

bots and templates and time are certainly in this. tbd.

a few simple rules could generate most (but not all) scope attributes: first row all header cells? They all get scope="col". First cell in a row a th while all subsequent cells are tds? It gets a scope="row". Anything else gets tagged for review as a semantically suspect table structure. Anyway, this fuss is a result of efforts in one domain coming as a surprise to those focused on other areas. Rules implemented here need to be general in nature (ok, 'common' in nature), of wide applicability, and not rock too many boats. Leaky boats, like IE6, should be allowed to founder in peace. Cheers, Jack Merridew 19:17, 5 November 2010 (UTC)

If you are thinking that a bot would do the changes you are mentioning, sure, it looks fine. Well, adding scope="col" to table headers is absolutely consensual, so we could go with this first. Yours, Dodoïste (talk) 21:32, 5 November 2010 (UTC)

I'm saying that MediaWiki should be able to generate most of these per such rules; generated on-the-fly, not embedded in wiki-text — by either editors or bots. A scheme of manually adding them will never result in a significant percentage of table headers having scope specified; that's simply not how wiki-editors do things: most will simply never read any guidance or care. And any such code-generation should defer to explicit scopes given in the wiki-text, so overrides may occur.

Most headers should be bold; h1-h6, table-header-cells (&&captions), DT (';'), as this is bedrock of the way the net is. We can make exceptions where a good rationale exists, but they should be limited and not catering to specific groups of articles, such as discographies (or filmographies). Much of this mess could be sorted by making some of these "lists" actually *be* lists, not tables. Jack Merridew 22:00, 5 November 2010 (UTC)

Problem is, if a bot makes a mistake, it's easy to notice and fix. If the parser is wrong, who is going to notice? A handful of tech guys too busy to check most articles? It would only worsen the current situation. Dodoïste (talk) 22:10, 5 November 2010 (UTC)

I'll await Edokter's take on this. Jack Merridew 22:30, 5 November 2010 (UTC)

I'm still not a fan of 'breaking' standard table behaviour, but if there would be consensus on formatting row headers this way, the parser would be equally accurate as any bot. A simple rule that adds 'scope=row' to every first header followed by a cell should be adequate. Any tables that deviate are probably intended to deviate. And the remaining errors should be spotted and fixed by the people that watch the articles. And like I said below, only the font should be changed; the background should remain the same. However, I strongly favor a manual methodology and we experiment first; I don't foresee a consensus building any time soon to blanket-apply this styling to every table on Wikipedia just yet. — Edokter • Talk • 13:45, 6 November 2010 (UTC)

This does need to be pushed at the devs for their consideration; as-is, the scope="row" is being rote-pasted into a lot of pages, which is part of what his piqued The Rambling Man's and others' interest (putting it mildly;). I'm also seeing explicit bolding being done in some of the disco pages. This was all shoved into the accessibility pages with little discussion. Ultimately, we are going to have scope specified on damn-near all td-elements (!), but I believe we don't want them in the wiki-text; i.e. MediaWiki should generate them. Jack Merridew 00:49, 7 November 2010 (UTC)

Yes it is purely presentational, as that is where the disagreement comes from. We are building lists formatted as tables. And while I agree that rows should have a key, that does not mean that you'd want that key bolded and with a darker background on all 250 rows of the list. That's simply not pretty, and doesn't aid anything. On the other hand there are people relying on the DEFAULT behavior of table headers in rows being bold etc already, so we cannot change that. Changing it for "just" the scope row case seems rather confusing to me. Thus splitting the visual layout seems like the best option to me. If someone has a better name than wikilist, I'm all for it, but I like it just fine. A list is a list, be it formatted using a table or with list elements as far as i'm concerned. We don't have Wikipedia:Featured tables. —TheDJ (talk • contribs) 01:16, 6 November 2010 (UTC)

The thing, is, it is the bold and darker background that is indicating that the cell *is* a header (or primary-key). This is ages-old and I'm sure there are plenty of tables it's working just fine for: multiplication table, for example. FWIW, I believe the centering was originally intended to specifically target the column-headers and that row-headers were not much considered. But the bold and background is an appropriate way to style the row-headers so that readers have an indication that the left-column cells are special (are headers, keys). Of the two examples I gave, I'm strongly leaning towards only the italic-in-lieu-of-bold rule, and only used the scope attribute selector to keep from targeting the col-headers. Purely presentational classes are, as I expect you know, usually quite inappropriate. Might as well have a class="blueText". Classes should have non-presentation rationale; what's different about these tables compared to other tables? Cheers, Jack Merridew 01:49, 6 November 2010 (UTC)

I'm completely baffled (and not for the first time in my life) about the use of italicization as a criterion for non-bolding headings. What do italics have to do with anything? — JohnFromPinckney (talk) 02:24, 6 November 2010 (UTC)

It's just an example; the idea was to drop one inherited style (bold) when another was explicitly specified (italic). The first example was just to show how to drop all the bold, which TheDJ pointed out, is likely to cause problems in some cases, such as multiplication table. Jack Merridew 00:49, 7 November 2010 (UTC)

• This was not intended as a 'solution', just some options ;) Jack Merridew 16:17, 7 November 2010 (UTC)

Solution 3

I have to agree with TheDJ here, in that the majority of editors expect to see behaviour that is inherent to tables. I still believe that forcing all row headers to show as plain by default is not the way to go. I do however like the idea of adding a seperate class for those that want plain row headers, but .wikilist is a poor name. Instead, the name should convey it's function, so I propose it would be called .plainrowheaders, which gives row headers normal weight and left-aligned text. But I do recommend leaving the original header background color, so it remains recognizable as a header. This gives editors a choice on how to format their row headers, without forcing others to work with semantically-incorrect behaving headers with regards to styling. So this would be my proposed code:

/* Normal font styling for table row headers with scope="row" tag */
.plainrowheaders th[scope=row] {
  font-weight: normal;
  text-align: left;
}

— Edokter • Talk • 13:31, 6 November 2010 (UTC)

I support Edokter's proposal. :-) Dodoïste (talk) 13:37, 6 November 2010 (UTC)

I see that dropping all bold in row-headers will cause problems, and just explained the italic idea to JohnFromPinckney, just below. Edokter's css is better; the name and the keeping of the background-color. I am still hopeful that a more focused set of rules can be devised that will sort this without the need for a presentational fork. If something like the above *is* used, then the code added a while back should be re-considered:

/* row-headers get left-aligned */
.wikitable th[scope=row] {
    text-align: left;
}

Cheers, Jack Merridew 00:49, 7 November 2010 (UTC)

I should have mentioned that if my code example is used, it is intended to replace the current code. — Edokter • Talk • 10:51, 7 November 2010 (UTC)

I support the proposal of Edoktor. —TheDJ (talk • contribs) 12:34, 7 November 2010 (UTC)

I support Edoktor's proposal. It would be more intuitive for editors to use. --RexxS (talk) 13:28, 7 November 2010 (UTC)

I wonder, would it be impertinent of me to ask how this works for "regular" list editors? In other words, to suppress the bold row headers, what would I need to do? The Rambling Man (talk) 13:49, 7 November 2010 (UTC)

Two things need to be added:

1. Add plainrowheaders to the table class.
2. Add scope="row" to the row headers.

If any of the two are omitted, the row headers retain their normal, bold and centered look. — Edokter • Talk • 14:00, 7 November 2010 (UTC)

I see, that's pretty straightforward, thanks to you, and the other contributors to this discussion, for all your efforts to accommodate everyone. The Rambling Man (talk) 14:09, 7 November 2010 (UTC)

It does presuppose, however, that the table row headers have already been identified by replacing '|' with '!' for the appropriate cells. Regular list editors will often have to carry out that step first (or in conjunction with the above) for many tables. --RexxS (talk) 15:57, 7 November 2010 (UTC)

Give it a whirl; purge your caches. Cheers, Jack Merridew 16:23, 7 November 2010 (UTC)

 Done. Give it a try. I picked the first article mentioned in this thread to test it out. See Fantasia Barrino discography. — Edokter • Talk • 16:35, 7 November 2010 (UTC)

Excellent, thank you. I think all we need now (to guarantee a smooth transition at FLC from the existing standard table to the new plainrowheader table) is a miniature step-by-step guide to doing this, including how to add "scope=row" and so on to the table. I'll do my best as FL director and reviewer of most lists to ensure we get this implemented, where possible. As per the recent discussions, I would very much appreciate the ongoing support from you guys with respect to some of the more esoteric templates being used by some projects, such as the video games template ({{VGtitle}}) being discussed at this nomination) to ensure they match up with the expectations of the accessibility crew. Cheers, The Rambling Man (talk) 17:19, 7 November 2010 (UTC)

Sure, just give me a yell on my talk page if you need help. I'll have a look at VGtitle. — Edokter • Talk • 17:25, 7 November 2010 (UTC)

Status check

So now we've gone ahead and changed common.css, allowing row headers to be non-bold and left-aligned (or bold and centered). Are we already so happy with this universally that we can say it's a (permanent, at least in wiki-terms) "go" WP-wide? Are we waiting for feedback from the WikiProject:Military folks or the WikiProject:Lighthouses people? Is it all right to blend this into the proposed guidleine at WP:DISCOGSTYLE as if this is the direction we intend to go? (Someone mentioned "a manual methodology and we experiment first", but it seems we've skipped that.)

And what's going on with the idea of Wikimedia auto-generating the scope attributes? Is that a realistic possibility that's moving forward now (somewhere), or is it some wishful thinking for six monthes from now? — JohnFromPinckney (talk) 20:36, 7 November 2010 (UTC)

For what it's worth from FLC, once I'm clear on how to convert an "old-style" table to a new one (using the unbolded row headers), I'll insist upon it in each of my reviews. I think we're moving forwards. The Rambling Man (talk) 20:39, 7 November 2010 (UTC)

Yes John, I think this looks like it can stick. The folks at WP:DISCOGSTYLE will be wondering what's happened, so they may need some assistance. I'd be happy to comment there if you think there's anything useful for me to say. --RexxS (talk) 21:22, 7 November 2010 (UTC)

Be carefull to insist using this new feature... there needs to be consensus among the various projects before you can start enforcing it. Perhaps updating the MOS first is the wiser course of action, and informing WP:USE is also very desireable. — Edokter • Talk • 22:12, 7 November 2010 (UTC)

I consider this a test-drive, after all, there is no other way to test it then to do it. But I really don't forsee any objections, as default table behaviour is preserved. With regard to auto-generating the scope tags, that could still be a goal; now that we have the CSS framework in place, we can explore the possibilities of implementing an automated scope generator. This would have to be implemented by the devs (or a bot), so prepare to state your case on Bugzilla. — Edokter • Talk • 22:12, 7 November 2010 (UTC)

Having tried this out on a couple of the tables I helped get to featured status, I now see a very clear grey background in the first cell of each row. Sorry for being so dense for having missed this thus far. What is the purpose of this? Can it be (easily) overridden? The Rambling Man (talk) 14:53, 8 November 2010 (UTC)

That is because a row header must remain recognizable as a header. If the header background was the same color as any other cell, any distinction between header cells and data cells would be lost, which I think is not desireable. — Edokter • Talk • 15:35, 8 November 2010 (UTC)

Oh, that's a shame. I thought row headers were also recongizable by being bold, but that we'd agreed this could be turned off using the plainrowheader class? I suspect if we can't do a similar thing for the grey backgrounds, we're not going to be using this interpretation of MOS as it has already raised eyebrows. The Rambling Man (talk) 15:50, 8 November 2010 (UTC)

Late to the party, but why is it undesireable to have row headers as the same shade of grey. I admit my knowledge of all these changes is somewhat limited (WP:TLDR) but I thought the addition of row headers was just for WP:ACCESS purposes. Most of these tables never had row headers before, and the only reason they do now is so screen readers can interpret them (as "scope" only works in ! (th) elements and is depricated from HTML5 in | (td) elements). Rambo's Revenge (talk) 16:01, 8 November 2010 (UTC)

For disclosure I had TRM's talkpage on my watchlist. I agree with Rambo. In my view the most important thing is to ensure that there are no circumstances where there could be a reasonable objection to implementing row headers. I do not hold this view myself, but believe that many people will take the view that introducing a highly undesirable graphical is disproportionate to the problem, and would therefore consider it reasonable not to add row headers. —WFC— 16:09, 8 November 2010 (UTC)

(e/c) That would have been my proposal, not Edokters. —TheDJ (talk • contribs) 16:13, 8 November 2010 (UTC)

The background colors are determined by the .wikitable class. If there is consensus to change the background color in plain row headers as well, we can change that. But in my opinion, this adds a possible layer of confusion to editors as row headers will look exactly the same as data cells. — Edokter • Talk • 16:16, 8 November 2010 (UTC)

I don't see that as a major problem as most of our lists are sortable these days, so the necessity to use a "key" isn't really there, as the "key" "changes" when the reader selects which order to sort the table. The Rambling Man (talk) 16:20, 8 November 2010 (UTC)

I don't see how sorting is relevant to the header's appearance. My point is that is someone uses !, he/she will expect that cell to look like a header, even when plainrowheaders is used. — Edokter • Talk • 16:40, 8 November 2010 (UTC)

I do see Edokter's point. Indeed, an uneducated but technically adept editor would probably reduce !scope=row style=text-align:center|2010 to |2010. But I think the risk of people outright refusing to implement row headers even when educated outweighs the problems that a plain background would throw up. —WFC— 16:47, 8 November 2010 (UTC)

As far as I can see, people are only using ! on rows to make it ACCESS compatible. They don't want it to look like a header. Rambo's Revenge (talk) 17:04, 8 November 2010 (UTC)

I agree with Rambo's Revenge, nobody at FLC (or anywhere else that I've seen) has yet mentioned that our row headers should "look like a header". The Rambling Man (talk) 17:18, 8 November 2010 (UTC)

I agree with both of you. But I thin what Edokter is saying is that editors who aren't fully aware of WP:ACCESS might decide to get rid of what is (as far as they're aware) redundant coding. I think that's a lesser issue than people refusing to implement row headers on aesthetic grounds, but it's a valid point. —WFC— 17:22, 8 November 2010 (UTC)

No, the initial purpose was to make existing row headers access compatible. Then DISCOGS came along wanting to adapt their tables, but not liking the bold, centered font. But anyway, let's hear from more people to see if we can change the background color as well (noting my mild opposition). — Edokter • Talk • 17:28, 8 November 2010 (UTC)

Okay well from my perspective, if we can make this change, keeping accessibility in mind, but allowing tables to look like they used to without the grey background on the first column (which may not be the relevant column as a result of sorting), then fine by me. If we can't maintain the status quo, this change is unlikely to be adopted at FLC. The Rambling Man (talk) 17:36, 8 November 2010 (UTC)

(edit conflict) I've promised not to come back here seeking any further changes, but I hope I'll be allowed to comment. From what I can see (and leaving aside infoboxes), the vast majority of data tables in articles, and particularly 'list articles', don't have row headers, even though they could. Not every one of those tables need row headers, but most of them would improve their accessibility for visually-impaired readers using assistive technologies if they had row headers. As understanding of these issues increases, more editors are trying to introduce row headers to tables to meet accessibility requirements such as WCAG 2.0. The folks who work with list articles regularly have naturally acquired a sense of what the style of those tables should be; however, because row headers have been used so infrequently in the past, the visual style they expect is at odds with the effects produced when a table is changed to have row headers. The "plainrowheaders" class is a simple way of retaining (most) of the styling that is expected, without masses of undesirable inline css styles. I hope that's a fair summary? Personally, I prefer the slightly darker grey background, but I'm not a FLC regular, and I'd defer to their judgement of what they expect. --RexxS (talk) 17:53, 8 November 2010 (UTC)

Header background

Do we want a plain background color (same as data cell) for .plainrowheaders? — Edokter • Talk • 17:37, 8 November 2010 (UTC)

• Optional would be best, so those who insist on it can have it, and those who have never used it, never missed it and question its utility can suppress it. Cheers. The Rambling Man (talk) 17:40, 8 November 2010 (UTC)
  • The only way to make the background optional is with inline CSS, so that is not feasable. The question here is what color do row headers with .plainrowheaders need to have? — Edokter • Talk • 18:01, 8 November 2010 (UTC)
    • That's a real pity. No colour then. The Rambling Man (talk) 18:10, 8 November 2010 (UTC)

We should retain the darker background as an indication that the the cell is a header. Forgoing the centering for row-headers is fine as it really only is right for column-headers; optionally dropping the bold is a presentational concession, as it is. Omitting all distinction from data cells is inappropriate as it tosses the notion that structure matters. Jack Merridew 18:47, 8 November 2010 (UTC)

Well this about compromise. People won't use this if they get undesirable effects that they've never seen before and people won't use it if they don't see any advantage to a mild grey background either. In fact, we've spent a long time trying to not use "just" colour to designate a particular property of a table. The Rambling Man (talk) 18:57, 8 November 2010 (UTC)

Dropping the bold was a compromise. Dropping all visual distinction between a row's header and the row's data cells rather makes the whole notion of appropriately structuring a table an exercise in futility. Absent a distinction, most editors will continue to incorrectly structure tables. The bold was serving to provide a secondary indication of the cell being a header-cell. Jack Merridew 19:11, 8 November 2010 (UTC)

/* ability to cancel background-color, too */
.plainrowheaderbackgroundtoo th[scope=row]
{
 background-color: #f9f9f9;
}

and class="wikitable plainrowheaders plainrowheaderbackgroundtoo sortable" would make it optional. Just sayin', not proposing. Jack Merridew 19:11, 8 November 2010 (UTC)

Too complicated. Question for Jack and Rambling Man (and others): How about using an intermediate color (#F5F5F5) for the tagged row headers? — Edokter • Talk • 22:03, 8 November 2010 (UTC)

Would be better, but where is the "expert" advice that we need to colour the row headers and where is the "expert" advice as to which colour to do it? And where did the old advice of ACCESS go (where we couldn't just "colour" something, we had to add something for the colour-blind to see too, like * or +?) The Rambling Man (talk) 22:08, 8 November 2010 (UTC)

I could mebbe see a lighter shade... but why, really? This reminds me of the zebra striping example; the bottom part, by me. The issue there was finding an intermediate colour between #f9f9f9 and #f2f2f2. On most displays, these are barely distinguishable. Jack Merridew 22:59, 8 November 2010 (UTC)

I'm just trying to find a situation mutually acceptable. ACCESS is important, and our project want to buy into it, but suddenly introducing a grey background after five years (when we've stridently avoid "colour-only" backgrounds, for ACCESS believe it or not) where we, in general, can't see any use for it, and being rather hand-wavy and glib and smug about it, will just result in us ignoring it. I thought we had gone some way to compromise if we accepted the "scope" changes, so screen-readers could use our tables? The Rambling Man (talk) 20:41, 8 November 2010 (UTC)

Where did you get significant feedback from users, that makes you able to know for sure users will dislike the grey background? I thought the main issue was with the bold. Dodoïste (talk) 20:53, 8 November 2010 (UTC)

Fair question. Since I've rolled these changes out to one or two of my lists, I've been asked about the indiscriminate, seemingly unhelpful grey background by one or two people. I don't see the advantage to it, if it's the first column in any case. For a non-visual reader, they get the screen reader telling them about the "scope", for visual readers, they can "see" it's the "first" column. Why does it need to be grey? And how funny that we've worked so hard to not "just use colour" all these years and then WP:ACCESS make cells grey without any explanation whatsoever! The Rambling Man (talk) 20:59, 8 November 2010 (UTC)

I'm aware of the inappropriateness of using colour-only to communicate information. We had three means (centered, bold, background), and are now down to one. I'm also well-known for being against the gratuitous use of colour. This is not just about accessibility in the vision-impaired sense. Styling of headers in a distinctive manner is about communicating the structure of the table to all users. Edokter is saying much the same thing. The definition of wikitable is common across all WMF projects and probably most MediaWiki installations. In order to override this WMF/dev level of 'consensus' folks are going to have to put together a very strong consensus indeed. plainrowheaders is just a day old and is on a 'test-drive' (or a whirl, as I put it). Asking to remove all visual distinction of header cells is simply asking too much. Jack Merridew 21:46, 8 November 2010 (UTC)

Sorry Jack, but perhaps you don't realise that these "header cells" are not signified whatsoever right now. Do consider the fact that WP:FLC are trying hard to accommodate these visual changes, and would happily compromise on a coding that allows blind readers to see what's going on, but doesn't then detract from those readers who can see the table. Perhaps we've spent years wasting our time with trying to (somehow, partially, naively, incorrectly?) meet ACCESS with coloured/denoted cells. I suppose the bottom line is if ACCESS insist on this being MOS, then FLC will shy away from it as it's clearly not in the interest of 99.1% of our audience. If, however, we could find a compromise, then so much the better. To be honest, the ongoing clamour for commonality across WMF etc is a bit too much. In the past fortnight or so, FLC have tried to embrace these changes, understand the restrictions imposed by ACCESS, but right now it seems there's little chance for compromise. Two weeks ago we hadn't really even heard of table captions. The Rambling Man (talk) 22:00, 8 November 2010 (UTC)

I hope we're not gradually forgetting the purpose of row headers. I understand I will improve access to screenreaders in certain situations, but you should always check to see if a particular table actually needs row headers. That said, if row headers are used for the sole purpose of improving screenreader accessability, I guess we can forgo on enforcing a visual distinction between data cells and row headers, but such use must be well-documented. — Edokter • Talk • 22:26, 8 November 2010 (UTC)

The 'not signified whatsoever' header cells would be those that should be headers, but aren't implemented as headers because people don't like the inherent styling? Right now, table header cells get a darker background than data cells. The only exceptions will be those table where is is deliberately coloured differently. This background colour has nothing to do with accessibility, really. Accessibility is pushing the scope attributes, and the captions are helpful to *all*. Captions have been in html forever, and have been associated with "tables" for centuries. MediaWiki has been styling headers in the #f2f2f2 colour forever. Jack Merridew 22:59, 8 November 2010 (UTC)

Since it was my proposal not to change the background, I feel a bit responsible for the whole debate. I think the initial proposal was to style the entire row header as a data cell, as TheDJ proposed. So I'm withdrawing my objection here. Since it is called .plainrowheaders, not .plainrowheaderfonts, it would actually make more sense. I'll make the background transparent (and simultaniously restrict it's use to .wikitable). The impact will be low, and with enough education, there should be little problem adopting the class="plainrowheaders" + scope="row" method. Remember, there's no rush and nothing is irreversable. — Edokter • Talk • 23:28, 8 November 2010 (UTC)

Today's Status Check

So... what, now? It seems we've gone to the greatest effort possible to get the smallest possible effect.

We've endeavored to make sure that only users of screen readers recognize row headings, and everybody else goes without. Editors are not to be encouraged to structure tables according to the data they present, but rather based on what "looks nice", which appears to equate to what the FLC guys are used to seeing.

When given the opportunity to formalize tabular data into semantically correct markup, we've chosen to munge the table markup to most closely approximate a layout table. Editors now have a choice of row headings which are bold, centered and background-shaded (defaults for wikitable, a 67% match with browser defaults), and normal-weight, left-aligned, and unshaded, so that it looks like a (somewhat uncooperative) <td> table cell. Both of these options force a certain alignment no matter the table's default alignment, so anything else needs to be specified inline on every cell. The first of the two options was described as unusably ugly; the second is imperceptably better to most users. We've really achieved some impressive things: The FLC crowd doesn't have to do anything new, or suffer the trauma of seeing something (ew!) different.

Please tell me we're not going to stop here. When I got on this bus, I thought it was going to take me somewhere nicer. Can't we keep going, or back up a couple of blocks, or something? — JohnFromPinckney (talk) 03:39, 9 November 2010 (UTC)

John, you're a clever guy so I don't see why you need to resort to sarcasm all the time. There's been a lot of useful debate here, and wouldn't it have been nice to have done it before rolling those changes out to existing featured material? Anyway, we are here now, and several members of the FLC project have contributed a lot of time and effort to this discussion. It's not about the FLC crowd not wanting to see something different, it's about convincing the FLC crowd that row headers need to have a shaded background. As far as I'm aware, we can now cater entirely for blind people regarding row identification, so we have made positive progress. The discussion re: captions is ongoing. The bus drives on. Ding ding. The Rambling Man (talk) 07:29, 9 November 2010 (UTC)

The FLC bus drives over. Trod trod. Jack Merridew 11:51, 9 November 2010 (UTC)

No, FLC are trying to discuss things with ACCESS, and if you don't think we've made any progress at all, then that's a shame. When FLC object or as for further discussion on this evolving debate, we get name-calls and sarcasm. Which is a shame. The Rambling Man (talk) 11:55, 9 November 2010 (UTC)

What is the priority here? As far as I'm concerned, it's to ensure that all of our content can be accessed by those who can't currently do so in as short a time as possible. The argument against bolded row headers is that a lot of tables would require pretty extensive reworks that are perceived to be disproportionate to the problem. While I have sympathy with the view that this effectively amounts to saying that we can't be bothered to do the volume of work necessary to help blind people, a very similar view did undermine alt text. Given that the argument against manditory visually distinct headers has enough support to prevent consensus on this issue, the best way forward is to implement blank row headers. If that is not satisfactory to some editors, we can then consider whether it is necessary to phase in "proper" row headers, and if so, how we would go about doing it. By insulting those who do care about those who have most difficulty in accessing our content, and/or campaigning for a bolded headers now or nothing approach, there is the very real prospect that "nothing" will be the outcome. I would like to think that none of us want that. —WFC— 12:40, 9 November 2010 (UTC)

I understand the idea of compromise and I don't require all-or-nothing; the risk of nothing is too great. What dismays me is the apparently reflexive resistance to anything that's even somewhat different. Again and again I hear that the FLC guys likely won't support something, so we'd better not try. Even the slightest bit of bg shading on a row header makes the FL community start to pack up their things to go home. There's been no rational explanation for that, no polls or studies, just The Rambling Man saying he was asked a couple times about it and, since he didn't understand the point of it, has concluded the FLC won't support something as drastic as (even only 33% partial) heading behavior in a heading.

I don't require bold in the row headers, although I thought it worked well in certain tables. What I would like to have is a bit more rationality mixed in with the discussion and compromise. It's ugly, therefore it's less accessible, and background shading is different from how it was aren't exactly rational, well laid-out arguments to me, and I'm stunned that the backwards crabbing happened so fast on that basis.

To me, we've gone to great lengths to move forward about 1.7 centimeters. I feel as though we've strapped on some nice big stilts allowing bigger steps, then strode off in a big circle to end a half-inch forward of our original spot. It makes me cranky, and I admit I've become somewhat disillusioned by the experience. — JohnFromPinckney (talk) 13:06, 9 November 2010 (UTC)

But, Man, why do we have to spend so much time convincing FLC (or anybody) that headings should be styled as headings? Why is that such a deal-breaker?

Wikipedia has a style for tables, which includes indications of what are headings and what are data cells. The three indicators for headings are bold, centered, shaded, and you picked all three off one after the other. (In fact, the discussions at DISCOGS led to the left alignment exception already, but the bold and shaded aspects remained.) I can't see what's wrong with having them look at least little bit like what they are. Yet we seem to have to shave off as much of the proposed change as possible so as to cause the least amount of possible offense. I haven't seen a justification for so firmly resisting the basic idea of row headings. It just seems like "it's different" to me. — JohnFromPinckney (talk) 13:19, 9 November 2010 (UTC)

Sorry, nobody's packed their bags. We're still here. We still want to move forward together. It's bad faith of you to say otherwise. I'm happy to start a straw poll to gauge expectations of FLC with regard to grey backgrounds for row headers. Would that help move us forward? If Edokter could knock up a "before", "plainrowheaders" and "after" set of examples (i.e. without scope, with scope but plain headers and no grey background, and with scope, with bold headers and with grey background) that'd be useful to allow FLC to see what's being proposed. The Rambling Man (talk) 13:26, 9 November 2010 (UTC)

(edit conflict)No, Man, you haven't packed them; but there was no need once you got rid of the last bit you didn't like. I really do hope you want to move forward, and when I'm thinking clearly I believe you truly do. It's just that it seems to me that you're trying to avoid doing anything that you've never seen before. That's what I'm trying to document here, so you you can (perhaps) see my frustration. I sincerely appreciate your willingness to spend time on this, and engage in discussions, generally in a more collegial and respectful tone than I have. I hope I'll find the right way to align my still-bitter tone more in the example of yourself, Dodoiste, and RexxS.

I have two main concerns about the straw poll idea:

1. Now that the shading and everything else has been turned off, it seems like it'd be difficult to show people what you're talking about and to get a fair assessment of how they like it. (Part of the thing about row headers is the reason they're row headers; who will explain that?)
2. Once again I come back to the FL-relative-to-the-rest-of-WP issue: shouldn't this be considered by all of Wikipedia (well, those few troubled souls who might care, I mean)? The wikitable is used by everyone, so even if FLC came in with overwhelming unanimous approval of shaded headers, there's still the problem of, say, some folks doing insect articles absolutely hating the change. Don't we have to get everyone on board (oops, there's that stupid bus metaphor again)?

I'm going to have to log off for a while soon, so maybe you and the ACCESS guys can come up with some reasonable approach, while I try to get things in a better perspective away from WP. I'll check in again later tonight, I expect. — JohnFromPinckney (talk) 13:59, 9 November 2010 (UTC)

The primary reason this is most important to FLC is that we mandate the use of the manual of style in any list before it's promoted. As far as I'm aware, only FAC do that too, and their use of data tables is pretty limited. So hopefully that's clearer. As for the straw poll, okay, you have concerns, but I'm not sure how to alleviate the fact that you were worried that it was just me being subjective and using the opinions of a "couple" of people who had raised concerns. Do you have an alternative suggestion on how best to do this? I think for many this has already become a TL;DR issue, so I thought a summary of changes made so far would be useful, and provide a benchmark against which we could draw comment. It would also allow ACCESS to provide a summary, in each case, on what the advantages and disadvantages were for each approach. The Rambling Man (talk) 14:13, 9 November 2010 (UTC)

So, per WP:MOSBOLD#Other uses:

Use boldface in the remainder of the article only in a few special cases:

* Table headers and captions

* Definition lists (example: Glossary of trucking industry terms in the United States)

* Volume numbers of journal articles, in some bibliographic formats

In the first two cases, the appropriate markup automatically adds the boldface formatting; do not use the explicit triple-apostrophe markup. Similarly, in the third case, the formatting should generally be added implicitly by use of a template, such as {{citation}}.

no list will pass FLC if it uses plainrowheaders to subvert the proper rendering of table headings in bold. All-with-JohnFromPinckney, who's right. This change to common.css does not have consensus and subverts the MOS. From under the bus, Jack Merridew 17:25, 9 November 2010 (UTC)

I think you will accept that the majority of the population of the known universe would refer to the first row of a table as its header, not the first column. Irrespective, it's a shame it's turned out this way, with continuing sarcasm. You'll probably be glad to know that you've finally tipped my balance, so I won't be commenting further. I wish ACCESS all the success it deserves. The Rambling Man (talk) 17:33, 9 November 2010 (UTC)

Table headers are any table cells produced by the '!' wiki-text syntax or by explicit th-elements (mostly only in templates). Typically, they appear in the first row and first column, although it's plain that many don't understand row-headers. This change should be undone absent a far clearer consensus to allow the FLC bus to drive over the site css and MOS. Jack Merridew 17:48, 9 November 2010 (UTC)

I'm not sure what you mean by "typically", because "typically" on Wikipedia, lists don't have the ! element outside of the initial row. I'm in complete agreement with The Rambling Man on this issue; the forced bold in these "row headers" is, IMO, unnecessary. I was one who noted that this discussion has become too long to read in sum, however, I will note that a statement that "no list will pass FLC if it uses plainrowheaders to subvert the proper rendering of table headings in bold" is not a decision for any non-FL director to make, especially because it is your opinion that this rendering is "proper", and is not the opinion of those editors who are working to build content in this encyclopedia. I won't comment further on this issue because I've no desire to be dragged into all this mess, but I've said my piece and will now withdraw. — KV5 • Talk • 18:34, 9 November 2010 (UTC)

Typically, lists on Wikipedia are implemented as lists per WP:MOSLIST; Ordered-list, unordered lists, definition lists. Most tables have both logical columns and rows inherent in them and those headers should be appropriately marked-up and styled to indicate their structure. That some lists are marked up as tables is part of the core problem, here. Such lists get entangled in all sorts of non-list related concerns by the choice some have made to use table mark-up for lists. You may be right that FLC will continue to pass pages that don't pass MOS, which says table headers should be bold. Jack Merridew 18:56, 9 November 2010 (UTC)

Header background examples

OK, here are the three examples. No example without scopes, as that is not part of this dispute. — Edokter • Talk • 15:36, 9 November 2010 (UTC)

No .plainrowheaders List of music videos, showing year released and director Title Year Director(s) "Truth Is" 2005 Diane Martel "Free Yourself" 2005 Lenny Bass "Hood Boy" 2006 Ray Kay "When I See U" 2007 Lenny Bass "Bittersweet" 2010 Lenny Bass "I'm Doin' Me" 2010 Benny Boom

.plainrowheaders with shaded background List of music videos, showing year released and director Title Year Director(s) "Truth Is" 2005 Diane Martel "Free Yourself" 2005 Lenny Bass "Hood Boy" 2006 Ray Kay "When I See U" 2007 Lenny Bass "Bittersweet" 2010 Lenny Bass "I'm Doin' Me" 2010 Benny Boom

.plainrowheaders with plain background List of music videos, showing year released and director Title Year Director(s) "Truth Is" 2005 Diane Martel "Free Yourself" 2005 Lenny Bass "Hood Boy" 2006 Ray Kay "When I See U" 2007 Lenny Bass "Bittersweet" 2010 Lenny Bass "I'm Doin' Me" 2010 Benny Boom

So, there's no way to use this class and get row headers to properly render without somehow violating the MOS? Jack Merridew 17:31, 9 November 2010 (UTC)

Please let WT:FLC know if/when you remove the plainrowheaders effect, thanks. The Rambling Man (talk) 17:42, 9 November 2010 (UTC)

 Done on Angelina Jolie && Rihanna discography. Jack Merridew 20:31, 9 November 2010 (UTC)

Time out!

Technically, any deviation from standard bold, centered and gray background for headers is violating the MOS. I am going to repeat some key elements here as to how this change came to be: WP:DISCOGSTYLE was eager to adopt the scope=row method to make their tables more accessable, but did not like the rendering. First, the headers were left aligned, then unbolded. I think most people were happy with that. Then WP:FLC wanted pure plain header cells that look like data cells, so away went the gray background. I am going to ask everyone again: what is the purpose of styling the row headers any different then standard headers? If I can't get a definitive answer, I am going to remove the styling alltogether, as it is clear that no implementation is going to get the necessary consensus. — Edokter • Talk • 20:27, 9 November 2010 (UTC)

Technically every change we ever do violates a guideline these days, until we amend it. It's the consequence of having many rules, you become inflexible. It's a guideline folks. please drive over it with a bus marked WP:IAR if needed. —TheDJ (talk • contribs) 20:38, 9 November 2010 (UTC)

I'd say the purpose of the styling of table-headers, including row-headers, is to aid all readers in properly understanding the nature of the table; to know that certain cells have a special status of 'header'. This is bedrock to html, in the case of bold table-headers, and bedrock to WMF/MediaWiki in the case of center and background on table-headers. I'm more than willing to optionally (plainrowheaders) drop centering on row-headers, as I believe it was truly intended as specific to column-headers when it was originally styled, years ago. Forgoing bold is a major concession to the appearance-over-substance view, and I've reluctantly agreed to that (again, optionally, per plainrowheaders). I object to cutting the background-color under any circumstances, as it removes *all* indication of the header/data relationships between cells in a row; i.e. a false indication of the header-cell's status. Row-headers are *not* specifically an accessibility issue, they, and their appearance, are a structural affordance for all users. Any deviation must be optional and limited to keeping some indication of header-status. For what it's worth, this:

/* row-headers get normal-weight when bold explicitly on-offer; i.e. a it's a route to 'cancel' the ambient bold... */
.wikitable th[scope=row] b
{
 font-weight: normal;
}

would allow overriding the bold by explicitly reiterating the boldness inline. The net-effect is that you get no bold. I've used this sort of approach in other projects to good-effect, but understand that it has a counter-intuitive aspect. Jack Merridew 20:55, 9 November 2010 (UTC)

That is weird code; No thanks. — Edokter • Talk • 22:17, 9 November 2010 (UTC)

Closing this

We were closest to consensus with only resetting the font styling. I still agree that some indication of a header is the best way to go, and as far as I can see, WP:FLC (well, Rambling Man) was the only one with a very vocal opposition to background remaining untouched. Ironic, as he is the one who suggested to unbold the row headers in the first place, and that is precicely the outcome. Not forgetting that me removing the gray shading started this whole discussion, I am going to revert to the previous incarnation that gained the widest consensus (#Solution 3). That means only the font-styling is reset, but the background shading remains in all headers. If any project has a problem with this, please remind them that this styling option is offered as an aid to help accessability, not intended to trump any standing conventions. If and how to use it is now entirely up to the projects, and any discussion of its implementation and MOS related issues is outside the scope of this talk page. — Edokter • Talk • 22:17, 9 November 2010 (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.