MediaWiki talk:Common.css

This is the common CSS for all the skins. Use it only for styling things within the content area (stub notices, message boxes, spoiler/disambiguation messages, etc). --cesarb 16:54, 11 July 2005 (UTC)

The following stylesheets call this one:

• MediaWiki:Cologneblue.css (Cologne Blue)
• MediaWiki:Monobook.css (MonoBook)
• MediaWiki:Nostalgia.css (Nostalgia)
• MediaWiki:Simple.css (Simple)
• MediaWiki:Amethyst.css (Amethyst)
• MediaWiki:Chick.css (Chick)
• MediaWiki:Standard.css (Classic)

Merge template style

Please replace the ".Merge" and ".Merge td" styles with this code. Basically, this was mistakenly added as a "class", rather than an "id". Note that in this CSS, disambig and spoiler are done as id, so this change is consistent. Perhaps you could also group those template styles together so they are easier to see.

(code removed for space)

Let me know when this is complete, so I can correct the related templates quickly. -- Netoholic @ 21:22, 13 July 2005 (UTC)

Ids are supposed to be unique on a given page; classes can be reused. Multiple merge templates on the same page sometimes make sense, as recently seen on Wikipedia:How to create policy (even though the actual merges didn't). —Cryptic (talk) 22:58, 13 July 2005 (UTC)

You make a good point. This is a good time to move to the class-only method. I've changed the code above to a better scheme. You can see a test here using both divs and tables. Can I get someone to add the new code? -- Netoholic @ 02:32, 14 July 2005 (UTC)

This has been completed. -- Netoholic @ 04:31, 17 July 2005 (UTC)

I'm running Firefox 1.0.4 on Windows, using Monobook, and the boxes have completely disappeared. IE displays them. Has this been tested with Firefox? If not, why not? If so, why am I not seeing any boxes anymore? JRM · Talk 12:31, 17 July 2005 (UTC)

Clear your cache. That should solve it. -- Netoholic @ 16:33, 17 July 2005 (UTC)

It does work now. Normally purging the page is sufficient; in this case it wasn't. Let me guess: the CSS is cached no matter what... JRM · Talk 08:08, 18 July 2005 (UTC)

Is this entirely sensible?

It's nice that the skins now don't get out of sync. However, this happens at the expense of the commonly-styled items looking rather out of place in every single one (or, at best, all but one) of the skins. What we really want is a set of classes that are defined in each skin seperately, but which all skins have (a CSS interface class, as it were). This CSS should be used sparingly, and not for proper styling of meta-data like structures, which semantically should be more part of the "overview" of the article than the article itself - that is, they should be styled to look like the rest of the skin. A notable area where common CSS rather than skin-specific CSS would be a bad idea is for infoboxes - it should blend in with the skin (and I strongly doubt that there is a way of styling such a highly-styled item so that it blends with all skins, or even more than one, really).

James F. (talk) 11:38, 23 July 2005 (UTC)

I don't understand the concern. The CSS currently in was largely designed by me, and I've looked at how infoboxs appear in all the skins, and they're fine. If something that is in Common.css doesn't look right, then correct it in the specific skin using the same class identifiers. If you're talking about something that approaches personal preference, feel free to totally redesign in your personal CSS.

Where I agree with you is if we get into too much trouble by being far too specific with the code here. It should be simple and clean, and flexible. The infobox code is just that - it takes the most common formatting already in use today and wraps it up in a stand-alone form that the user can customize. When this code (borders, position, width, etc.) is place in a template directly, you can't customize. Most infoboxes now just need to add class="infobox" and will have a basic format (replacing the more limited "toccolours" usage). -- Netoholic @ 19:47, 23 July 2005 (UTC)

I believe JamesF's point (and I agree with it fully) is that what looks good in one skin may well not look good in another. For example, I don't think the messagebox, infobox or prettytable default colours (#f9f9f9 — light grey) look at all good in Cologne Blue, and I fancy they wouldn't look good in Classic either. What JamesF was suggesting was each class has a different look in each skin, to create a completely "skinned" appearance. This is the way most websites would do it. [[smoddy]] 08:46, 25 July 2005 (UTC)

Surely it is possible simply to over-ride the particular properties which look bad in the particular skin? So you keep the standard properties other than those which look bad... —Phil | Talk 12:13, July 25, 2005 (UTC)

Class names

We seemed to have complete ignored the discussion about class names from monobook.css: (ed g2s • talk 15:36, 8 August 2005 (UTC))

Whatever you do, don't use the word "pretty" in the class name! A class name should describe the function on the element, not the current appearance, which is likely to change. See what the W3C has to say on the matter: http://www.w3.org/QA/Tips/goodclassnames . ed g2s • talk 11:13, 21 July 2005 (UTC)

I agree, but I cannot come up with a better name than "pretty", maybe because I cannot describe which tables should be "pretty" and which should not. The ones that should not be "pretty" are fx infobox, taxobox and other tables that ought to have their own css class definitions. So maybe the "prettytable" thing should really apply for tables in general? But, as mentioned above, I do not know the exact consequences of changing the css for tables in general... -Fred Bradstadt 11:28, July 21, 2005 (UTC)

Finally I got attention! Maybe I should have added this to the bottom of the page like I usually do.

I advocate good class names myself, but ‘pretty’ is a border case IMO. Name it whatever you want, though, as long as people can remember it and associate with the correct meaning, which currently is just prettyfying. This argument would of course be nil, if all tables were changed.

Note that the second part of my code, that is not intended to work in IE, is not perfect. If Wikipedia really used XHTML—currently it's just tagsoup labeled as XHTML, which is bad—the selectors with ‘tbody’ would not work; solution: duplicate and remove “tbody>” once. The header background color part is of course just an example, often just selecting ‘th’ would be enough (and nobody uses ‘scope’ on WP anyway). Christoph Päper 11:53, 21 July 2005 (UTC)

What about default table, standard table or skinned table? I'm sure that between us we can do better than "pretty". ed g2s • talk 12:28, 21 July 2005 (UTC)

“Default” or “standard” should be just ‘table’, not ‘table.foo’. “Skinned” implies that it's different in each Skin, i.e. it wouldn't belong into common.css. Christoph Päper 13:36, 21 July 2005 (UTC)

Hey guys, I think this is an important initiative - let's not leave it stranded because we cannot agree on a class name! Are there any problems in changing the general table design to the prettytable css? -Fred Bradstadt 11:46, July 24, 2005 (UTC)

I agree that if the intention is for this to be the default table styling then it shouldn't have classname at all, but should only apply to all tables inside an article (i.e. replace table.pretty { ... } with #content table { ... }). I can't see any other problems with implementing it. ed g2s • talk 12:59, 24 July 2005 (UTC)

empty-cells:show; for "prettytable"?

In the German wikipedia I've added empty-cells:show; to the prettytable template. With it, adding " " or using other ugly tricks to get borders around all cells is unnecessary. My suggestion would be adding it to the "prettytable" class (or whatever it's name ends up to be), would be good as well. And yes, I know it won't work on older browsers. BTW, I stumbled upon the issue again, when looking at the article Comparison of accounting software in it's version (http://en.wikipedia.org/w/index.php?title=Comparison_of_accounting_software&oldid=20546718). For "normal" users, I'd assume it's a big help. --S.K. 19:23, 8 August 2005 (UTC)

Using these classes

See infobox standardisation.

Proposal for CSS for tables

For the last half year, there has been discussions (see Prettytable and Monobook.css) regarding the Prettytable template, a "cute design template for tables" currently used by almost 4,000 wiki-pages – that's hard work for the servers,  :-(

It has been suggested to create a new table class, for example pretty or prettytable (which is actually already in use in Common.css), but it has been suggested (by myself) to simply change the CSS for tables in general. The proposed CSS follows (thanks to User:Crissov):

table {
    margin: 1em 1em 1em 0;
    border-collapse: collapse; 
    background: #f9f9f9; color: #000;
    empty-cells:show;
/*  font-size: 95%;*/
}
table th,
table td {
    border: 1px #aaa solid;
    padding: 4px;
}
table th[scope="col"], /* column header */
table>tbody>tr:first-child>th,
table th[scope="row"], /* row header */
table>tbody>tr>th:first-child {
    background-color: #ccccff;
}
table th[scope="row"], /* row header */
table>tbody>tr>th:first-child {
    text-align: left;
}
table>tbody>tr:hover>td,
table>tbody>tr>td:hover {/* or '*' instead of 'td' */
    background-color: #e0e0ff;
}

I see the following possible problems:

1. Wikipedia skins may use some table-based layout, which would now get some unwanted style changes.
2. The design is suited for the Monobook skin only. Other skins look great as they are.
3. Browser X shows stripes/unwanted colors/behaves strange/crashes because of this change.

Please give me your thoughts. Regards, Fred Bradstadt 16:09, August 20, 2005 (UTC)

Can't problem #1 be avoided by just adding a #bodyContent to each of these rules? I can see a related problem, however: some templates might be expecting the current styling for their tables. --cesarb 00:54, 21 August 2005 (UTC)

Of course cesarb, you're right! Here is 2nd Proposal for CSS for Tables:

div#bodyContent table { margin: 1em 1em 1em 0; border-collapse: collapse; background: #f9f9f9; color: #000000; empty-cells: show; /* font-size: 95%;*/ } div#bodyContent table th, div#bodyContent table td { border: 1px #aaa solid; padding: 4px; } div#bodyContent table th[scope="col"], /* column header */ div#bodyContent table>tbody>tr:first-child>th, div#bodyContent table th[scope="row"], /* row header */ div#bodyContent table>tbody>tr>th:first-child { background-color: #ccccff; } div#bodyContent table th[scope="row"], /* row header */ div#bodyContent table>tbody>tr>th:first-child { text-align: left; } div#bodyContent table>tbody>tr:hover>td, div#bodyContent table>tbody>tr>td:hover {/* or '*' instead of 'td' */ background-color: #e9e9ff; }

There are a few minor corrections from the 1st proposal. In the 2nd last line I have changed the hover color to a bit brighter shade of blue.

Still, we have 3 requests for comments:

1. The design is suited for the Monobook skin only. Other skins look great as they are.
2. Browser X shows stripes/unwanted colors/behaves strange/crashes because of this change.
3. Some templates might be expecting the current styling for their tables. How is this fixed?

-Fred Bradstadt 17:58, August 21, 2005 (UTC)

1. applies to colors only. I assume 2. is a question with no answer yet. Templates as described in 3. must be changed, they shouldn't expect any particular styling in the first place. Note that you probably have to adjust the margin for right-aligned and centered tables, i.e. something like

div#bodyContent table.right {margin: 0 1em 1em 1em;} div#bodyContent table.center {margin: 1em auto;}

Christoph Päper 23:02, 21 August 2005 (UTC)

I agree with changing the formatting for all default tables. However, there are probably many tables that depend on the white background, for instance, so it might not be a good idea.

Also, please don't make any sweeping changes until we've thoroughly tested them and make sure there are no visible differences. See Template talk:Prettytable#Movement to CSS User:Omegatron/sig 21:36, August 22, 2005 (UTC)

About the 3rd problem, that some templates are dependent on the current table style to look right: Isn't the problem really that the templates should have had their own class="template" kind of thing? By the way, many templates use the toccolours class.

About Omegatrons comment, that some tables depend on the white background – I don't see that problem. Could you/somebody give examples, please?

I agree 100% that we should test thoroughly before we implement any changes. -Fred Bradstadt 07:35, August 30, 2005 (UTC)

I don't know of any examples. I just thought it might be possible. User:Omegatron/sig 13:28, August 30, 2005 (UTC)

Note that some Infoboxes use nested tables, which will be given unwanted margins, borders etc. ed g2s • talk 13:48, 30 August 2005 (UTC)

The current class "prettytable" gives results quite different from the template "prettytable". The proposal above gives good results in a few summary tests I did (in IE6). Would it be possible to take the proposed style above already in production as a class "prettytable" (or should we rename to "wikitable")? Then we can experiment with replacing the various "prettysomething" templates already in use. See also remarks at Template talk:Prettytable. Merging the style with an additional style parameter at the table itself works well. −Woodstone 20:19:25, 2005-09-08 (UTC)

Cellpadding doesn't work:

Prettytable template	template	template
100	Cake	Monster in the closet
Wikipedia	^______^	Darth Vader
Moo	1.618033989	Pay your bills

Prettytable class	class	class
100	Cake	Monster in the closet
Wikipedia	^______^	Darth Vader
Moo	1.618033989	Pay your bills

Otherwise it looks good to me. Should be tried with many different tables and see if they all look good. User:Omegatron/sig 16:02, September 9, 2005 (UTC)

Note that the current production version of the class is not the one proposed above. So it cannot be judged right now from the above if padding works. Furthermore, in the current version margins are defined in pixels, where it should be in terms of font size (em, en, ex). To do experiments on a lot of tables, I propose again to install above proposal as class "wikitable". Any objections? −Woodstone 21:38:06, 2005-09-09 (UTC)

The cellpadding attribute is in pixels, no? So it would have to be changed to pixels to make it exactly the same. I think font-proportional padding is a better idea.

There is already a wikitable class, though I don't know what it is used for. Supposedly we should have a functional name for the class instead of a descriptive name, but I don't know what that would be. The function is to make tables pretty.  :-) User:Omegatron/sig 21:56, September 9, 2005 (UTC)

Suppressing external links in print backend

Moved this thread from User talk:Lexor on 11:48, September 8, 2005 (UTC)

Hmmm. Why did you do this? First, I think there should be semicolons after "display : none ! important;", and second, plainlinksneverexpand should never expand links, whether in print or on screen... Lupo 09:13, September 8, 2005 (UTC)

I am stumbling around trying to ensure that external links with class="plainlinksneverexpand" embedded in infoboxes like Template:Infobox Country don't get expanded in the print backend especially. My CSS isn't great, if you can help me out, great. I fixed the semicolon problem. Lexor|Talk 09:24, September 8, 2005 (UTC)

e.g, try doing "Printable version" of United States, because of the external co-ordinate link for Washington, the whole infobox consumes the entire screen real-estate. I tried wrapping the link with a <span class="plainlinksneverexpand">, and added a corresponding CSS rule in Common.css for class='external text' but for some reason it doesn't work the same as for the class='external autonumber'. Lexor|Talk 09:28, September 8, 2005 (UTC)

Here's a standalone testcase: User:Lexor/test. If you click printable version, you should not see the external link in either case, but only the one with the autonumbering "[1]" is the external link supressed. Lexor|Talk

Yeah, I see what you mean. Beats me. The "a.external.text:after" case you added should suppress this. Why it doesn't, I do not know. Lupo 10:29, September 8, 2005 (UTC)

Now I just added this:

.plainlinksneverexpand a.external.text:after {
 display: none !important
}

to my local customization monobook.css, and it works! (try adding it to your User:Lupo/monobook.css), but it really should be applied globally, IMHO. Lexor|Talk 14:07, September 9, 2005 (UTC)

I moved it to MediaWiki:Monobook.css, seems to work there. Mysterious, though. Lexor|Talk 14:23, September 9, 2005 (UTC)

Could this have something to do with the funny way MediaWiki:Monobook.css imports Common.css? What does "smaxage=2678400" mean? Lupo 14:39, September 9, 2005 (UTC)

Dunno, could be, maybe. Don't know what smaxage means, I'm guessing it limits the age of the edit it uses or something? I guess try making other minor (test) modifications to Common.css and see if they take effect, maybe that's the problem, Monobook.css isn't "seeing" the changes to Common.css. Lexor|Talk 14:55, September 9, 2005 (UTC)

That "funny way" is exactly the same way the import of Monobook.css is done (view the source of any page and you will see). I made it that way exactly to avoid any possibility of the import not working (because if it didn't work, Monobook.css itself wouldn't work). Did you clear your cache after changing Common.css (Shift-Reload on Firefox)? Did you check with a CSS validator? --cesarb 00:39, 11 September 2005 (UTC)

Replacing "prettytable" templates with a style

Currently the Template:Prettytable and the style Prettytable give quite different results. Discussions have been ongoing on this and other pages. The proposal below is a simple version that embodies most comments made. It comes so close to the original template that most likely no disturbance of layouts will occur. A few small tweaks are:

• slightly darker background on header
• relative definition of padding, and just a fraction smaller
• new name to avoid clashes and allow double checks on existing occurrences
• automatically show borders around empty cells

table.wikitable {
  margin: 1em 1em 1em 0;
  background-color: #f9f9f9;
  border: 1px solid #aaaaaa;
  border-collapse: collapse;
  empty-cells: show;
}
table.wikitable th {
  padding: 0.2em;
  border: 1px solid #dfdfdf;
  background-color: #efefef;
  text-align: center;
}
table.wikitable td {
  padding: 0.2em;
  border: 1px solid #dfdfdf;
}

Who would be able to add this to the protected page? After that is done, we can replace several templates (which are not so consistenty named right now):

• {{prettytable}} => class="wiki" style="font-size: 95%"
• {{prettytable100}} => class="wiki"
• {{subst:prettytable100center}} => class="wiki" style="text-align: center"
• {{prettytable-center}} => class="wiki" style="text-align: center"
• {{prettytable95}} => class="wiki" style="font-size: 95%"

−Woodstone 23:01:59, 2005-09-10 (UTC)

It should be like this:

• {{prettytable}} => class="wiki"
• {{prettytable100}} => class="wiki"
• {{subst:prettytable100center}} => class="wiki" style="text-align: center"
• {{prettytable-center}} => class="wiki" style="text-align: center"
• {{prettytable95}} => class="wiki" style="font-size: 95%"

I don't know why people keep adding the font size command to the regular one. User:Omegatron/sig 23:56, September 10, 2005 (UTC)

The original one started out as 95%; that's why there is a 100 version; the 95 version came about because people got tired of the edit war, never knowing what size was in. In my new proposed class the font size is not specified. So it can be decided locally at the table if a reduction or enlargement is needed. I changed the example table to avoid that the table size is influenced by the text of the format option. −Woodstone 09:37:04, 2005-09-11 (UTC)

Added. I don't think "wiki" as a class name is any better than "prettytable".

Thanks for adding it. I agree "wiki" is a rather presumptuous class. I have no objection against "prettytable", but during testing, it might disturb existing articles. I propose to weaken the class name to "wikitable" for the time being. I already tested a number of previews, and it gives quite good results so far. One thing that was not right yet, were the nicely faint internal borders of the template. I have experimented and come up with an adapted version. On my IE6 the "empty-cells:show" does not seem to work however. Could you please replace this version for further testing? Hopefully the edit war over font size at template:prettytable can be ended when the style is established. −Woodstone 09:37:04, 2005-09-11 (UTC)

It's my understanding that the "empty-cells:show" only applies to the separated borders model, and this is using collapsed borders. Do you have a test case that it doesn't work for? User:Omegatron/sig 20:40, September 11, 2005 (UTC)

Those colors are completely invisible on my LCD.  :-) I kept refreshing the cache thinking it hadn't updated yet, but in reality those colors just look white on my screen. We shouldn't design around my screen; the different background colors in monobook aren't even distinguishable, but I think the borders should be a little darker; they're almost invisibly faint in your last version. I noticed that your efefef cell borders override the aaaaaa table borders in Firefox, as per the spec, but IE renders the outside border as aaaaaa. This works better for me: User:Omegatron/sig 21:42, September 11, 2005 (UTC)

