MediaWiki talk:Common.css/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

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://wiki.riteme.site/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 — Omegatron 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. — Omegatron 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. — Omegatron 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.  :-) — Omegatron 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. — Omegatron 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? — Omegatron 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: — Omegatron 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. — Omegatron 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. — Omegatron 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. — Omegatron 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.  :-) — Omegatron 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? — Omegatron 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.  :-) — Omegatron 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? — Omegatron 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. — Omegatron 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://wiki.riteme.site/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)

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://wiki.riteme.site/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)