table.wikitable {
  margin: 1em 1em 1em 0;
  background: #f9f9f9;
  border: 1px #aaaaaa solid;
  border-collapse: collapse;
}
table.wikitable th {
  border: 1px #aaaaaa solid;
  padding: 0.2em;
  background: #efefef;
  text-align: center;
}
table.wikitable td {
  border: 1px #aaaaaa solid;
  padding: 0.2em;
}

In the original template, I especially like the strong outer border and faint inner borders (or are they perhaps white?). Many of the "info boxes" defined for many subjects have similar faint borders. It fit well together with prettytable. It is not clear how this is reached. On IE6 (and my 32bit LCD) it looked fine for the class proposal. Do you know another way to do this in firefox (which I do not have). I agree the header background could be slightly darker. Meanwhile I will do some more experimenting. I'm using the following test examples (not in wiki style for testing stand alone):

old {{prettytable100}}

	x	y	z
blank
primary	red	green	blue
mixed	cyan	magenta	yellow
neutral	dk grey	lt grey	white
empty

class="wikitable"

	x	y	z
blank
primary	red	green	blue
mixed	cyan	magenta	yellow
neutral	dk grey	lt grey	white
empty

class="wikitable"
style="text-align: center"

	x	y	z
blank
primary	red	green	blue
mixed	cyan	magenta	yellow
neutral	dk grey	lt grey	white
empty

class="wikitable"
style="font-size: 95%"

	x	y	z
blank
primary	red	green	blue
mixed	cyan	magenta	yellow
neutral	dk grey	lt grey	white
empty

Original prettytable template - caption

Header	Foo	Bar
old {{prettytable}}
100	Cake	Monster in the closet
Wikipedia	^______^	Darth Vader
Moo	1.618033989	Pay your bills

Prettytable class example - caption

Header	Foo	Bar
class="prettytable"
100	Cake	Monster in the closet
Wikipedia	^______^	Darth Vader
Moo	1.618033989	Pay your bills

Wikitable class example - caption

Header	Foo	Bar
class="wikitable"
100	Cake	Monster in the closet
Wikipedia	^______^	Darth Vader
Moo	1.618033989	Pay your bills

Looks good to me.User:Omegatron/sig 23:54, September 10, 2005 (UTC)

I don't like the really faint lines on top of a grey background. I am looking on my CRT at work and it still doesn't look good. We need to think about accessibility for visually impaired, too, not just washed out LCD monitors like I have at home.  :-) To get a dark border around the whole table and light borders around cells, you would have to make it two pixels wide, I believe. A wider border overrides a thinner one, but a cell border overrides a table border of the same width. User:Omegatron/sig 20:33, September 12, 2005 (UTC)

On my IE6 I have clearly single pixel dark outer and faint inner borders. I see this also in many "infobox" templates (like for countries). How do you see those? Strangely enough, if I copy the prettytable template content in a local file, it looks different (grey inner borders) than via wikipedia (almost white inner borders). There must be other styles influencing behaviour. How do you see them above here? The amount of faintness can of course be discussed and determined to be perceptable for most users. Faint inner borders look much more distinguished than all borders heavy. After a few trials I find #dfdfdf to be about equal to the color in inner borders of the infoboxes. I agree with yourt proposal above for #efefef as header background. I changed my list above accordingly. I tried a 2-pixel border, but it is quite ugly and out if style with the rest of wikipedia. −Woodstone 21:31:33, 2005-09-12 (UTC)

The color of table borders are not showing as #aaaaaa. See list of countries by population. Please fix this. —Cantus…☎ 11:58, 15 September 2005 (UTC)

I agree with Cantus and suggest to replace

table.wikitable th {

 border: 1px #f9f9f9 solid;
 padding: 0.2em;
 background: #f2f2f2;
 text-align: center;

} table.wikitable td {

 border: 1px #efefef solid;
 padding: 0.2em;

}

with

table.wikitable th, table.wikitable td {

 border: 1px #aaaaaa solid;
 padding: 0.2em;

} table.wikitable th {

 background: #f2f2f2;
 text-align: center;

}

Regards, -Fred Bradstadt 12:36, 15 September 2005 (UTC)

I agree. The invisible borders aren't good. I've updated it accordingly. User:Omegatron/sig 13:58, 15 September 2005 (UTC)

It looks good, but it's a pity that we cannot do the faint inner borders. As for clarity of definition I would prefer a full split between th and td parts. The replacement of template:prettytable100center was incorrect (now ok). As for margin (see remark below), we might include only top and bottom margin. That would work for many cases of left and right placement, where text does not flow around. With flow-around margin can still be added locally by margin-right="0.2em". −Woodstone 20:19, 15 September 2005 (UTC)

YUCK the cell borders are almost invisible now making some tables like the one at the top of windows-1250 nearly impossible to read Plugwash 21:50, 15 September 2005 (UTC)

Ctrl+F5.  :-) User:Omegatron/sig 02:46, 16 September 2005 (UTC)

Wikitable margins

.wikitable should not define margins in the main class. There should be sub-classes, wRight, wLeft and wCenter, as the margins are dependent on table alignment. ed g2s • talk 14:32, 15 September 2005 (UTC)

I agree. In particular, the top margin must be set to 0; otherwise, table captions will be separated from their table by this margin. The margins also cannot be overridden in user CSS. ‣ᓛᖁ♀ᑐ 18:14, 19 September 2005 (UTC)

In the examples shown above in IE6 I do not see the caption separated by the margin! The margin goes neatly on top of the caption. I strongly urge to keep at least top and bottom margins, as removing them would disturn layout in most articles. Suppressing the right margin will hopefully not do too much harm and will allow both left and right alignment on table level. −Woodstone 19:34, 19 September 2005 (UTC)

wikitable padding/font size

Padding is too small and text is too large. It looks strange. Either increase the padding, or decrease the font size. Thanks. —Cantus…☎ 06:28, 16 September 2005 (UTC)

We changed the padding to a font-proportional size instead of a pixel size. It looks the same as the old template on my screen. Do you have an especially high- or low-res screen/big or small screen font? Can you show a screenshot? User:Omegatron/sig 13:38, 16 September 2005 (UTC)

Sure:

—Cantus…☎ 00:31, 18 September 2005 (UTC)

It would help if you could reference the article where this table comes from, so we can compare. −Woodstone 08:14, 18 September 2005 (UTC)

Tennis Masters Series. Oops :-) —Cantus…☎ 04:11, 19 September 2005 (UTC)

Indeed your padding looks a tiny bit smaller than what I see. I tested locally to set padding to 0.25em and it exactly replicates the original size of the template (at the default font in my IE6). However there were requests to make padding a trifle smaller. What does everyone think, should we try 0.25? −Woodstone 18:06, 19 September 2005 (UTC)

I like it smaller. The screenshot looks great to me.  :-) User:Omegatron/sig 00:23, 20 September 2005 (UTC)

Just a little bit more padding, please. The current padding sets a separation that is even less than a space character! —Cantus…☎ 23:24, 21 September 2005 (UTC)

Accessibility

I would like to request that we consider accessibility as a priority. Moving to a stylesheet is probably a 'good thing' for accessibility.

However, there are still some features within the proposed standard style that could be improved. For example, the colours reduce contrast. It would improve access if contrast between text and background were increased.

People may also wish to check example pages with: http://valet.webthing.com/access/url.html

Many thanks. Bobblewik 14:14, 20 September 2005 (UTC)

wikitable captions

I like the captions of the prettytable template better; at the bottom of the table and bolded. What do others think? User:Omegatron/sig 18:01, 21 September 2005 (UTC)

At the bottom, but not bolded would be my preference, which is consistent with how it's done by default for pictures. −Woodstone 19:09, 21 September 2005 (UTC)

Wikitable alignment in row header

It is often required that row header cells are not centered. With the old template:prettytable this worked by adding align="left". However, with the class "wikitable" this does not seem to work anymore. Adding style="text-align: left" still works. See examples here:

appearance rowheader	extra formatting in rowheader	comment
r1	none	header centered as per style
r2	align="left"	straight override not working
r3	style="text-align: left"	style override working

A few articles currently suffer from this effect. Can someone explain why straight alignment does not override the stylesheet? Is it conforming css specs? −Woodstone 21:43, 25 September 2005 (UTC)

My original proposal had code to center text in column heading cells, but left-align in row ths, i.e. something like

.wikitable th:first-child    {text-align: left;}
.wikitable tr:first-child th {text-align: center;}

The selectors could be made more precise/specific (>) to result in fewer false positives (possible with nested tables), but would probably work in fewer browsers, esp. Internet Explorer. (IIRC IE6 supports :first-child, otherwise the point is moot.)

How should text in the upper left corner be aligned? — Christoph Päper 13:33, 26 September 2005 (UTC)

I tried this already before based on your proposal, but in both my IE6 and Firefox it does not have any effect. Does it work for you? If so, can you edit the example above to show how you do it precisely? −Woodstone 16:32, 26 September 2005 (UTC)

I remembered incorrectly, IE6 doesn’t support it, but Gecko (Firefox, Mozilla), Opera and KHTML (Konqueror, Safari) work just fine. IE 7 and iCab 3 probably, too. Test with any simple table. If it doesn’t work in Wikipedia articles there is probably a more specific rule in one of its stylesheets. Christoph Päper 18:58, 26 September 2005 (UTC)

Merging classes "wikitable" and "prettytable"

Since a few weeks the class "wikitable" has been in use to implement the various templates {{prettytable}}. It seems to be working fine. However during experimentation phase a class "prettytable" was added to the Common.css stylesheet as well. Now the time has come to eliminate one of the names.

• either we stick to "wikitable" and delete the "prettytable" class
• or we go for "prettytable" (but change the contents to to currently accepted "wikitable") and eliminate "wikitable".

−Woodstone 10:09, 5 October 2005 (UTC)

Agreed that one needs deleting. Not sure which one is better. User:Omegatron/sig 13:41, 5 October 2005 (UTC)

Since the purpose is simply aesthetic (right?) I suggest using the class name prettytable. —Michael Z. 2005-10-16 14:10 Z

I disagree. The table is not necessarily pretty to all. The purpose of the class is to apply the current wikipedia styling. I will merge the classes so prettytable is an alias of wikitable as it may still be in use in places. ed g2s • talk 14:34, 31 October 2005 (UTC)

Imported directly

This page is now imported directly into the HTML for all skins. The @import lines can be removed from all the skin-specific CSS pages, after a few days have elapsed for cache expiry. -- Tim Starling 10:55, 23 October 2005 (UTC)

Cool! I didn't expect my idea of creating a separate common CSS on the MediaWiki: namespace would go that far. --cesarb 19:31, 23 October 2005 (UTC)

Main Page CSS

I'm shortly going to add a little bit of CSS to this file for the proposed new Main Page design. This is for testing purposes only, to check if this design works correctly live on Wikipedia. It will not alter the display of the live site. Please don't remove it for the moment. Thanks, Tom- 23:19, 25 October 2005 (UTC)

Image alignment

The hardcoded css for monobook at http://en.wikipedia.org/skins-1.5/monobook/main.css includes the lines:

img {
    border: none;
    vertical-align: middle;
}

Classic, Nostalgia, Cologne Blue, and I suspect most of the new skins do not, and where this is not taken into account, the results look horrible. (See, for example, Template:Mac-stub, where the once-standard table code still visible in Template:Metapicstub was recently removed.) Rather than quixotically searching through the template namespace and adding tables to control this visual issue (usually a poor idea), with confused monobook users following me and breaking them again, can this be added here? —Cryptic (talk) 06:30, 28 October 2005 (UTC)

Common.css should only have things which affect the content area (see the very top of this talk page). These lines also have an effect outside the content area. I believe what you want to add to Common.css would be:

div#bodyContent img {
    border: none;
    vertical-align: middle;
}

--cesarb 02:35, 30 October 2005 (UTC)

bodyContent, again, only appears in monobook. Switch to classic and view the html source. —Cryptic (talk) 03:42, 30 October 2005 (UTC)

Hm, classic seems to use div#article instead of div#bodyContent. I believe then it would be better to add the code separately to each of the skins, instead of using Common.css, since it would be different for each one of them. --cesarb 12:43, 30 October 2005 (UTC)

Little arrows on the Refs

Hi guys, I have my own website running on the wiki software and I am beating my brain trying to figure out how to get rid of the external link arrow on my reference template. I've got what seems to be all the pieces needed in the default skin's Summabook.css file, as well as monobook's Monobook.css. And for good measure, it's in Common.css (even though I don't import it into the other .css files like wikipedia does) and the main.css file for the skin. How can it not be loading the code and getting rid of the arrows? What's missing? David Bergan 07:18, 1 November 2005 (UTC)

As far as I can tell (using Mozilla's DOM Inspector) you've got a rule

#bodyContent a[href^=http://], #bodyContent a[href^=gopher://] {background-image:url(external.png)}

in your main.css. That's where it happens... -Fred Bradstadt 09:19, 1 November 2005 (UTC)

Ok. Well, commenting that line out got rid of all the arrows... both for the refs and the normal external links... which isn't the solution that wikipedia uses. But on the other hand, I kind of like it.

Can anyone explain to me the theory behind the "plainlinksneverexpand" solution and how they got it to work on wikipedia? David Bergan 00:38, 2 November 2005 (UTC)

Audio links

The problem: We want a way to briefly link to audio files, like so:

Bordeaux ( pronunciation[?]) is a port city in...

But if you click on the loudspeaker icon, you go to the image page for the loudspeaker icon, which obviously confuses a lot of people. So it currently looks like this:

Bordeaux () is a port city in...

Ideally, we would be able to use css or software changes to make a clickable icon for audio files.

A solution

Add this to your user css (User:YOURUSERNAME/monobook.css):

.audiolink a{
    background: url("http://upload.wikimedia.org/wikipedia/commons/f/f7/Loudspeaker.png") center left no-repeat !important;
    padding-left: 16px !important;
    padding-right: 0 !important;
}

and then reload this page:

• External audio link:

  pronunciation

• External audio link with audiolink class:

  pronunciation

• Internal audio link:

  pronunciation

• Internal audio link with audiolink class:

  pronunciation

This way people can click on the loudspeaker icon without going to the loudspeaker's image description page. If it works for everyone, can we add it to MediaWiki:Common.css and use the audiolink class where appropriate?

The icon should really be a system icon (in http://en.wikipedia.org/skins-1.5/monobook/), but we can use a (protected?) image from the Image: namespace for now. I made a copy here to be protected, but maybe that's not necessary.

Same discussion here. — Omegatron 18:56, 18 January 2006 (UTC)

Unjustified text justification

Would anyone object to removing text-align: justify from .notice and .messagebox? This serves no purpose, except to add big ugly gaps between the words and make it looks like it belongs to some other web site. —Michael Z. 2005-11-15 19:30 Z

Invalid CSS causing parsing errors in Firefox

I originally reported this here, not knowing where else to post it. I filed a bug and was referred here, so here's the original message, somewhat redacted:

There are two problems with the Common stylesheet that should be fixed ASAP. First, the filter statement on line 225 should simply be removed: It is nonstandard and produces errors messages in Firefox's debugging console. Secondly, the line-height property on line 208 has no units (should be 1.5em, I'm sure), which is invalid and also causes error messages. —HorsePunchKid→龜 19:36, 18 November 2005 (UTC)

Font problem for y with macron

y with macron, ȳ, Unicode 233 hex, which is used in Old English morphology, appears as a box on my computer even though it is enclosed in Template Unicode. The same problem occurs with Template IPA: ȳ

I use MSIE 6.0, and my fonts include Arial Unicode MS, Microsoft Sans Serif.

The problem appears to be that Arial Unicode MS appears before Microsoft Sans Serif in MediaWiki:Common.css, but Arial Unicode MS doesn't support codes 218-24F. I propose that the order of these two fonts be reversed. --teb728 01:31, 3 December 2005 (UTC)

OK, let me restate this as a request rather than as a problem. Someone please put Microsoft Sans Serif ahead of Arial Unicode MS in the font list. --teb728 21:27, 14 December 2005 (UTC)

Increase wikitable contrast

The contrast in wikitable is unnecessarily low. Can we increase it please? Bobblewik 12:33, 14 November 2005 (UTC)

I would love to get rid of the grey background altogether; there's no reason for it. The table already has an outline. —Michael Z. 2005-11-15 19:28 Z

If that is a proposal acceptable to others, I would go along with it. Bobblewik 17:34, 4 December 2005 (UTC)

Looks great exactly the way it is to me. — Omegatron 18:29, 4 December 2005 (UTC)

The background is consistent with the left side bar, the table of contents and many other boxes. It gives a distinctive styling. −Woodstone 18:59, 4 December 2005 (UTC)

Phrases like looks great and distinctive are aesthetic judgements. Aesthetics are good. Legibility and accessibility are also good. I would like to increase contrast to increase legibility and accessibility. Bobblewik 19:16, 4 December 2005 (UTC)

Incidentally, the background of this whole talk page has more contrast than the wikitable. What value is it set to? Bobblewik 19:18, 4 December 2005 (UTC)

Legibility is subjective as well and certainly not independent of aesthetic experience. Since many other elements in the style share the same level of contrast, we should not modify just one element. And a change with such a heavy impact on overall style should not be taken lightly. −Woodstone 19:33, 4 December 2005 (UTC)

I don't know what makes you think legibility is subjective, it can be measured. If you reduce contrast, you reduce legibility. That may be acceptable to you but not everybody has your eyesight and your screen.

I agree that these decisions should not be taken lightly. If you suggest an increase in scope of the discussion, that is fine. Where would such a discussion take place? Bobblewik 20:07, 4 December 2005 (UTC)

It is by no means an established fact that more contrast is more legibility. There may be in an average sense a "best" contast, but that may not be the best compromise. Actual effect depends on many factors as the type and resolution of the screen, the view angle, the lighting in the room and the eyesight of the viewer. It's quite difficult to "know" what should be done. Let's not tinker with long standing style elements. −Woodstone 20:24, 4 December 2005 (UTC)

Even pure black on white on any computer monitor always has lower contrast than black type on white paper under good lighting. Practically all word processor software and most well-designed web sites with long passages of text use pure black on white—maximum contrast—for best possible readability (including Wikipedia!).

The Wikitable, with its grey background, has a lower contrast, and therefore reduced readability (this has been tested in practice, and the results are the complaints of editors that you see on this page—for every one who found this place, there is probably a hundred or a thousand non-editors who haven't).

The purpose of the grey background in the title and margin is to indicate that these elements are outside of the page content area. The grey background in the table dilutes this graphical message, but serves no purpose. It reduces readability. Let's make it white, or at least lighter grey. —Michael Z. 2005-12-6 15:31 Z

By the way, Woodstone's statement "It is by no means an established fact that more contrast is more legibility" is patently false; accessibility guidelines always stress contrast, and less contrast is always less legibility. The W3C's Web Accessibility Guidelines require good contrast in images and text [1], and their Web Content Techniques document states "ensure that foreground and background colors contrast well".[2] —Michael Z. 2005-12-6 15:54 Z

One quote from higher up:

"Practically all word processor software and most well-designed web sites with long passages of text use pure black on white"

Indeed, but tables typically do not contain "long passages of text". The slighty less white background does serve the purpose of making the table (often containing a lot of "white" space) stand out as whole and separating it from surrounding longer stretches of text. The same device is used in the table of contents in the article and in many of the specialty boxes (country, city, song, ...).

White text on a black background also has maximum contast, but has by now been abandoned in most web design as not very readable. So there is more to readability than just maximum contrast. −Woodstone 20:45, 6 December 2005 (UTC)

"but has by now been abandoned in most web design as not very readable"—until you can back up this assertion with some evidence, I will strongly dispute it.

Tables do often include a lot of character info: columns and rows of words or figures, already harder to scan and read quickly than running text. They also often (including in this case) have unnecessary vertical or horizontal rules increasing the clutter. A box rule already sets off the table as "other content"—but a table is usually part of the document flow, and doesn't stand outside of it the way infoboxes, navboxes, etc. do. Given all this, the grey background is redundant over-formatting and needlessly reduces contrast. At least make the background lighter; perhaps #F8F8F8? (need a white background to see that correctly)

To compare, have a look at the following examples of tables, which are more attractive, and easier to read because they dispense with unnecessary tone and rules, but use them where they serve a function. In many cases, text weight and alignment convey much of the table structure on their own. Where tone and rule are present, they are as subtle as possible, to do their job but not compete with the actual table contents. In every case, these tables have less formatting than a "wikitable" and look and work better for it. Other editors have copied some of these formats for other articles and even other-language Wikipedias.

1. Ukrainian alphabet—Table of letters needs no formatting at all to stand apart.
2. Ukrainian alphabet#Letter names and pronunciation—This table uses tone only, and only bars for every three lines to help guide the eye across long rows. Horizontal alignment is sufficient to follow the colums.
3. Romanization of Ukrainian#Table of romanization systems—Similar to above, with horizontal centring.
4. BT tank—The infobox uses more colour to stand apart from the article flow, but still maximizes text contrast, while reducing the use of rules. Text alignment indicates the single vertical divider, and edges of toned areas delineate horizontal lines of varying depth. Colour also denotes heading and sub-headings.
5. BT tank#Specifications—Rows of varying depth require delineation. The only tone is very light #F8F8F8 to set off the header a bit.
6. T-34#Soviet medium tank models of World War Two—Every row is one line, so horizontal rules are not necessary. Therefore, a single line is sufficient to set off the header without any tone.
7. Soviet armored fighting vehicle production during World War II—Not much needed at all. In fact the German version successfully uses even less formatting.

Less is more, baby. —Michael Z. 2005-12-6 22:59 Z

I have some trouble believing you are serious about setting these tables as an example. Most "alphabet" tables also use (alternatingly) gray backgrounds (darker than wikitable). The "tank" tables are quite cluttered and hard to read. According to most style guides, if a table has no horizontal rules (borders), the text in them should never be centered. Text should be left aligned, numbers right aligned. Units should not be repeated, but with the row header or in a separate column. Furthermore there is no consistency among the styles of these tables. Consistency is one of the purposes of the wikitable style. −Woodstone 15:21, 7 December 2005 (UTC)

So you find the second example easier to read? —Michael Z. 2005-12-7 17:44 Z

Dimensions, road speed, engine horsepower did not vary significantly. References: Zaloga & Grandsen 1984, pp. 113, 184. Harrison 2002, p. 181.

	T-34 Model 1940	T-34 Model 1941	T-34 Model 1942	T-34 Model 1943	T-34-85	T-44
Weight	26 t	26.5 t	28.5 t	30.9 t	32 t	31.9 t
Gun	76.2mm L-11	76.2mm F-34	76.2mm F-34	76.2mm F-34	85mm ZiS-S-53	85mm ZiS-S-53
Ammunition	76 rounds	77 rounds	77 rounds	100 rounds	60 rounds	58 rounds
Fuel	460 L	460 L	610 L	790 L	810 L	642 L
Road range	300 km	400 km	400 km	465 km	360 km	300 km
Armour	15–45 mm	20–52 mm	20–65 mm	20–70 mm	20–90 mm	15–120 mm
Cost		270,000 rubles	193,000 rubles	135,000 rubles	164,000 rubles

[removed wikitable version with right-aligned numbers; the version below is better —Michael Z. 2005-12-7 21:45 Z]

I definitely find the second one easier to read. But you misunderstood one thing I said. Centering is disadvised when "no horizontal rules" are present. Since wikitable has rules (and within the columns dimensions are unequal) the numbers could have stayed centered. My preference would be like below. (Note that the original smaller characters also reduced legibility.) −Woodstone 21:28, 7 December 2005 (UTC)

Dimensions, road speed, engine horsepower did not vary significantly. References: Zaloga & Grandsen 1984, pp. 113, 184. Harrison 2002, p. 181.

	T-34 Model 1940	T-34 Model 1941	T-34 Model 1942	T-34 Model 1943	T-34-85	T-44
Weight (tonnes)	26	26.5	28.5	30.9	32	31.9
Gun	76.2mm L-11	76.2mm F-34	76.2mm F-34	76.2mm F-34	85mm ZiS-S-53	85mm ZiS-S-53
Ammunition (rounds)	76	77	77	100	60	58
Fuel (litres)	460	460	610	790	810	642
Road range (km)	300	400	400	465	360	300
Armour (mm)	15–45	20–52	20–65	20–70	20–90	15–120
Cost (rubles)		270,000	193,000	135,000	164,000

plainlinksneverexpand

It ain't working! When I print, it expands the external URLs. This is having a major effect in a few template:

• Template:Ref
• Template:Note
• Template:usc
• Template:usc-clause

Can someone fix this? - Ta bu shi da yu 08:08, 5 December 2005 (UTC)

Probably not. It works fine in Firefox and Mozilla, as well as screen output in IE. However, it fails on print output with IE, where the ref links are still expanded. Seems to have something to do with a bug in IE relating to multiple class names (see [3], [4], [5]): the ref links have class="external autonumber" set (i.e., they're in two classes named "external" and "autonumber"), and that seems to confuse the print engine of IE. I've tried using only "external" or only "autonumber" in the CSS, duplicating any version and wrapping explicitly in a "@media print" block, explicitly setting the content of that ":after" pseudo-element to the empty string; but to no avail. Lupo 12:30, 5 December 2005 (UTC)

Need diff colors that are compatible with color-blind people

Since a large portion of people are color blind in some sense, we should address this quickly:

(copied from User talk:Jimbo Wales)

---

Hi Mr. Wales, or Jimbo, which ever you prefer.

I'm just inquiring about a recent change in the edit thingy. When you enter into "History" of an article & then click on the "Compare Selected Changes" button, the changes were shown in dark red. But now they are hardly visible, & for an editor with colourblindness, it is quite hard to see what changes people have made to the article. Could you please supply me with an answer if this will be changed or remedied or if it will stay the same.

I would have posted this on the appropiate page, but I do not know of one, so selected you because you are the "Main Man" on Wikipedia I suppose.

Regards, Spawn Man 23:15, 7 December 2005 (UTC)

---

— BRIAN0918 • 2005-12-8 00:04

• I agree heartily, although I am not colour-blind. I would like it if changed characters could have a different background-color to make it easier, nay possible, to spot altered white-space. HTH HAND Phil | Talk 10:08, 16 December 2005 (UTC)

Sisterproject

Please change .infobox.sisterproject to be "width: 20em", which matches more closely how these were originally (which was 250px, but em is better). -- Netoholic @ 14:23, 15 December 2005 (UTC)

I actually prefer 250px. I know maybe absolute values aren't as good, but as an infobox, 250px works quite well unless the font is unreadably small or ridiculously large. It's just that many pictures are sized at 250px, and infoboxes directly below them at 250px looks very good. - Hahnchen 22:13, 15 December 2005 (UTC)

Specifying the size in em lets the user's local fontsize settings adjust the infobox. If you use px, you lock it into and makes the box impractical because the larger text is crammed into the same area. The VAST majority of sisterproject boxes are in the "External links" section - nowhere near images. Let's be kind to that segment of our readership that has special needs. -- Netoholic @ 22:25, 15 December 2005 (UTC)

I know that having 250px would be fixed no matter what the font size. But what I am saying, is that 250px is suitable up to quite a large font size. When it becomes unsuitable, hardly any text fits on the page anyway, and even those who use "large print" books would probably not use such a size. - —the preceding unsigned comment is by Hahnchen (talk • contribs) 22:51, 15 December 2005 (UTC)

250px is not suitable because it leads to a lot of excess word-wrapping at large font sizes. -- Netoholic @

I disagree, I tried to scale the text up earlier on the old edition of a sisterproject box, and even at 250px it scales quite well. - Hahnchen 03:07, 16 December 2005 (UTC)

I guess that em will have to be good enough - the difference is negligible. Your reason (matching with images) is not relevant enough to deviate from the extensive use of em on Common.css. If you really don't like it, you have the power to add .infobox.sisterproject { width: 250px; } to your personal stylesheet (see meta:Help:User style). -- Netoholic @ 04:31, 16 December 2005 (UTC)

Highlighting (wikitable) table rows

Seeing the edit http://en.wikipedia.org/w/index.php?title=List_of_The_Simpsons_episodes&diff=31567503&oldid=31556419 – where a hard-coded color is applied to every 2nd table row – earlier today made me think: "we need a standard color for highlighting stuff/text/table rows". How about adding

table.wikitable .highlight,
table.prettytable .highlight {
  background: #ececf6;
}

to this CSS. Then we might simply use

{| class="wikitable"
|-
| one row || one row
|- class="highlight"
| another || another row
|}

instead of the hardcoded colors? --Fred Bradstadt 08:39, 16 December 2005 (UTC)

I'm not a fan of this. It seems to narrow a usage, and I'd rather see us just leave that color choice up to the table author. -- Netoholic @ 14:17, 16 December 2005 (UTC)

Agreed. Wikitable is a css'ed version of {{prettytable}}, which originally had highlighting, too, through {{highlight1}}, {{highlight2}}, etc. Those should really be css classes that match with the user's skin, though, rather than hardcoded colors. — Omegatron 15:50, 16 December 2005 (UTC)

So are you proposing only red, blue, and gold highlights be added, or are we going to support the thousands of other possibilities that people may want to use? How many tables really are using highlights awyway? -- Netoholic @ 16:00, 16 December 2005 (UTC)

This must be a rhetorical question because obviously we aren't going to see thousands of classes created. There is nothing wrong with having one (or just a few) standard highlighting that people can use that goes well with the standard CSS style. And if someone feels he would rather go off and do something "funky" instead, he can do so (at least until someone else comes along and decides their idea of funky is better). —Mike 01:17, 17 December 2005 (UTC)

CSS for metadata

Per my Village Pump proposal, I'm going to be adding a bit of CSS to enable the creation of metadata (ala Personendaten in the German Wikipedia). This will allow us to try out some metadata schemes and hopefully implement some in the future. See this article for more info. Kaldari 19:27, 22 December 2005 (UTC)

BTW, if anyone's interested, I've set up the first metadata project at Wikipedia:Persondata. It's gotten a lot of positive feedback so far. Kaldari 19:56, 2 January 2006 (UTC)

CSS for navbars

See Template talk:Dynamic navigation box. Monobook contains the code missing in other CSS. -- User:Docu

I disagree with this change completely. You're using a template to perform a function which really should be added as a software feature. Templates should be used to replicate text among article, not change the fundamental navigation structure outside of the article body. -- Netoholic @ 19:31, 2 January 2006 (UTC)

That's nice. But a lot of templates are used as navigational aids (navboxes, etc). See for example, {{Street Fighter series}}. That the necessary code to make the show/hide buttons work isn't available in the other skins is something that should be rectified. —Locke Cole • t • c 19:42, 2 January 2006 (UTC)

Hiding and showing content is something that should be requested as a built-in to the software, where the Javascript code (currently in MediaWiki:monobook.js can be put through proper development practices, like CVS. -- Netoholic @ 20:01, 2 January 2006 (UTC)

Restoring missing stuff

I have restored the specifications for the date display templates which got removed for no reason explained in the Edit Summary. If this was a purposeful removal, then could whoever does it explain it here before doing it again, please? HTH HAND —Phil | Talk 08:16, 5 January 2006 (UTC)

Bug in Monobook.css?

As reported on Wikipedia:Village pump (technical)#Bug in Monobook.css there appear to be two errors in Common.css:

Unknown property 'filter'.
Error in parsing value for property 'line-height'. 

Also, this may be completely unrelated, but my Firefox fails to display certain images while IE is able to display them (cache cleared, control-shift-R tricks all tried in vain):

• Image:Reflection_nebula_IC_349_near_Merope.jpg [6]
• Image:Reflection_nebula_IC_349_near_Merope_full.jpg [7]

Most other images are fine, and IE seems Ok with these. -Wikibob 03:54, 13 January 2006 (UTC)

Both errors were from the experimental main page stuff. I went ahead and changed the line-height:auto since it wasn't valid CSS. The filter thing is an IE only special deal. Should we keep it or scrap it? Kaldari 04:19, 13 January 2006 (UTC)

As for the images, check if you aren't using a misconfigured ad blocker. The first one has /ad/ on its URL, which is often indiscriminately blocked. --cesarb 04:51, 15 January 2006 (UTC)

Yes, the IE filter thing keeps popping up in my js console. Can you hide it from non-IE browsers? Apparently this recalc thing does it? — Omegatron 01:48, 18 January 2006 (UTC)

CSS hack reduces accessibility

I just learned about the CSS hack being added to a number of templates, to compensate for a changed policy on template transclusion. I understand that there is an alternative way of recoding these templates, but the CSS hack is being implemented because its easier. Main discussion on this is at Wikipedia talk:No meta-templates. Please make your opinion heard there.

This hack injects junk code into the body of the page, then hides it from most visual browsers using CSS. The following line in common.css is being used to hide this code in template:Journal reference, template:Taxobox, and many others:

 /* hiddenStructure from Monobook - allows selective hiding of markup in templates */
 .hiddenStructure {
    display: none;
 }

This makes Wikipedia less accessible for users of assistive technologies, like web page readers for the handicapped, and text readers. This is sloppy programming and bad practice from the point of view of web page accessibility, web page usability, and standards implementation. Wikipedia is an open encyclopedia; please lets not start treating the minority who has the most difficult time reading like second-class citizens. —Michael Z. 2006-01-16 17:51 Z

Michael- I am concerned about accessibility myself, and a while ago I started to document some good practices at Wikipedia:Accessibility. Specific to this "CSS hack", we can add "speak: none;" to hiddenStructure. I think that addresses your concern. -- Netoholic @ 19:05, 16 January 2006 (UTC)

I would disagree—I don't think this would cover all situations; definitely wouldn't work in a text-only browser like Lynx. "Hidden structure" is just that: structure that shouldn't be there—hiding it with CSS is an ugly hack. I must run now, but I will come back to put a more thoughtful 2¢ in. —Michael Z. 2006-01-16 19:15 Z

Hiding structure with CSS is a very common practice, and our specific use is even a little elegant. As far as the argument about the lynx browser, you're a little late as it's been discussed before. Lynx/Links browsers make up fewer than 0.03% of the readers here. What should be done is to avoid using too many optional parameters in any template, but there really aren't anymore hard-core lynx users, so I think the argument is a straw man. -- Netoholic @ 19:25, 16 January 2006 (UTC)

"Elegant?" You can't be serious. Your code can't produce the right HTML, so leave the cruft in, then use CSS to hide it. This is not elegant, it's bush league.

So 0.03% of users of one of the world's busiest web sites are insignificant? Lynx is an open source browser with just about the most compliant HTML engines available. You think that the web page breaking in Lynx is an "elegant use"? Are blind readers an insignificant minority in your opinion too?

And all of this when the weeble solution would work? Amateurish and unworthy. —Michael Z. 2006-01-16 19:46 Z

The HTML/CSS is just fine. All we are doing is outputting the name of a CSS class that doesn't exist, which is acceptable under CSS validation. Lynx/Links users were 0.03% in February 2004. If you extrapolate over time and assume that several people use lynx just to test what the site looks like under lynx, it's far fewer real users. Also, those that use lynx know and expect that they are losing functionality. You want to know a better solution altogether? Don't use templates for references on a permanent basis. -- Netoholic @ 20:00, 16 January 2006 (UTC)

Netoholic, Would you remove occurences of "|if=" on template calls if you see them or would you let us live with the weeble variant. Michael announced that he would remove any call to templates that use the CSS on pages which he has a major interest. How about you in the CSS camp? Do you intend to abolish any occurence of weeble on sight or would you let us live with weeble. Note: weeble code does not violate WP:AUM. So with weeble we can both satify your beloved WP:AUM and Michael. Weeble does not violate anything (besides your preference) so this is a simple content dispute on templates. --Adrian Buehlmann 21:42, 16 January 2006 (UTC)

I am confident that in the long run, people will much prefer CSS over that odd weeble method. CSS makes the template itself pretty to edit, and has lead to a lot of interesting applications because of that. I won't systematically remove all occurences of it, but I ask that you not make such a change to any template such that you have to go out and add "if=|" to pages. -- Netoholic @ 22:21, 16 January 2006 (UTC)

Ok then. But this is the same because we cannot work against you on templates as it is pointless to revert you. So if you insist on CSS on journal reference (and others) we have only the option watching Michael removing calls to journal reference. And this is anyway what you prefer right? Damned. Everywhere is somebody against something. Goodby citation templates. --Adrian Buehlmann 22:34, 16 January 2006 (UTC)

With respect, why do you need citation templates? Citation styles are not about to change over time, are they? They should be inserted in plain text, by preference. I have even written a tool to aid this [8]. If people appreciate it, I can extend this to other templates. [[Sam Korn]] 22:36, 16 January 2006 (UTC)

In fact we do not need any template. We can always insert everything "by hand" in any article. If this is the consensus (for citation templates), ok then. --Adrian Buehlmann 22:52, 16 January 2006 (UTC)

"The HTML/CSS is just fine"—Netoholic, it is not fine. The literal text of the HTML page contains meaningless junk, generated because you can't control the output of a template! You can't justify that by saying some browser is used by some tiny minority. This contravenes word and spirit of the Web Content Accessibility Guidelines [9], including the two main themes "graceful transformation" and "understandable and navigable content", and guideline 3 "Use markup and style sheets and do so properly", guideline 9 "design for device-independence", and especially checkpoint 6.1 "Organize documents so they may be read without style sheets". The last is a priority 1 checkpoint—ignoring it means that Wikipedia will fail the most basic standard of accessibility.

"Don't use templates for references on a permanent basis"—perhaps that is the best solution. The old meta-templated templates could be subst-ed, as a shortcut method to create good clean HTML citations. —Michael Z. 2006-01-16 23:13 Z

Comment: Templates that contain a call to qif cannot be substed. --Adrian Buehlmann 23:25, 16 January 2006 (UTC)

CSS solution only works where CSS is available. The non-CSS camp can produce a WP for HTML conforming user agents and robots. The CSS hack camp needs HTML+CSS conforming agents. Download of data dump is not longer all - you also need to download and implement WP-CSS. Easy use / openess of WP is reduced by the CSS hack. Tobias Conradi (Talk) 23:01, 16 January 2006 (UTC)

This is not a good idea. The whole point of CSS is to make multiple "text-only" versions of web sites, for accessibility reasons, unnecessary. CSS is meant to style an HTML page, which should be completely understandable without it. The problem here is that Netoholic can't control the output of these templates, and they add junk content into the HTML. Then he layers CSS on top of it to hide the junk from some browsers. This is not just a hack, it's an ugly hack, which breaks W3C guidelines for accessibility in ways not previously imagined. —Michael Z. 2006-01-16 23:41 Z

You're becoming very repetitive, and not very informative. "junk content into HTML" - I have no idea what you mean by that at all. Your concerns are better addressed by making sure use of the CSS method is done minimally and selectively, but we gain nothing by ignoring the potential it brings. Sounds like you need to take up specifice concerns on the specific templates you're worried about, because I don't even think I could put a cap on hiddenStructure usage now. It's out there, it works well for our needs. -- Netoholic @ 01:40, 17 January 2006 (UTC)

You have no idea? "Junk content" is all the stuff you hide from visual browsers with CSS. For those who haven't seen it, examples of the actual output are at template talk:Infobox Language.

I have considered the 'potential' of this method to allow you to write more templates which indiscriminately output crap, and then add more code to hide it from most non-handicapped readers. My specific concerns are this fundamental flaw with the method and concept behind it.

Below is an excerpt from the output of Netoholic's proposed language template. Full output at the link above. This is not the wikicode, but the actual text that a handicapped reader might have to listen to before he got to the start of the article. —Michael Z. 2006-01-17 01:51 Z

  Language codes                                                               
  ISO 639-1: en                                                                
  ISO 639-2: eng                                                               
  ISO/DIS 639-3: eng --                                                        
  {{{lc1}}} -- [[{{{ll1}}}|{{{ld1}}}]]                                         
  {{{lc2}}} -- [[{{{ll2}}}|{{{ld2}}}]]                                         
  {{{lc3}}} -- [[{{{ll3}}}|{{{ld3}}}]]                                         
  {{{lc4}}} -- [[{{{ll4}}}|{{{ld4}}}]]                                         
  {{{lc5}}} -- [[{{{ll5}}}|{{{ld5}}}]]                                         
  {{{lc6}}} -- [[{{{ll6}}}|{{{ld6}}}]]                                         
  {{{lc7}}} -- [[{{{ll7}}}|{{{ld7}}}]]                                         
  {{{lc8}}} -- [[{{{ll8}}}|{{{ld8}}}]]                                         
  {{{lc9}}} -- [[{{{ll9}}}|{{{ld9}}}]]                                         
  {{{lc10}}} -- [[{{{ll10}}}|{{{ld10}}}]]                                      
  {{{lc11}}} -- [[{{{ll1}}}|{{{ld11}}}]]                                       
  {{{lc12}}} -- [[{{{ll2}}}|{{{ld12}}}]]                                       
  {{{lc13}}} -- [[{{{ll3}}}|{{{ld13}}}]]                                       
  {{{lc14}}} -- [[{{{ll14}}}|{{{ld14}}}]]

That seems to be, again, a concern about a specific template. And please stop with the handicapped issue, if I was an admin, I'd add "display: none;" immediately. That ends your argument completely because there are no screen readers that ignore CSS. Lastly, that visible text is not "junk HTML" (a phrase that implies the HTML is invalid or against standards). -- Netoholic @ 02:08, 17 January 2006 (UTC)

Display:none doesn't remove content from a web page, it just hides it from certain web browsers. Sorry, not "junk HTML", junk text in the HTML, plus some HTML span elements specifically generated to hide the junk.

How do you know there are no such screen readers? How do you know that one won't be released tomorrow? Using CSS to hide content which was "accidentally" added to a web page breaks WCAG priority 1 accessibility, as I explained above. Ignoring this is totally contrary to Wikipedia's "open" philosophy, and is just a shoddy way to build web pages. —Michael Z. 2006-01-17 02:10 Z

I believe Blynx (being a Lynx derivative for Blind people) has no support for CSS MrWeeble Talk Brit tv 15:29, 17 January 2006 (UTC)

Comment: just an example for what the CSS trick does on the html of Royal Welch Fusiliers:

<tr class="hiddenStructureExpansion of the Army to oppose James II and the imminent war

with France. Originally the 23rd Regiment of Foot; it became the Royal Welch Fusiliers in 1713 as a reward for great gallantry under Marlborough."> <th>Reason for creation</th> <td>Expansion of the Army to oppose James II and the imminent war with France. Originally the 23rd Regiment of Foot; it became the Royal Welch Fusiliers in 1713 as a reward for great gallantry under Marlborough.</td> </tr> Long class name that. --Adrian Buehlmann 17:46, 17 January 2006 (UTC)

Ew. — Omegatron 20:41, 17 January 2006 (UTC)

A class attribute contains a space-delimited list of classes, so this is a serious problem. For example, depending on the content of such a note, parts of the page could arbitrarily be put into the existing classes in monobook.css and common.css: .selected, .thumb, .error, .external, .text, .notice, .metadata, .messagebox, .infobox, .bordered, .IPA, .Unicode, and .polytonic. There may also be a limit to the number of characters allowed in a class attribute. —Michael Z. 2006-01-17 21:07 Z

This is only the case where the parameter contains un-wiki-linked words or phrases. HTML Tidy strips out the entire class= statement. See the page source of Royal Welch Fusiliers after I made this change. -- Netoholic @ 01:39, 18 January 2006 (UTC)

Which is now:

<tr> <th>Reason for creation</th> <td>Expansion of the Army to oppose <a href="/wiki/James_II_of_England" title="James II of England">James II</a> and the imminent war with France. Originally the 23rd Regiment of Foot; it became the Royal Welch Fusiliers in 1713 as a reward for great gallantry under Marlborough.</td> </tr>

Looks good now. --Adrian Buehlmann 15:20, 18 January 2006 (UTC)

That's a workaround for this particular case, but the CSS hack used in this template and others still risks unexpectedly breaking page rendering in any occurence. —Michael Z. 2006-01-18 22:06 Z

Changed Template:Infobox British Army regiment to use updated CSS trick. No more random CSS classes, only "hiddenStructure". Nothing else. --Adrian Buehlmann 22:08, 20 January 2006 (UTC)

Why Not Weeble?

Can anything be done using the CSS hack that can't be done with the "weeble" method? Superm401 | Talk 09:26, 17 January 2006 (UTC)

Weeble needs an additional artificial parameter with name "if" that must be defined and empty on each call of a template that uses the weeble trick (written as "|=if"). --Adrian Buehlmann 10:13, 17 January 2006 (UTC)

So what "can't be done" with the 'Weeble' method (which has actually been around for a while... Template:If defined uses it) is to convert many templates to non-meta forms without changing the template calls. That being said... for alot of the more complicated templates the calls are being changed anyway. In such cases I think we should use Weeblecode since it's biggest drawback (having to update each call) is required anyway.

Another option would be to decide that a few 'meta' aspects are 'ok'. If we can get rid of all the 'Boolean' and 'If' templates then is it really such a threat to have a few double transclusions that get used on a couple hundred pages? I don't think so and I don't think there will ever be a way to eliminate such. If some basic double transclusions are allowed then the '|if=' calls can be made in the top level templates... causing no change to many template calls. For instance, if Template:Language were changed to call Template:Infobox language, Template:Infobox Conlang, or Template:Infobox Sign language, depending on the type of language, then the calls to 'Language' on various pages could remain unchanged, the '|if=' conditions could be set in 'Language' before calling the sub-templates, and the different language templates could be customized more. This might also reduce load from changes by splitting out into sub-templates. However, it'd be a 'meta' (more accurately 'nested') template. Just barely, as it's only double transclusion, but others of this sort have recently been proclaimed 'anathema'... though many many more have been ignored / left in place. I think this is really the best solution currently available, but is it possible in the face of the 'meta-template jihad'? --CBD _☎ ^✉ 12:10, 17 January 2006 (UTC)

That method first of all require 4 templates when 3 will do, just change the articles to call the right template (it's easy). Your suggestion also breaks the intended purpose of Whatlinkshere. What is so damn hard about manually keeping these three templates looking alike? By splitting the templates, we can remove A LOT of the extraneous optional parameters, which cleans up the HTML source. -- Netoholic @ 20:42, 17 January 2006 (UTC)

I personally have nothing against weeble as we have now very strong opposition against CSS which only leaves the "remove calls" option on my beloved template book reference. BTW, does anyone of the experts know what google does for example with <tr class="hiddenStructure"><th>Died</th><td><br /></td></tr> as can now be found in the html source of GWB (see also below)? --Adrian Buehlmann 12:25, 17 January 2006 (UTC)

Why do book references need templates? They're not going to change. It seems to me unnecessary to use ugly (and they are ugly) methods when you can use simple, clean ones. You can insert the reference in plain text. Difficult? I don't think so. [[Sam Korn]] 20:48, 17 January 2006 (UTC)

You are welcome to express your opinion on template talk:book reference. I have asked there how to proceed with that template. --Adrian Buehlmann 21:40, 17 January 2006 (UTC)

Change request

Could some admin please change

/* hiddenStructure from Monobook - allows selective hiding of markup in templates */
 .hiddenStructure {
    display: none;
 }

to

/* hiddenStructure from Monobook - allows selective hiding of markup in templates */
 .hiddenStructure {
    display: none;
    speak: none;
 }

As proposed by Netoholic above? Example: look at the html code of George W. Bush. You will find there:

<tr class="hiddenStructure">
<th>Died</th>
<td>{{{death_date}}}<br /></td>
</tr>

Due to the CSS trick used in template:Infobox President. Would be good if "Died" would not be spoken out on that article (especially not on that article). --Adrian Buehlmann 10:26, 17 January 2006 (UTC), Updated --Adrian Buehlmann 22:55, 17 January 2006 (UTC)

Is it possible to simply remove the word "died" from the article about George W. Bush, instead? —Michael Z. 2006-01-17 16:08 Z

That word comes from the transclusion of the template template:Infobox President into that article. The html snippet I presented origins from that transclusion. If you remove that transclusion, then that word is removed (but also the infobox). Hmm, I strongly think I didn't get what you mean... --Adrian Buehlmann 16:20, 17 January 2006 (UTC)

I meant: can the template be fixed so it doesn't insert unintended words or field names into the page? This could be a problem for Google or other search engines. —Michael Z. 2006-01-17 21:10 Z

I try to be short: with weeble code, that would be possible (rejected by Phil Boswell and Netoholic). With qif it was no problem (to be killed soon with an axe by David Gerard or Snowspinner and lots of others). With conditional templates in MediaWiki it would be plain kindergarten (devs fear "wiki viruses", said "kill if/qif with a stick"). So the answer is: NO. As I already said: remove the template (option of last resort). --Adrian Buehlmann 21:54, 17 January 2006 (UTC)

Just for a note: I dislike the CSS hack too (won't reiterate the reasons already listed above.) I'm not active in English Wikipedia, but I work in Russian section and recently we are having a massive introduction of CSS hack copied from English. I personally think I'll just stick with qif in my templates for a while, since Russian Wiki is not that large. I really hope conditionals are introduced into the wiki syntax soon so that we don't have to choose between an ugly hack solution (CSS), a slow hack solution (meta-templates) and an iconvenient hack solution (Weeble.) -- Paul Pogonyshev 21:28, 20 January 2006 (UTC)

Obviously, this change is beneficial, whether you like the hiddenStructure method or not. -- Netoholic @ 20:44, 17 January 2006 (UTC)

Despite my antipathy towards the system, I have changed the style as requested. [[Sam Korn]] 20:51, 17 January 2006 (UTC)

I just had a look at "George W. Bush" using Lynx. The entire article displays perfectly, except the infobox ({{Infobox President}}) renders like this (note "Died"):

CAPTION: George W. Bush

Order 43rd President of the United States
President from January 20, 2001 - present
Vice President Dick Cheney
Preceded by Bill Clinton
Succeeded by incumbent
Born July 6, 1946
New Haven, Connecticut
Died
Political party Republican
Spouse Laura Welch Bush
                                                                               

And several instances of {{main}}, looking something like this:

Main articles: Early life of George W. Bush, and Professional life of George W. Bush, and [[]], and [[]], and [[]]

Both are breakages of the actual content of Wikipedia, and both caused by using the CSS hack to compensate for faulty output of templates. —Michael Z. 2006-01-18 00:34 Z

If I would get a license to do so, I would convert template:Infobox President to weeble (am thinking about doing a mockup under my user space). But as long as I get oppositon from that prominent people I can't do anything. Especially Neto (with his big license plate) would revert me within milliseconds. --Adrian Buehlmann 10:37, 18 January 2006 (UTC)

Something you could do is in the template instead of blank text ie {{{death_date}}} try and add some text that exlains that he is still extant ie {{{death_date|Still alive [[as of 2006]]}}} which would result in:

Died: Still alive as of 2006

Not particularly nice way of doing it, but at least it would avoid confusion as to his current status.

<sarcasm>Of course, we could just shoot him, might be the easiest solution</sarcasm> – MrWeeble Talk Brit tv 10:57, 18 January 2006 (UTC)

Adrian, I would support replacing any CSS hack template with a weeble version. It's been implied that the weeble version's template code is not as pretty, or not as flexible or something, but I haven't actually seen why it's opposed. Given the problems already demonstrated for the other method, don't you think we could find consensus for the version that actually works? —Michael Z. 2006-01-18 22:09 Z

The only clear drawback I see is that additional |if= parameter on calls (sorry for constantly repeating this). I haven't seen any other technically based arguments against weeble so far, so I do not know too why weeble is attacked that heavily. Ok it is another "hack" solution, but only until we have a conditional in MediaWiki. You are not alone against the CSS hack, I think Garzo and the group around template:language is also headed towards weeble based on similar arguments as you brought here. My problem is that Phil Boswell obviously wants to wait onto the "real" solution (conditionals in MediaWiki) and Netoholic simply revert wars any template with weeble. Given that I personally follow a zero-revert rule towards edits of Neto, I'm pretty much blocked (see also Neto's actions on template:language and Wikipedia:Administrators' noticeboard/Incidents#Inappropriate page move protection by User:Radiant!. He has pretty much a license to do anything. I would go with weeble in order to get you on board. I see nothing wrong with weeble. It's quite frustrating all this WP:AUM terror. But we can't ignore WP:AUM because we get shot sooner or later. --Adrian Buehlmann 22:25, 18 January 2006 (UTC)

I must add that for template:Infobox President I tend to weeble anyway because of these texts in the html source ("died"). So for Infobox like stuff, I would prefer weeble. For the citation templates it is not that bad to use the CSS hack because there are not such dangerous texts to hide. --Adrian Buehlmann 22:37, 18 January 2006 (UTC)

What happens if the |if= parameter is omitted or mistyped? Do trivial mistakes like typing an extra space break the template?

Having to type that is far less of a problem than the several drawbacks already discovered for the CSS hack. The danger of adding unexpected random classes into class attributes in particular could have all kinds of unpredictable results: definitely breaks accessibility, definitely could break page layout, might be able to break standards compliance, might adversely affect a browser's HTML parser by adding dozens or hundreds of classes to one or more HTML elements. These confirmed, probable and possible adverse effects on readers of Wikipedia far outweigh the burden on an editor of having to type four extra characters into a template once. —Michael Z. 2006-01-19 00:12 Z

Ops. I'm a bit late responding here. Just in case you havent seen: take a closer look at my doc about the Netoholic variant (aka CSS trick). Netoholic invented a new way so that only the class "hiddenStructure" is used. Nothing else. So there aren't any random CSS classes any more. Please note that the CSS trick might get replaced by something better in the future (possibly MediaWiki code). It's certainly not meant as a definitive solution. --Adrian Buehlmann 21:45, 20 January 2006 (UTC)

Thanks, but I still don't know if the only objection to the "weeble" method is the necessity of adding the |if= parameter. In what way does it break if the parameter is omitted or incorrectly typed? —Michael Z. 2006-01-22 22:08 Z

If the blank '|if=' parameter is not included then the conditional logic fails and displays the text automatically... essentially it winds up looking like the 'hiddenStructure' trick does on non-CSS browsers. That being said, as the 'weeble' method becomes more common the likelihood of the '|if=' parameter being ommitted decreases. I really think this method is inherently superior to the CSS hack and even many current meta-template implementations. The only significant drawback is that existing template calls would have to be updated. I've been using it with newly designed templates (see Template:User Infobox) and as part of internal meta-template calls (see how Template:Language calls Template:Language/genetic). In the first case many people, several of them 'newbies', have used the template and had no trouble understanding and including the 'if='. In the second case the extra 'if=' parameter is set inside the top level template (getting rid of extra calls to qif and switch in the process) and the change was effectively invisible to the users. --CBD _☎ ^✉ 22:30, 22 January 2006 (UTC)

Given the newest statments from Brion VIBBER on WP:AUM we might even consider waiting until the conditional support has been added to MediaWiki and continue using qif in the mean time. So I would recommend waiting a bit what happens around Brion on that matter before we are going to do (or continue) a lot of useless work. WP:AUM is no longer a policy. See also Wikipedia talk:Avoid using meta-templates#What I need from you. --Adrian Buehlmann 00:23, 23 January 2006 (UTC)

Tables inside frames

Smile attack

There are uses for tables of images inside frames, but the css doesn't work with them, since it puts a border around every image instead of around the table as a whole. {{Float begin}} handles this in a kludgy way, but better ones would be nice. One possible solution is to add:

div.thumb div table a img {
	border: 0;
}

div.thumb div table {
	border: 1px solid #ccc;
}

Then I would modify float_begin to use the code in the above example. This will remove the border around images inside tables inside thumbnail frames and put the border around the table instead. There are other solutions, I'm sure, like using a div with a border so that you can put anything inside a frame, instead of just tables, but this would work for now. Can it be added? Are there any conflicts? — Omegatron 18:18, 20 January 2006 (UTC)

I don't see where this is necessary enough to make a site-wide change to some pretty widely used CSS classes. It could cause conflicts later. You could either combine the smaller images into a larger one, or just kludge it for the few occassions it seems to be used. Take this example, where I put the information into a table using no templates and very little styling. -- Netoholic @ 21:28, 20 January 2006 (UTC)

Your kludge is just as bad as the one currently in use. Adding to the css won't break anything and will provide a valid implementation.

Another alternative is to create a new div.framed or div.framedtable class instead of reusing in addition to the div.thumb class, if you're really worried about future css conflicts. — Omegatron 22:46, 20 January 2006 (UTC)

CSS hack reduces accessibility, confirmed

Netoholic wrote "And please stop with the handicapped issue, if I was an admin, I'd add "display: none;" immediately. That ends your argument completely because there are no screen readers that ignore CSS". But please see template talk:Main#Strange output; there's already a blind editor using Jaws (the most common screen reader) adversely affected by the CSS hack. —Michael Z. 2006-01-22 22:03 Z

Yes, I am affected: {{main}} is the place where I notice it the most.

Thanks for bringing this up here. And I personally do appologize for being one of those who have been adding that CSS hack to templates and thus indirectly to articles. Until recently we had a policy (WP:AUM) that mandated the removal of a technical solution which was deemed to be bad for the servers. Instead of working for a decent technical solution we went mad and put up the CSS hack because some of us had the opinion that this would be ok as a stop gap measure in order to avoid the removal of templates from articles. It all boils down to that we were told to no longer use templates in templates and especially not template:qif which was put up as a temporary solution until we have conditional logic support for templates in MediaWiki software (which we are still desparately waiting for). That qif produced decent html (also for your screen reader and all non-CSS browsers), but had been announced for removal by important Wikipedians due to ugliness, fragility and server strain. The result is now that the consensus (as established by the actual Wikipedia consensus-finding capabilities) was to replace that qif with the CSS hack, thereby ignoring people like you, based on reason that users like you are a small minority of users and that we should thus no longer support non-CSS browsers. Note however that there was and is a significant fraction of wikipedians who think that this CSS hack should not be used. There is another technical solution for conditional logic in templates (called weeble trick) that also produces decent html but which was refused to use by important participants in this anti-templates-in-templates crusade because it needs an additional artificial paramter that must be named "if" and be defined to be empty on every call to a template that uses the weeble trick. Now to all Wikipedians: do we want to ignore people like the person here who said she/he has problems reading Wikipedia articles caused by the CSS hack? I would appreciate if we could either stop the removal of qif calls until we have support for conditionals in MediaWiki or use the weeble trick which at least produces decent html. Thanks to all for your careful consideration. Sorry for being verbose once again. --Adrian Buehlmann 08:36, 23 January 2006 (UTC)

Given recent statements from Brion that meta-templates are not a major server problem and that they are looking at ways to allow conditionals in MediaWiki I'm all for wiping out the CSS hack entirely. There is no longer any reason for it. Maybe it improves server performance slightly while we are waiting for 'built in' conditional logic, but that's not worth the accessibility problems. I'd say use 'weeble' if it can be done easily or just go back to 'qif' otherwise. --CBD _☎ ^✉ 11:47, 23 January 2006 (UTC)

I've just found out that the template works fine in jaws 6.0, so it would probably work fine in all versions after that. However, it's a paid upgrade for me, and many would have a good reason to use versions of jaws below 6.0. They use a more flexible authorisation scheme, have an easier-to-use directory structure, and are generally more responsive on slower computers. Therefore, I would strongly recommend that the css hacks not be used because there will be a sizable number of people using older screen readers, and they may not be able to upgrade. Graham/pianoman87 talk 05:08, 23 January 2006 (UTC)

From freedom scientific

Ok, this is what the Freedom Scientific site says about CSS with earlier versions of jaws. Feel free to refactor this if necessary. This applies to jaws 5.1 and earlier. For the whole web page, see [10]. Refreshing with insert+escape shortcut mentioned did not work on wikipedia. I have found out that diff links will also display better in later versions of jaws, so I, personally, will upgrade.

The text is as follows:

Q. Does JAWS support cascading style sheets (CSS)?

A. Yes, JAWS does support cascading style sheets (CSS). CSS is a way of marking up text using styles that are inherited by applying a set of style rules to a page without having to change the actual page content. For example, you can link an HTML document to a style sheet that displays all level one headings in red. There are some issues that authors of Web pages should be aware of when using CSS to ensure the page is accessible.

When a page loads and JAWS processes the HTML code, it also processes linked and inline style information to determine which elements should be rendered. Any elements that use a style with the attributes "visibility:hidden" or "display:none" are not included in the JAWS rendering of the page. However, if the page has elements shown when it first loads, but then dynamically hides these elements without user intervention after the page loads, JAWS does not detect that this has occurred and may still show the hidden content. Conversely, if a page hides content when it first loads but then dynamically shows this content after the page loads, JAWS does not announce the new content.

The safest course of action when developing Web pages is to hide anything in the HTML when the page first loads that should not be shown. Then, only hide or display content when the user interacts with the page (such as by clicking a link or item with the onClick attribute). When the user clicks text, links, images, and so on, JAWS asks Internet Explorer for the HTML again, and updates the page.

A JAWS user can press INSERT+ESC to refresh the page content in the virtual document. However, the source that is passed to JAWS by Internet Explorer should represent the current visible state of the page. This does not occur if the HTML source code does not reflect the true visibility status because of scripting. If that is the case, JAWS still does not have an accurate view of the document.

JAWS uses style information to try to determine the font name, font size, font attributes, colors, and text alignment. This information is provided to the user when he or she presses INSERT+F.

Other than visibility and text attributes, style information is not interpreted any further. JAWS does not indicate zIndex levels. --—The preceding unsigned comment was added by Pianoman87 (talk • contribs) 10:03, 23 January 2006.

Thank you for the information, and it's good to hear that the CSS hiddenStructure method does work with the most commonly-used screen reader. The method was originally used on Infobox templates only, where hiding a few rows which didn't have data was a convenience. For other uses of conditionally displaying information, as a group, we need to be smarter about developing good, simple solutions rather than "clever" ones. -- Netoholic @ 11:38, 23 January 2006 (UTC)

Please note that screen readers and other web browsers are not required to use CSS at all, and other ones may very well ignore it. Also note that main.css is loaded by a style element containing the attribute media="screen,projection", so it should be ignored by screen readers, and consequently the CSS cascade will be different for screen readers which respect the media attribute.

The gist of this is that we can't possibly know how every single browser, screen reader, and search engine will process pages. Therefore, we should follow HTML and CSS standards, accessibility guidelines, and good authoring practices, and not just ignore or pay lip service to them. —Michael Z. 2006-01-23 15:10 Z

Ignoring css?

I can now confirm that both common.css and monobook.css are ignored in jaws versions below 6.0. This has other implications besides conditional statements. For example it makes interpreting diffs and distinguishing red links more difficult, because even the colour check commands do not work. The only thing the jaws 6.0 new features has to say relating to this is that "JAWS also features improved performance while you are reading complex Web sites." [11] The FAQ for jaws 5.0 did say that css was supported, though.

What could be causing this, and is there any way to fix it? Or maybe this is just another reason to upgrade, along with the fact that Firefox is supported. That's another 350 dollars or so out the window ... Graham/pianoman87 talk 15:28, 23 January 2006 (UTC)