MediaWiki talk:Common.css/Archive 5

.spoiler
I just noticed that the spoiler class is still here. Can this be removed now? --- RockMFR 22:43, 10 June 2008 (UTC)


 * I don't know anything about that class, but anyway: Perhaps you should ask the people over at Bot requests to run a search to see if it is still used? That is, to do a full search on a copy of the database.
 * --David Göthberg (talk) 19:21, 12 June 2008 (UTC)


 * Doesn't look like a job for bots, or even for Query_service. One possible way to check is to download a dump and then do a search. —AlexSm 20:09, 12 June 2008 (UTC)


 * Smotrov: Right. Just as I stated above, such a search should be done on a dump, not by a bot. And a good place to ask for that is over at Bot requests. Since there are people over there that regularly do such searches, thus they already have downloaded dumps and the tools and expertise to do such searches. That seems to be a pretty common thing to ask for and get help with at that page.
 * --David Göthberg (talk) 20:31, 12 June 2008 (UTC)

None of them actually use  in CSS, it's either matches the name of the domain (www.spoilerfix.com) or is discussion about the class. All namespaces search using enwiki-20080524-pages-articles.xml dump, results may be skewed as I limited to 3 million pages and case sensitive. — Dispenser 01:49, 13 June 2008 (UTC)
 * 1) Spoiler (aeronautics)
 * 2) Surprise (Buffy episode)
 * 3) Big Bad
 * 4) List of Supernatural episodes
 * 5) List of characters in Heroes
 * 6) Interfaces/Internal interfaces
 * 7) Pat Zartman
 * 8) Wikipedia:Requests for comment/Policies/Wikipedia:Spoiler warning/Proposals to hide spoilers
 * 9) Templates for deletion/Log/2007 November 8
 * 10) WikiProject Spam/LinkReports/spoilers.es
 * 11) Village pump (technical)/Archive 8
 * 12) Village pump/Archive index
 * 13) In Buddy's Eyes
 * 14) Hello, Little Girl
 * 15) Sunday (Desperate Housewives)
 * 16) Opening Doors
 * 17) Wikipedia:WikiProject Transwiki/MediaWiki:Common.css


 * Thanks Dispenser. So it seems RockMFR can go ahead and remove that class from Common.css. Could you do a search for "Talk-Notice" too? (See next section.)
 * --David Göthberg (talk) 03:57, 13 June 2008 (UTC)
 * Unfortunately, I do not have the complete pages dump. The larger size (double) is a detractor for most practical uses. — Dispenser 03:25, 15 June 2008 (UTC)

.Talk-Notice
Talk-Notice was deprecated almost 3 years ago. Can this be removed now? --- RockMFR 01:18, 11 June 2008 (UTC)


 * See my response/suggestion at the .spoiler section above.
 * --David Göthberg (talk) 19:23, 12 June 2008 (UTC)

Any last objections to removing these? --- RockMFR 02:38, 23 June 2008 (UTC)
 * Both now removed. --- RockMFR 20:40, 24 June 2008 (UTC)

Removal of -webkit-column-count
It seems rather silly to remove this line when it will only cause a possible detriment and offers absolutely no benefit. Older versions of Safari (and possibly other WebKit browsers) that used the -webkit property will be damaged while nothing is gained. Is there any particular reason to not revert the change? --MZMcBride (talk) 04:22, 29 June 2008 (UTC)


 * According to Net Applications, the older versions of Safari that do not support column-count are no longer used, or are used only rarely. Thus, there's no need to clutter the common CSS file with declarations that won't be used. —Remember the dot (talk) 04:29, 29 June 2008 (UTC)


 * On the other hand, the CSS file was 26,885 bytes and now it's 26,856 bytes. There's plenty of redundant / excessive code on the page, but removing a single line to 'prevent clutter' while also removing functionality (if only rarely used) seems a bit silly. Oh well. --MZMcBride (talk) 04:35, 29 June 2008 (UTC)
 * Actually, Webkit (fortunately) doesn't support column-count. Please revert. —Ms2ger (talk) 12:07, 29 June 2008 (UTC)


 * Red information icon with gradient background.svg Not done: please establish a consensus for this alteration before using the template. Cheers, PeterSymonds  (talk)  13:44, 29 June 2008 (UTC)
 * There was no form of consensus for the removal. This argument is void. —Ms2ger (talk) 14:32, 29 June 2008 (UTC)
 * I agree with Ms2ger. This should not have been removed, webkit does not yet support "column-count", only "-webkit-column-count" --Th e DJ (talk • contribs) 14:42, 29 June 2008 (UTC)


 * I can confirm that column-count works fine on Safari 3.1 for Windows. And according to this blog entry from Dave Hyatt, Safari's software architect, WebKit has supported column-count since January 2007. —Remember the dot (talk) 22:39, 29 June 2008 (UTC)
 * I tested it this afternoon on 3.1 and NB Mac OS X, and it does NOT work. Hyatt is talking about -webkit-column-count in that post (just look at the HTML source) --Th e DJ (talk • contribs) 22:54, 29 June 2008 (UTC)

I've reverted it for now. --- RockMFR 23:02, 29 June 2008 (UTC)
 * I'm consulting webkit developers on wether or not there possibly is a bug in Safari for Windows that might cause divergent user experiences. I will hear from them soon. --Th e DJ (talk • contribs) 23:07, 29 June 2008 (UTC)


 * I honestly don't know why it was working for me before...You were right, despite the blog post saying "column-count" only "-webkit-column-count" is currently supported. I'm sorry for all the trouble, I should have double-checked first instead of misinterpreting the statements of others. —Remember the dot (talk) 23:13, 29 June 2008 (UTC)


 * Oh, I see now.  generates &lt;div class="references-small" style="-moz-column-count:2; -webkit-column-count:2; column-count:2;"> rather than going through the references-2column class. Why is this? What is references-2column for, then? —Remember the dot (talk) 23:21, 29 June 2008 (UTC)
 * References-2column is how it was done before reflist was created (and is probably still in use on thousands pages). One could make the case that reflist should use classes for the column specifications. It's all complicated by a number of factors: backwards compatability, browser support, people hardcoding 3/4/5 columns on their pet articles because they have a 30" monitor, etc. --- RockMFR 01:45, 30 June 2008 (UTC)
 * Using individual classes for 2, 3, 4, etc. columns doesn't seem like a good idea. In fact, we should consider removing the references-2column class and making everyone use  uniformly. Do you know of a good way to get a list of pages that use this class? —Remember the dot (talk) 01:59, 30 June 2008 (UTC)


 * OK, I just removed it. Here are my reasons for doing so:
 * Template:Reflist has supported 2-column display since November 2006 (diff).
 * Internet Explorer doesn't handle multicolumn layout anyway, so the impact of this change is limited.
 * AWB has been automatically replacing instances of this class since February (see bug report).
 * Unless we remove the class, editors will have little motivation to update articles to use.
 * I think that common.css is cached for 30 days, so it will be a while before we see the effect anyway. Making the code simpler and more consistent is definitely a good thing, and since this is such a minor change at this point it shouldn't be much of a problem. —Remember the dot (talk) 01:39, 9 July 2008 (UTC)
 * As long as this is in use, it should remain here. --- RockMFR 15:32, 9 July 2008 (UTC)
 * We should be taking active steps to make this class 'extinct in the wild' before removing it from the CSS here, but it should be removed. Happy‑melon 16:05, 9 July 2008 (UTC)


 * What is there to do? Removing the class will provide the motivation necessary to get the remaining instances of this class switched over to . And Internet Explorer doesn't process this CSS anyway, so 70% of our users will be completely unaffected. —Remember the dot (talk) 04:31, 10 July 2008 (UTC)


 * I have done quite a bit of investigation on the reflist issues lately, and there is a bug in Safari. Multiple columns show nicely, but the links are mispositioned. If you link into column two or higher, then the screen appears to go to where the reference link would be at one column. See Template:Reflist/Safari testcase. This is a bug in Safari and exists through the current version of 3.1.2. The bug has been reported to Apple by myself and another editor. See Template talk:Reflist. --——  Gadget850 (Ed)  talk  -  14:02, 15 August 2008 (UTC)

Assessment grade colourings
I have some doubts about the latest addition of "assessment grade colourings". The new classes seem to be designed for Template:FA-Class and such (never mind I had to look up user contribs to find that out). I think these colors could just stay as part of the templates: —AlexSm 15:49, 30 June 2008 (UTC)
 * skinnability of specific templates is rarely used by anyone, and still could be achieved by using !important keyword
 * ease of maintenance seems marginal
 * Common.css is already huge enough
 * and the new classes are not even for article namespace
 * These colors were hardcoded in templates, and are not wrapped using a CSS class at all, so skinning them using !important is impossible. Also, while these are generally not used in the article namespace, they are transcluded in about a million and a half talk pages, so they definitely would be used. Tito xd (?!? - cool stuff) 06:55, 2 July 2008 (UTC)
 * I think it was obvious that I hinted at the option to add classes while keeping "default" styles in the template code. All in all, this addition makes the site a bit heavier for visitors, and there are a lot more visitors that regular editors. —AlexSm 14:34, 2 July 2008 (UTC)
 * They will also be used in MediaWiki:Gadget-metadata.js which will affect the mainspace. Actual eventual use: 1,717,000 pages in Talk: namespace for all users, plus however many project pages, project-talk pages, category pages (at least 13,000 of those) and template pages are used in the display of WikiProject stats, plus 1,330,000 pages in mainspace for however many users use that gadget. For comparison, the cmbox code is at least twice the length and is only used on 15,000 non-mainspace pages, yet its presence here is undisputed... Happy‑melon 16:23, 9 July 2008 (UTC)

I just tried implementing these classes, and while it didn't affect the display of talkpage project banners, it caused all the summary statistics tables (which use class=wikitable) to no longer display the background colours (I have a screenshot if it would help). Barring someone coming up with a clever fix, given the objections above, it seems that this is a poor situation to use CSS. Should we remove the code from common.css, or is there an easy way to make it work? Happy‑melon 18:56, 2 August 2008 (UTC)

I have removed the CSS, but Pyrospirit has just left the following comment on my talk page:

I notice you removed the assessment color CSS classes in MediaWiki:Common.js. Could you please put those back? Removing them broke my metadata script that uses them, and they may be used elsewhere as well. Also, even if they're not universally adopted, having them there at all will help to standardize color schemes for article assessment. Besides, it doesn't do any harm to leave them there. Thanks, Pyrospirit ( talk  ·  contribs ) 01:38, 11 August 2008 (UTC)

Any comments from any regulars here? Happy‑melon 11:17, 12 August 2008 (UTC)


 * As a workaround, I'm going to install the classes through a custom stylesheet for anyone who uses the metadata script. I still think it's a good idea to have these in Common.css, but it won't be required for the script to function. Pyrospirit  ( talk  ·  contribs ) 15:53, 12 August 2008 (UTC)
 * If that is possible, then it is a preferred solution anyway, because it reduces the amount of data required for pageloads where the script is not used. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 14:30, 13 August 2008 (UTC)

Mainpage CSS
What is the point of including the CSS of the mainpage here, if it's only really used in 1 out of our 2,5 million pages ? --Th e DJ (talk • contribs) 16:43, 8 July 2008 (UTC)
 * Where else would we put it? --MZMcBride (talk) 19:18, 8 July 2008 (UTC)
 * Sorry about that, didn't realize someone had added new code. I thought you were referring to the CSS we use to hide the &lt;h1>, etc. I reverted the other code. I agree with you, adding CSS to an already-huge file for 1 out of 13 million pages makes little sense to me. --MZMcBride (talk) 19:22, 8 July 2008 (UTC)
 * Well, it is the most-loaded page. — Edokter  •  Talk  • 19:37, 8 July 2008 (UTC)
 * Well, is there any reason not to specify all this as inline CSS? Is it skinnability? reducing the size of Main page? —AlexSm 20:44, 8 July 2008 (UTC)
 * Reducing size mainly, which is always a good thing. Now the CSS has to be sent on every page load. Moving inline CSS to common.css, or a seperate mainpage.css, could reduce traffic,as it would be cached seperately, and longer. — Edokter  •  Talk  • 12:00, 9 July 2008 (UTC)
 * Normally i would say, we would conditionally load such CSS if people want this. However, since it is the mainpage, I do not want to assume people have Javascript active. --Th e DJ (talk • contribs) 13:08, 9 July 2008 (UTC)
 * Not that it really matters... but from what I can see, http://stats.grok.se/en/200805/Special:Search is greater than http://stats.grok.se/en/200805/Main_Page. --MZMcBride (talk) 01:42, 9 July 2008 (UTC)

I oppose this change for the following reasons: the code adds 908 bytes to Common.css, and I doubt it's going to save that much even on the Main page (e.g.  vs  ); while the external CSS is cached, the browser still have to parse every time, slowing down every page rendering (even if for a little); finally, redesigning Main page will become more difficult (due to CSS caching). —AlexSm 14:16, 9 July 2008 (UTC)
 * The primary reason for the change is to allow the Main Page to be skinned for those users that wish to do so, and optionally changed in the various skins (it currently displays the same as monobook in all other skins). I suspect that the classes have been constructed fairly poorly and could probably be made more efficient - I'm not a CSS pro by a long stretch of the imagination! I can't see how redesigning the page would be made more difficult by it being skinned; surely we'd just use the same technique that worked with, , etc: deploy the page with hardcoded styles, add appropriate code to this CSS, wait for the caching time to expire, and then convert the page to use the classes. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 15:14, 9 July 2008 (UTC)
 * If skinnability is the primary reason, you can keep the styles inline and simply append some classes, then users will simply have to use  keyword. What I meant about cache: you'll have to wait up to a month on every major redesign, while keeping both old and new CSS in Common.css. Overall, I think the best solution would be to ask devs for a separate editable CSS file for a main page. —AlexSm 15:32, 9 July 2008 (UTC)
 * Fully agree with the latter; you can see my level of CSS competence from my ignorance of the former! Would IDs be more appropriate than classes? <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 16:25, 9 July 2008 (UTC)
 * If you say so yourself, in the future, could you please be so wise to discuss things that apply to all our pages, effect all our users and are cached for 1 month by the few users that happen to download it ? Also, classes are for things that are re-used or CAN be reused multiple times, IDs are for things that are unique. Usually, you add both in cases like this. Like one general class for all the "square-section-boxes", and an ID for every box in itself. So you have ID's "mainpage-ITN" "mainpage-DYK" and "mainpage-featured-article". The latter 2 of class "mainpage-box-green" and the first of "mainpage-box-blue" for instance. --Th e DJ (talk • contribs) 17:47, 9 July 2008 (UTC)

User:Remember the dot and body.page-Main_Page {display:none}
Please discuss changes before implementing.

This is not a rule you should ignore because you are "sure of what you are doing" or "just want to test". That means, discuss them, don't just go make the main page invisible. You should also realize, that the interface message has a max-age and s-maxage of 30 days (it is allowed to be cached for up to a month in browser caches and on the squids). This means, your actions will have consequences for up to 30 days.

Testing can be done on your own user Monobook.css.

Even though this is a suggestion, you should always do this, even if you are sure of yourself, before messing with the site wide CSS.

Remember the dot: It looks like your last 3 changes to Common.css have had to be reverted. I suggest you do not implement any more changes to this interface message, most especially without at least 24 hours of discussion beforehand on the talk page here. --Splarka (rant) 08:03, 23 July 2008 (UTC)

Access dates for printed references
After this discussion about the citation templates I wonder if you could make it the default to hide the access dates for printed references by adding the following code by Happy-melon: The idea is to not confuse casual readers with two dates (published and accessed) but make both accessible to editors. See discussion for pros and cons and feel free to comment there. Thanks, --EnOreg (talk) 23:08, 25 July 2008 (UTC)
 * Sorry, I'm a bit confused. We shouldn't generally be using display:none; in articles (or elsewhere) as it's terrible with text-only browsers and browsers that don't support CSS. The link you provided left me lost. Can you provide some detail on the situation? Thanks! --MZMcBride (talk) 23:14, 2 August 2008 (UTC)


 * I'll try to summarize. References (citations, sources) can have a publication date (stable sources, mostly printed) or an access date (web pages that keep changing). One of the two is sufficient to make a source verifiable. Therefore, for stable sources we shouldn't display an access date next to the publication date—that would be confusing for the reader. Some editors, however, want to see the access date to help them recover dead links.
 * Happy-melon CSS-wrapped the access dates in the templates for stable (printed) sources, e.g. in Template:Cite book, so they can be shown to the editors who want them and hidden for everybody else.
 * What does the problem look like with the browsers you mention? --EnOreg (talk) 21:44, 3 August 2008 (UTC)


 * The problem is that text browsers and PDF exporters do not support CSS at all, so the text will appear. — Dispenser 03:33, 4 August 2008 (UTC)
 * So it wouldn't make the problem worse for them but improve the situation for everybody else, no? --EnOreg (talk) 04:12, 4 August 2008 (UTC)

This is fundamentally a bad idea. Why would we output something just to hide it with CSS except for a handful of editors? This gives 99.9% of readers no chance to see it at all. Access dates aren't exclusively for helping editors. --- RockMFR 03:54, 4 August 2008 (UTC)
 * In the discussion linked above you will find the following question asked many times, but no answer: What use to readers is an access date if the reference already has a publication date? If you have an answer please provide it to the original discussion (to keep it in one place). --EnOreg (talk) 04:12, 4 August 2008 (UTC)

Their argument is essentially that, where a source is originally a printed work, the url is merely a convenience link - if the url no longer functions, then reference must be made to the original offline source, which is no worse than if the url had never been provided. As such, therefore, the accessdate is irrelevant because linkrot is not a concern. I'm not sure how far I agree, but the functionality is there if needed. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 10:05, 4 August 2008 (UTC)
 * I agree with Happy-melon: add the CSS class and let each user decide on the aesthetic look. Those who hate the accessdate and can follow simple instructions can hide it. --—— Gadget850 (Ed)  talk  -  13:29, 13 August 2008 (UTC)
 * Everybody agrees with Happy-melon that it should be configurable. The question here is what should be the default. Most of our parents are not able to follow what you call "simple instructions" to hide the access date (most readers don't even have an account), but most editors will be able to modify their CSS to make it visible. Moreover, the default should suit the majority and the vast majority has no use for these access dates. --EnOreg (talk) 14:20, 13 August 2008 (UTC)

CSS talkpage detection
I have started a discussion over at Village pump (technical)/Archive 122 regarding an idea how to make CSS based talkpage detection simpler. I think that discussion might interest several of you who watch this page.

--David Göthberg (talk) 21:12, 7 August 2008 (UTC)


 * The discussion resulted in that MediaWiki has been upgraded to put the classes "ns-talk", "ns-subject" and "ns-special" in the HTML body element of rendered pages. See the description of the classes in Catalogue of CSS classes. These classes will be on-line the next time Wikipedia is updated to run on the latest MediaWiki code.
 * --David Göthberg (talk) 19:36, 10 August 2008 (UTC)


 * I believe this is live now. <body class="mediawiki ltr ns-9 ns-talk page-MediaWiki_talk_Common_css skin-monobook"> is what this page is outputting. --MZMcBride (talk) 22:21, 10 August 2008 (UTC)


 * MZMcBride: Thanks for notifying us that it is live now.
 * Wow, that was quick! I checked several different namespaces and all three of "ns-talk", "ns-subject" and "ns-special" work as they should. And I checked around, it seems to also be live in the other language Wikipedias and other Wikimedia projects like Meta and Commons.
 * --David Göthberg (talk) 22:31, 10 August 2008 (UTC)

Index
Is it time to create an index page? Seems like many of these entries were added so long ago that you have to dig through years of changes or talk to figure out why something was added or changed. --—— Gadget850 (Ed)  talk  -  14:43, 18 August 2008 (UTC)


 * I agree, the talk page archives of this page needs indexing. I assume most of you know this: There are archiving bots that can do that automatically for us. As far as I have understood it we just need to add some stuff to the top of this page to make those bots come here and do the indexing for us.
 * Gadget850: You might also want to take a look at Catalogue of CSS classes. Most of the classes in these CSS files are explained there.
 * --David Göthberg (talk) 05:05, 20 August 2008 (UTC)

Microformat classes
I have added a page on classes used in microformats (see also microformat; WikiProject_Microformats). It has been suggested that these should be added to Common.css, unstyled, to ensure that they are found when people look for them, and that they are not reused of other purposes. Andy Mabbett | Talk to Andy Mabbett 09:00, 23 August 2008 (UTC)


 * I don't think that's necessary. We have Catalogue of CSS classes for this. —Ms2ger (talk) 13:31, 23 August 2008 (UTC)


 * I agree with Ms2ger.
 * Andy Mabbett: That you added information about those classes at Catalogue of CSS classes is correct since you want to "reserve" those class names.
 * But I don't think they should be added as dummy (empty) classes in MediaWiki:Common.css. Since among other things that would cost bandwidth for both our servers and every user visiting Wikipedia. Documenting them in "Wikipedia:Catalogue of CSS classes" should be enough.
 * And what I think of those classes:
 * Their naming is really bad. They are very short generic words so they are too likely to collide with other classes. Sure they surround them with a div tag marked with for instance, but that only protects declarations of those classes from interfering with other classes. (By using " ".) But as far as I know CSS has no good way of saying "logo, but not vcard", thus any other declaration of "logo" can not be stopped to interfere with the logo class inside a vcard. And it seems the microformat is a large "standard" and that it is likely they will add more classes to it at any time, so we can not know what collisions we will get in the future. They really should prefix all those classes with some standard prefix, like this: "mf-logo"
 * --David Göthberg (talk) 13:48, 23 August 2008 (UTC)


 * I'm happy to accept what you (both) say about not adding the classes to the CSS file; as I indicated above, I was responding to a suggestion from another editor.


 * As to the naming of classes, in microformats, you have a good points and I invite you to raise it on the microformats wiki or mailing list (details on that wiki). Note that the class-names in the "species" proposal, of which (unlike the rest) I am the author, include a proposed "taxo-" prefix.


 * Thank you for your time. Andy Mabbett | Talk to Andy Mabbett 13:55, 23 August 2008 (UTC)

Ambox and cmbox margin problems
Resolved.

Wknight94 today changed the CSS code for the the ambox class from "margin: -1px 10%;" to "margin: -1px 10% 0px;". That means the bottom margin for amboxes changed from -1px to 0px. Wknight94 had found a case where the old code causes a problem. The problem is visible in both his IE 7 and my IE 5.5. He demonstrates the problem here: User:Wknight94/CSS fix (In Internet Explorer: If an image or other right flowing box follows immediately after an ambox with no or only one newline between them then subsequent section headings will overlap with the image.)

The reasons why we had -1px bottom margin for ambox and cmbox have been extensively discussed here: Template talk:Cmbox. The reason is that having 0px bottom margin seriously breaks the box flow for amboxes in Opera. That is, it causes other boxes like images and infoboxes to overlap with the amboxes. Here's some examples:

If using Opera, the old code here works fine (apart from the minor thing that the lower ambox slightly overlaps the upper ambox in Firefox):



But with the new code the image overlaps (covers) the ambox that comes after it in Opera:



So both settings cause problems. One option is to go back to using "margin: 0 10%" which we used some time ago. It doesn't cause any known problems in any browsers, other than the minor ugliness that in most browsers the borders between amboxes will be double. Like this:



I think this needs to be investigated further. But at the moment it seems to me that we need to go back to the older code "margin: 0 10%", for both ambox and cmbox.

--David Göthberg (talk) 23:47, 23 June 2008 (UTC)


 * Fine by me. I'll confess to not even having Opera!  With margin: -1 10%, there is another workaround for the original bug as shown in this edit.  Perhaps there is a deeper problem with the section heading lines?  —Wknight94 (talk) 00:30, 24 June 2008 (UTC)


 * Actually, Safari 3 has the same issue that you talk about with Opera I think. --Th e DJ (talk • contribs) 00:43, 24 June 2008 (UTC)


 * Well do we want to try one of the various CSS hack techniques so everyone plays nice? Or is that frowned on in these parts?  —Wknight94 (talk) 02:11, 24 June 2008 (UTC)


 * Wknight94: Using different CSS for different browsers? That is probably messy. Of course, for this a widely used template it might be worth it. But we have some more things we can test that is less messy. And the robust one above with double borders isn't that bad after all. (And if we set it to "border-collapse: collapse;" like we had earlier then it only gets double borders in some browsers.)
 * --David Göthberg (talk) 14:14, 24 June 2008 (UTC)

How does Opera/Safari handle the code below? It might solve the problem. — Edokter  •  Talk  • 13:26, 24 June 2008 (UTC)




 * Well, "margin: -1px 10% 0 10%;" = "margin: -1px 10% 0;". And as expected the image unfortunately does overlap the second ambox when viewed with Opera. But it was worth the try, since with bugs anything is possible.
 * (But there is hope, an editor suggested another solution some months ago. I'll code that one up and test it today and report back.)
 * --David Göthberg (talk) 14:06, 24 June 2008 (UTC)


 * Oh well, it was just a shot in the dark, hoping Opera/Safari had problems with 'implied' values. — Edokter  •  Talk  • 14:40, 24 June 2008 (UTC)


 * I say we simply use the + CSS selector, and let IE have pretty double lines. --Th e DJ (talk • contribs) 14:44, 24 June 2008 (UTC)


 * Meh... I find that favoratism. It should look the same in all browsers; double or single lines. — Edokter  •  Talk  • 14:56, 24 June 2008 (UTC)


 * ✅ Done - I know it is irregular to edit an archive page like this, but since this discussion is linked from many places I wanted to note this here. We have now fixed this by adding the following code to MediaWiki:Common.css:


 * All glory go to TheDJ who came up with the solution.
 * --David Göthberg (talk) 15:21, 12 April 2009 (UTC)

Add some top and bottom margin for cmbox
We are planning to give cmbox some top and bottom margins so it doesn't stack tight anymore, since we now think that looks better. See discussion and examples at Template talk:Cmbox. That also means that the cmbox won't have the margin problem discussed above. (I have not had the time to further investigate the margin problem for the ambox yet, sorry.)

--David Göthberg (talk) 19:30, 23 August 2008 (UTC)


 * Done. I have added the new top and bottom margins to the cmbox CSS code. It will become visible to users as their web browser's CSS caching times out and they reload this new version of MediaWiki:Common.css.
 * --David Göthberg (talk) 16:58, 24 August 2008 (UTC)

Tmbox margins and new class naming for all mboxes
I am planning to change the top and bottom margins for the class ".messagebox.standard-talk" so they match the tmbox class. This will make old and new talk page message boxes look better together, since they will then use the same margins. See discussion at Template talk:Tmbox.

We are thinking of changing the naming of the CSS classes for all the different kinds of mboxes. That is the ambox-*, tmbox-*, imbox-*, cmbox-* and ombox-* classes. This will not cause any change in looks, just an internal change in class naming. See discussion at Template talk:Mbox

--David Göthberg (talk) 15:21, 17 August 2008 (UTC)


 * I have now changed the margins for ".messagebox.standard-talk" to "margin: 4px auto;". Looks good on the talk pages and even works fine in my old IE 5.5.
 * I have not renamed the mbox classes yet.
 * --David Göthberg (talk) 06:10, 20 August 2008 (UTC)


 * And now I have added the new class names for the mboxes. So both things done. We can start using the new class names when the 31 days CSS caching time in the web browsers have passed.
 * --David Göthberg (talk) 16:52, 24 August 2008 (UTC)

Request for background-image rule
Hello, I realise this is an unusual request, but I'm working on the Main Page Redesign proposals and I really need to have a background image on a div. Obviously this has proved impossible without a change to this file, so I ask guiltily, whether it could be allowed for me to have a css class put in this file temporarily. The rule would be:  I realise this is going out on a limb, but there seems to be no workaround. My proposal is here, if you're interested P retzels chatters 15:22, 15 July 2008 (UTC)


 * Sorry for responding so late. It's just a handful of bytes for the MediaWiki:Common.css for some months. I think we can allow that, right guys? If we do this I will write the selector for it in such a way that that background can only be used on that very page. Thus it can not be misused.
 * I see that your code above is a bit wrong, but that you already fixed that in your personal monobook.css. You probably should tone that image down, since currently it makes the text very hard to read. (That is, upload a new softer image to the same image name.)
 * --David Göthberg (talk) 12:31, 1 September 2008 (UTC)


 * Thanks David! P retzels chatters 15:24, 3 September 2008 (UTC)


 * Why can't he ask people to input  into the address bar?  — Dispenser 18:24, 3 September 2008 (UTC)


 * Pretzels: Don't thank me just yet, your request is probably slightly controversial so I won't add your code until I have heard what some of the others who watch this page think.
 * Dispenser: Into the address bar? How does the browser then know for which pages that should be valid and for how long? Is it only for the page in the currently open tab or what? I know we can add a similar line of code into our personal monobook.css pages. But Pretzels page is a demonstration of a possible new main page layout so I expect that lots of users will view that page, thus it might be worth it to add his line of code into Common.css during the demonstration period.
 * And my POV disclosure: I have not viewed most of the new suggestions for main page layout yet so I don't have a point of view on Pretzels suggestion, that is at the moment I am more or less impartial. But I think the process of showing and testing new layouts is important enough that it warrants some extra service so it runs smoothly.
 * And here is the code I would use with the selector written in such a way that this background can not be misused on other pages:


 * --David Göthberg (talk) 14:05, 4 September 2008 (UTC)

Image gallery colours
I am planning to change the colours for the image galleries. That means both galleries created manually by a gallery tag and the automatic image galleries on category pages. The changes are:
 * For monobook: Both a change in colours and addition of a soft chequered background in some namespaces.
 * For all other skins: They already use those colours for the galleries, so the only change is the addition of a soft chequered background in some namespaces.

See more explanation at MediaWiki talk:Monobook.css, and discuss there.

--David Göthberg (talk) 10:18, 1 September 2008 (UTC)


 * ✅ Done - Now galleries are looking very nice in all namespaces. --David Göthberg (talk) 22:26, 1 September 2008 (UTC)

Checker-soft.png
I'm sorry to say... but it hurts my eyes. Please use Checker-16x16.png instead. The checkers are supposed to have sharp edges to contract the image. Now I am constantly squinting because the blurring gives the impression of bad monitor, or even bad eyes. — Edokter  •  Talk  • 22:52, 1 September 2008 (UTC)


 * Thanks David, much better! (Even on CRT.) — Edokter  •  Talk  • 14:20, 3 September 2008 (UTC)


 * To me the softer background image looked better on my CRT. But since you left the message above I went to the library and compared on the LCD monitors there, and then the sharper background is much better. So in total the sharper image is the better choice. That is, you were right. Thus as you requested I changed to the sharper image. (I hope the OLED monitors that are coming onto the market now will be better than the LCDs.)
 * For anyone else reading this: You might need to bypass your browser cache to see the new gallery background. And if you want to see what we are talking about, here is a category with many transparent images: Category:Wikipedia image placeholders.
 * --David Göthberg (talk) 15:18, 3 September 2008 (UTC)


 * Thanks again. I don't know what monitor you have; I have a TrinitronTM (I swear by them). — Edokter  •  Talk  • 00:26, 5 September 2008 (UTC)

MediaWiki:Handheld.css

 * This comment was moved here from MediaWiki talk:Handheld.css since that talk page has been redirected here.

I threw in these quick sample styles to flatten the layout tables on the Main Page. See my blog post on the matter for sample images in Opera's small screen mode. --brion (talk) 03:55, 4 September 2008 (UTC)

Font sizes
Fonts that are too small to read, are a cause of constant complaint. Anything at 90% or under, seems to especially cause problems/complaints, for a significantly sized sample.

Blockquotes (at 85%) are particularly difficult to read (eg Talloires Declaration or throughout European Community regulation). Small references (which dance between 95%, 92%, 90%, and 88%, in various implementations) are the other major problem. Infoboxes are currently 88%.

Here are the most relevant, of the threads I've seen this year:
 * MediaWiki talk:Common.css/Archive 4 (May 2008)
 * (Current threads - most of this page is about the problems with multi-columns and small fonts, but these 3 threads summarize well:
 * Template talk:Reflist
 * Template talk:Reflist
 * Template talk:Reflist
 * Template talk:Infobox (current thread - Edokter states here that "88% is the only fontsize below the regular fontsize that renders consistently between browsers")
 * Wikipedia talk:Accessibility (Feb 2008)
 * Wikipedia talk:Accessibility (current thread - discussing an addition, that would somehow restrict the use of small fonts)

(This note is primarily intended as a heads-up/fact-dump/link-dump, but...) If there are any experts on cross-platform accessible-text-sizing, we'd greatly appreciate your input at that last link, and here. Barely-readable-text might be considered harmful! -- Quiddity (talk) 05:35, 27 August 2008 (UTC)


 * I agree. Not all Wikipedia readers (and editors) are 18 years old and have full eyesight. Some are like me 39 years old and starting to get tired eyes. I still have better eyesight than most but at my age small text tires my eyes. And it must be terrible for those that doesn't have good eyes. (My optician just told me some weeks ago it is time I get reading glasses!)
 * --David Göthberg (talk) 11:11, 27 August 2008 (UTC)


 * Two comments: First, modern browsers allow users a lot of local control over fonts, including minimum font size, and relative font size (i.e. make all fonts on the page x point sizes larger or smaller). Wikipedia cannot be responsible for the failure of users to use the basic features of their software.  If we did, then we should set all fonts to 200% normal size, to account for people with really bad eyesight who have not bothered to find out how to control browser font size locally, and everyone else can just live with big fonts.  We're not going to do that obviously.
 * That said, I cannot think of any defensible reason to not set all of these small font usages at 90%, and have that be the declared minimum (it's not a minimum that can really be enforced, since if  and   are set at 90%, and someone does , you'll get a font size that is 90% of 90%). Just because of the way CSS works, there's nothing to be done for this other than fixing such mistakes in the pages they occur in, or doing a lot of CSS guesswork to try to catch all such cases pre-emptively. (e.g. if small is inside sup, if sup is inside small, is sup is inside blockquote, etc., etc., etc.), and even that wouldn't catch all cases, since the   attribute can be used all over the place.  I do agree that 85% is too small - in Mozilla/Firefox-family browsers under MacOS X using default fonts and sizes at 1024x768, text at or below about 85% size is not legible at all, no matter how good your eyes are, because the letter forms are mangled. —  SMcCandlish  &#91;talk&#93; &#91;cont&#93;  ‹(-¿-)› 12:56, 27 August 2008 (UTC)
 * The browser control of font sizes is very unsatisfactory. I have played around with the preferences a lot in Firefox. I have installed plugins too. The bottom line is that there shouldn't be too wide a spread of font sizes for the text on a page (headers are a different matter). I wouldn't go lower than 92% or 95%. Maybe lower in the standard sidebar links since they stay the same, and are easily remembered. But main text, infoboxes, collapsible boxes, references, etc. are frequently read, and shouldn't be less than 92%. I would prefer 95% for my eyes. I am not unusual in this desire. There is rarely a need for lowering font sizes. I can see only one legitimate reason and that is for the sidebar links so that they don't wordwrap into the next line. Such as lines like "Donate to Wikipedia" in the sidebar in the "interaction" section." --Timeshifter (talk) 22:23, 27 August 2008 (UTC)

I'd like to see #bodyContent at the browser default size, no matter what else - right now it is unaccountably at "127% (#globalWrapper) of x-small (body)" - which amounts to 95% of medium - less of a difference than I thought, but still odd - why should it be smaller than what the user has specified in their preferences? Can someone explain this? (both of the styles that apply here are in main.css as part of the skin, not in common.css here) --Random832 (contribs) 13:09, 27 August 2008 (UTC)


 * Beware increasing the size of superscripted text, however, as 1) it makes it more intrusive into the main text, and 2) causes line spacing problems (it took months to get this fixed last time). —  SMcCandlish  &#91;talk&#93; &#91;cont&#93; ‹(-¿-)› 21:39, 29 August 2008 (UTC)

Here are more font size discussions:
 * commons:Template talk:Collapsed
 * commons:Template talk:On Wikipedia --Timeshifter (talk) 22:12, 27 August 2008 (UTC)

Proposed increase
I would like to propose adding the following rule: #bodyContent { font-size: 105% } - this will bump up the size by one pixel at most sizes people may be using (between 10 and 30 pixels) and on firefox at least will bring it in line with the size specified by the user in preferences. --Random832 (contribs) 20:48, 29 August 2008 (UTC)
 * To clarify, this should actually be in mediawiki:monobook.css as it is a monobook issue. However, other skins should also be examined for base font size deficiencies. --Random832 (contribs) 20:49, 29 August 2008 (UTC)


 * We should not be trying to set the size of all text. That's a browser issue, not an issue for us. If other css declarations result in the body text not being rendered at the browser's default size, as you say above - then those other declarations should be fixed. &mdash; Carl (CBM · talk) 02:38, 9 September 2008 (UTC)


 * I'm opposed to a blanket resizing, which may not improve readability very much, but is sure to screw up the relative proportions of many elements. The leading for body text is pretty tight, and it may be better for readability to increase the line-height a bit and leave font size alone.


 * The relatively small default font size in monobook limits the range of smaller text sizes we can use to create a visual hierarchy—but if we eliminate them altogether, then readability may be reduced at another level. In my browser (Safari/Mac), articles' body text shows up 13px tall by default.  CSS   property (÷1.2) reduces it to 11px—this is a basic CSS change in size, and should be accommodated, at least for footnotes and other less-important text (it's the same as 84.6%).  If long text passages in block quotes are really too hard to read, then try them at 92% (12px by default), but adjust the line-height accordingly so they still have the same absolute line height as regular body text.


 * But frankly, playing with font sizes this way is a mistake. Every monitor has a different resolution and sits a different distance from its reader's eye.  There will be someone who complains that it is too small at any size, and probably someone who wishes it was smaller.  Wikipedia is not paper, and text can be resized in every reasonably recent web browser.  The reader has control.


 * Furthermore, accessibility guidelines do not mandate minimum font sizes.


 * WCAG 1.0 says nothing about text size, except to use relative font size specifications (e.g. ems or percent, not points or pixels).
 * The WCAG Samurai Errata say nothing about absolute text sizes either, but essentially say that all unit specifications in CSS are relative.
 * Web accessibility expert Joe Clark, in Building Accessible Websites (“Type size,” p 223) writes a very small amount about applying judgment to type sizing issues, but says “they are essentially irrelevant to actual visually-impaired people.”
 * He hammers it home in a presentation on his website: “Font size just is not your problem as an author.”


 * Millions read Wikipedia. Of course there will always be some complaints about font size.  Please don't mess with the overall look of a design that has been incredibly successful for years. —Michael Z. 2008-09-11 02:02 z 

Minimums
My original intention was to start a discussion on some sort of minimum recommendations for text resizing.

What would be ideal, is if someone who understands our overall system of interrelated stylesheets could build an example page, demonstrating all the details: why infobox is set to 88%, for example, yet still appears larger than reflist's textsize (currently at 90%)? I'm envisioning some sort of cross between User:Edokter/fonttest and these laborious screenshots (old bookmark, not uptodate browsers).

See also, the thread I mentioned initially: Template talk:Infobox (current thread - Edokter states here that "88% is the only fontsize below the regular fontsize that renders consistently between browsers"). That's what I'm after - consistency.

I'll repeat below what I said in a thread from May 2008 (following) -- Quiddity (talk) 03:43, 13 September 2008 (UTC)
 * I'd thought we were using 92% as a standard value, per FootnotesSmall? The only mediawiki archive discussions I could find were MediaWiki talk:Common.css/Archive 3 and MediaWiki talk:Common.css/Archive 2, but there are probably more, scattered in the other namespaces.
 * [...] We seem to use a mix of ems, %, and px, and I'm not sure if the overall plan is explained anywhere, or if there even is one? -- Quiddity (talk) 17:56, 1 May 2008 (UTC)


 * I'll see if I can describe some of the spaghetti. See CSS, and Catalogue of CSS classes for a list of the nine actual style sheets which may affect pages under the monobook skin.


 * Here's an outline of the cascade for basic font size, as near as I can untangle some of it, with computed font sizes as reported by Safari's Web inspector.  I haven't looked at the “IE fixes” style sheet, but IE 6 and 7 have font-sizing bugs which may or may not affect this cascade.


 * is set to your browser's default font size. For most, this is keyword “medium” which by default renders at 16px.
 * main.css applies, which reduces the size by two keyword steps: 10px.
 * main.css applies, with the comment “scale back up to a sane default”: 13px.
 * no font-size adjustment.
 * no font-size adjustment.
 * no font-size adjustment. Normal body text remains at 13px.


 * main.css applies 100% to tables, but this is overridden by the inline style which sets it to 88%: 11px (there's also a different size specification for .infobox.sisterproject and .infobox.geography in common.css)


 * —Michael Z. 2008-09-13 23:14 z 


 * How does IE have "fon-sizing bugs"? There are differences in font-size accross browsers, and IE does stand out by a margin, which is why I advocate using 88% in infoboxes, as that results in a consistent rendition between browsers. The root of the diffrences stems from the  declaration in the body, as that is what is interprated differently between browsers. I rather have that fixed then anything else, ohterwise we will continue to suffer from inconsistent behaviour between browsers. —  Edokter  •  Talk  • 00:09, 14 September 2008 (UTC)


 * I believe MSIE renders font sizes differently from the CSS specification which other browsers follow, and will not resize some text in response to user controls.  Perhaps this is a result of design or history, but when I design sites according to the spec, I have to address it as one of MSIE's many rendering bugs.  There's a demonstration at “How to Size Text in CSS” (A List Apart). —Michael Z. 2008-09-14 16:15 z 


 * I do agree that using a relative text size on the &lt;body> would probably improve consistency. Replacing the   with 67% or 69% would keep the display the same with default browser settings, and make it consistent across browsers.  However, I think it might change the text size in MSIE, so there may be significant resistance (perhaps not—I'm not familiar with Wikipedia's IE Fixes style sheets).  In any case, we should prepare test cases and review the rendering changes in many browsers before implementing such a broad change across the entire project. —Michael Z. 2008-09-14 17:12 z 

Why exactly are we scaling fonts down in body anyway? &mdash; Carl (CBM · talk) 21:00, 14 September 2008 (UTC)

Browsershots.org is working again. See for screenshots of User:Edokter/fonttest. I've uploaded all of these, and listed them in a subpage at User:Edokter/fonttest/screenshots. Hopefully this will help out somehow, or fresh shots can be taken as needed. :) -- Quiddity (talk) 00:05, 15 September 2008 (UTC)

ol.references
Why do we have  and is it used? This appears to over-ride the font size defined by  with Internet Explorer. --—— Gadget850 (Ed)  talk  -  11:41, 8 September 2008 (UTC)

Span for autosigned text
I am planning to add this style:

this evening. The purpose is to allow users to style the text of unsigned and similar templates. The font size was previously hard-coded into the template. Thoughts? &mdash; Carl (CBM · talk) 19:26, 10 September 2008 (UTC)
 * I would understand if we had a class "sig" automatically added to all signatures, but the ability to style only unsigned signatures doesn't sound all that exciting. I understand you're suggesting this in reponse to Template talk:Unsigned. However, if some users find unsigned too small and they don't mind editing personal CSS file, wouldn't they want to redefine all &lt;small&gt; tags on the page instead of just automatic signatures? —AlexSm 20:03, 10 September 2008 (UTC)


 * My more principled objection here is that we shouldn't be hard-coding font sizes into templates in the first place. In particular, it seems odd to force users to change all small tags simply to change the size of automatic signatures. The other benefit of switching to the span method is that there are quite a few different unsigned templates; using a single CSS class makes it easier to style all of them the same. &mdash; Carl (CBM · talk) 20:39, 10 September 2008 (UTC)


 * I object. per my comments at Template talk:Unsigned. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:36, 10 September 2008 (UTC)


 * I take it you object to the default being the "small" size, not to the use of a span to style the signatures? &mdash; Carl (CBM · talk) 20:39, 10 September 2008 (UTC)


 * Yes. I strongly agree with your view that we shouldn't hard-code sizes. But the default must be accessible. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:51, 10 September 2008 (UTC)


 * Accessibility guidelines do not recommend any particular fixed or minimum font size. (Indeed, the overall readability of the page may be better if cruft like unsigned tags are visually smaller to stay out of the way of actual content) Various readers need or prefer different font sizes, but they are all able to resize the text in their browser or read it with their screen reader.  A preference for, say 12 or 13px text over 10 or 11px is merely a personal preference.  I've expounded in more detail with references at MediaWiki talk:Common.css. —Michael Z. 2008-09-11 04:58 z 


 * As has been said by many and I agree with it: We should not use anything smaller than 90%. And due to web browsers caching the CSS files it takes 31 days before all users see changes we do to MediaWiki:Common.css. Thus we kind of have to use hard coded styles while we wait for the cache time-out. But if we also add a class name then the hardcoded styles can be overridden immediately by users and by skins by using the " " keyword, and that also means we don't really need to put and class in MediaWiki:Common.css. We just need to inform people more about the " " keyword. And since most of the templates in question is named "unsigned-something", like unsigned, I suggest we stick with the very logical tradition of naming the class the same, that is "unsigned". So I suggest you use this code instead:
 * Well, I am not sure about the exact font-size, but please not below 90%.
 * --David Göthberg (talk) 22:15, 10 September 2008 (UTC)
 * --David Göthberg (talk) 22:15, 10 September 2008 (UTC)


 * If we were to hard-code a font size,  would work well. There is some argument about whether the default should be regular size or small size, though, so no change is going to be made here any time soon. The idea of using a style in the template along with a class name is sound, and if there is some agreement to make the default size small, I hope that's how it's implemented. &mdash; Carl (CBM · talk) 23:14, 10 September 2008 (UTC)


 * CBM: Okay, since you say " " is better, let's try the different sizes and see how they look:


 * Normal text:
 * abcdefghijklmnopqrstuvwxyz 0123456789 abcdefghijklmnopqrstuvwxyz 0123456789
 * font-size: small;
 * abcdefghijklmnopqrstuvwxyz 0123456789 abcdefghijklmnopqrstuvwxyz 0123456789
 * font-size: x-small;
 * abcdefghijklmnopqrstuvwxyz 0123456789 abcdefghijklmnopqrstuvwxyz 0123456789
 * font-size: xx-small;
 * abcdefghijklmnopqrstuvwxyz 0123456789 abcdefghijklmnopqrstuvwxyz 0123456789
 * font-size: smaller;
 * abcdefghijklmnopqrstuvwxyz 0123456789 abcdefghijklmnopqrstuvwxyz 0123456789
 * font-size: 95%;
 * abcdefghijklmnopqrstuvwxyz 0123456789 abcdefghijklmnopqrstuvwxyz 0123456789
 * font-size: 92%;
 * abcdefghijklmnopqrstuvwxyz 0123456789 abcdefghijklmnopqrstuvwxyz 0123456789
 * font-size: 90%;
 * abcdefghijklmnopqrstuvwxyz 0123456789 abcdefghijklmnopqrstuvwxyz 0123456789
 * font-size: 88%;
 * abcdefghijklmnopqrstuvwxyz 0123456789 abcdefghijklmnopqrstuvwxyz 0123456789


 * Now what's up with that? "font-size: small;" is the exact same size as our normal Wikipedia text in my Firefox 2. In my Opera 9 it is larger than our normal text. And in my Internet Explorer 5.5 it is much larger than our normal text. While "font-size: 90%;" and at least seems to be about 90% of our normal text in all my browsers. So I don't think we can use "font-size: small;" at all.
 * --David Göthberg (talk) 23:46, 10 September 2008 (UTC)


 * I thought the CSS property was smaller, not small.... --MZMcBride (talk) 23:52, 10 September 2008 (UTC)


 * Ah, thanks MZMcBride, that is probably the property Carl was after. I added some more examples above so we can compare. "Smaller" is very small in all three of my browsers, it's the same size as "xx-small" in two of them. I say 90% or 95% is a better choice.
 * --David Göthberg (talk) 00:05, 11 September 2008 (UTC)


 * Interesting. font-size: small is legal CSS (check the CSS 1 spec), but apparently it doesn't interact well with the rest of our CSS. I'm glad you pointed that out. &mdash; Carl (CBM · talk) 02:04, 11 September 2008 (UTC)


 * Edoktor made this page User:Edokter/fonttest (as pointed out at Template talk:Infobox) (Might help with one of these textsize threads?) -- Quiddity (talk) 17:46, 11 September 2008 (UTC)
 * Browsershots.org is working again! See for screenshots of User:Edokter/fonttest. I've uploaded all of these, and listed them in a subpage at User:Edokter/fonttest/screenshots. Hopefully this will help out somehow, or fresh shots can be taken as needed. -- Quiddity (talk) 00:03, 15 September 2008 (UTC)


 * Quiddity: Oh! Major coolness! :)) Thanks for those images, they will be very useful.
 * --David Göthberg (talk) 01:53, 15 September 2008 (UTC)

Mbox changes
I am planning to do the following changes to the mbox classes today:


 * Remove the "ambox-mini" class. That class was added a year ago, but as far as I know it has never been used. (I searched for it again today: No hits.) As far as I remember the "ambox-mini" class was added without consensus and only to satisfy one very vocal editor. And then he didn't even bother to use it in his template current sport-related, since someone helped him hard-code the small function instead.


 * Update the "tmbox-small" class to use "font-size: 88%;" instead of "font-size: 85%;". I don't see any difference between the two sizes in any of my three browsers, but in other discussions on this page it has been claimed "88% is the only font-size below the regular font-size that renders consistently between browsers". (Note: This is not an endorsement of such small text from me, I am merely retaining the traditional size for text for this kind of boxes.)


 * Update the "tmbox-small" to use "clear: right;" instead of "clear: both;". I see that some right floating boxes use "clear: right;" and some use "clear: both;". According to my testing and understanding using "clear: right;" is the better option, especially in this case.


 * I am going to add an "ombox-small" class, looking exactly like the "tmbox-small" class. Since for instance the archive box and autoarchivingnotice are sometimes used on "Wikipedia:" pages and thus need to be able to use the small style there too. (It's yet another fix since we use "Wikipedia:" pages as discussion pages...) See discussion at Template talk:Mbox for more on this.

This was merely an announcement/explanation. No action is required from anyone else. But comments are as always welcome.

--David Göthberg (talk) 18:42, 14 September 2008 (UTC)


 * No problems here. The 88% statement should be read as the 'highest' value below regular fontsize that renders the same; 85% works as well. — Edokter  •  Talk  • 20:14, 14 September 2008 (UTC)


 * Edokter: Ah, I see! Thanks. Yeah, I thought it was strange that 88% was the "only". Since in my three browsers (FF 2, IE 5.5 and Opera 9) I get about the same size between 84% and 89%. So I think we should instead aim in the middle of that since I think that is the furthest away from any problems in other browsers and future versions of those browsers. With your highest value 88% we get the range 84% to 88%. That gives the middle value 86%. What is the lowest consistent value you see in your browsers?
 * And I have been doing more testing: The setting "line-height: 1.25em;" is used in the ".messagebox.small" and ".messagebox.small-talk" classes. So I copied that value when we made the ".tmbox-small" class. But now I have been doing some careful testing and that value seems to have no effect in my browsers. I guess that already is the default line-height for our text. So I am going to remove that value from "tmbox-small".
 * That means all the values for the small message boxes are tested and accounted for. Well, I wonder why they choose exactly 238px width back then, why not 290px? (But I won't change it since 238px width is used in all kinds of right floating boxes, and some of them are hardcoded.)
 * --David Göthberg (talk) 22:04, 14 September 2008 (UTC)


 * In IE, the fontsize is the same from 83% to 89%. In Firefox it is the same between 84% to 91%. (See the 90% problem here?) That makes my safe range 84%-89% as well. I choose 88% to have a little margin just in case (and is easier to remember). Since font-size also influences related properties, you might see differences in spacing, padding and line-height between 85% and 88%. As for line-height, Monobook default is 1.5em. If you don't see a difference between 1.25 and 1.5, it must be set somewhere else, or your cache is in the way. In IE, 88% at 1.5em line-height doesn't look very well. I think it's safe to leave it in, as it isn't a cascading property anyway (it is calculated from the current font-size). — Edokter  •  Talk  • 22:33, 14 September 2008 (UTC)


 * Ah, thanks for the detailed answer. I didn't think of those other properties that are calculated from the font size. And yes, we probably want those other values to be big, if they are affected. Right, so let's go with 88% then. I too like easy to remember numbers like that. :))
 * Regarding the 1.25 in line height it couldn't have been my cache since I used a new class name that only existed in my own personal monobook.css. And when I test I always set something else to a new and weird value so I see when the cache is cleared and I have reloaded the new CSS file. And I tested it in all three of my browsers. But I'll investigate it more some day. So for now I'll take your advice and leave the "line-height: 1.25em;" in the code.
 * --David Göthberg (talk) 01:23, 15 September 2008 (UTC)


 * ✅ Done - I have done the update. The ombox-small class may not be used before 16 October, due to the 31 days CSS caching. --David Göthberg (talk) 02:22, 15 September 2008 (UTC)

.IPA class
Please look at http://bugzilla.wikimedia.org/show_bug.cgi?id=11019

CSS IPA class uses font-family of IPA fonts _only_ for Internet Explorer and rely on glyph substitution for any other browser. It's interesting aproach, but doesn't work that good. First of all, glyph substitution is fallback and it isn't really intended to be used as much as possible! There are real results of glyph substitution. Same problem is with similar classes.

I'm sorry about imageshack, but i'm not registred here.

-- Lukas Vacek


 * I don't think there can be situation where result of automatic font subsitution is better then directly selecting ideal IPA font. If I understand font substitution well that .IPA class with inherit is important even for browser with font substituion. I would like to know your opinions. But it's probably not so much important, because people interested in language issues and using not tested browser would be probably able to change appropriate css style.

-- Lukas Vacek

Classes: IPA, Unicode, Polytonic and whatever are specific to Internet Explorer. They should be moved to the IEFixes stylesheet (note that version 7 needs them as well). The parameter comment hack "font-family /**/:" used to cancel the effect on other browsers reverts the customization for version 7; that causes missing glyphs. This hack should be removed. Yecril (talk) 01:53, 18 May 2008 (UTC)


 * Related the the section directly below. An admin with IPA knowledge should have a look at this. BTW, the main reason this isn't in IEFixes.css is because we cannot edit that file. — Edokter  •  Talk  • 11:44, 18 May 2008 (UTC)


 * Many of the reasoning about this is listed on Template_talk:IPA and Template_talk:IPA_fonts. With this information, I was able to deduce the following:
 * Not all IPA fonts have all IPA characters. Because of this, fonts with more chars should be listed earlier in the font-family list.
 * Having .IPA only apply on IE is problematic because glyph substitution might cause "inconsistent" representations, due to mixed fonts.
 * On OSX, the font Lucida Grande is used/the most complete for IPA glyphs. However lucida grande is also the name of a rather Unicode-broken Windows font, causing it to be removed from the list, somewhere in 2005. (I think not listing this font, was a bad call, because of the "inconsistent" representation issue. The default font that Safari uses on wikipedia (Times ??) does not look good icw several interspersed Lucida Grande glyphs)
 * Konquerer seems to not even be able to do glyph substitution. (See below)
 * The code is now both in Common.js and in Common.css
 * IE7 doesn't even use the CSS because the "IE hack" no longer works. (I think the .js code should normally catch this though...)
 * The same IE issue is present in all other CSS defined specialized font-family classes.
 * The current IE only approach was suggested by User:Mzajac in 2005. (I have contacted this user and asked him to contribute)


 * Conclusion. In my opinion we need to remove the current code in MediaWiki/Common.css, and we need to expand the code in Common.js
 * Mac specific case with:
 * Use the IE6 case as the "windows"-case
 * Linux. I have no idea here... (The konqueror issue is apparently a rather common Qt font substitution configuration problem)
 * Unicode and *lang, mufi, polytonic etc. What's the status of all this in IE7 and later ?
 * --TheDJ (talk • contribs) 20:57, 18 May 2008 (UTC)

❌ is only for use when you already know what it is you need changed, and you're certain that it's not going to catastrophically break anything, neither of which seem to be the case here. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 09:25, 19 May 2008 (UTC)


 * I know what I need changed.
 * Move Internet Explorer fixes to IEFixes.css where they belong.
 * Remove the comment hack because it does not work.
 * --Yecril (talk) 11:42, 29 August 2008 (UTC)
 * --Yecril (talk) 11:42, 29 August 2008 (UTC)
 * --Yecril (talk) 11:42, 29 August 2008 (UTC)


 * Again, not specific enough. IEFixes.css still cannot be edited (only devs can). Second, I feel this issue is best served if a few IPA/unicode capable editors start colaborating and draw up an implementation that accounts for most current browsers to fix all current issues. Slapping around the editprotected template won't get it fixed. — Edokter  •  Talk  • 14:45, 29 August 2008 (UTC)


 * All right, redirected to 15692. Let&rsquo;s see what happens.  My proposition is to remove the comment hack ASAP.  --Yecril (talk) 13:49, 22 September 2008 (UTC)


 * Sorry to show up late.


 * The perfectly valid "font-family /**/:inherit;" declaration negates the font specification in every browser which treats CSS comments correctly. (Too bad MS fixed that in IE 7, but left multilingual font display broken.  I'm glad someone has bloated up the javascript to fix their problem using yet another method.)


 * FYI: as near as I can tell, Safari applies "helvetica" to Wikipedia pages by default. The Helvetica font in OS X 10.5 Tiger appears to have a full range of IPA characters. I don't know if earlier versions did or not, but I have never seen any problems with display of IPA in this or older versions of the OS.  Font substitution in Safari/Mac has always worked fine for IPA just about every other language, as long as the OS has a supporting font.


 * "First of all, glyph substitution is fallback and it isn't really intended to be used as much as possible!" Says who?  My OS knows which fonts I have installed, and does a good job.  The display always got worse when Wikipedia editors were trying to second-guess it by applying fonts right in the templates and pages.


 * If there are wide-ranging display problems, then we should fix them (without making it worse for any readers). But I'd like to see some more disciplined test results.  Lukas, did you make those screenshots with only default OS fonts installed?  Which version of Windows?  Which kind of Linux?  Can you add screenshots made in Safari/Windows?  Would you take screenshots of a Wikipedia test page, so we can see the code and its effects in our browsers?24.79.84.230 (talk)  —Preceding comment was added at 08:14, 20 May 2008 (UTC)

Borders for the wikitable class
Resolved.

table.wikitable table {border:none;}

Please, so that tables (like templates) within them are rendered correctly. LA (T) @ 04:13, 18 August 2008 (UTC)


 * I don't think that will solve it. It will instead make it so that tables inside 'tables with class="wikitable"' will have no border, even if they have a border set themselves. I am right now reading up on this since the mboxes like ambox broke when inside 'tables with class="wikitable"'. This has to do with the CSS concept of "selector specificity".
 * It works something like this: The more "body div table.something.something" stuff you put in a class the more points it gets. There seems to be two ways to fix this, either you make the declaration for .wikitable simpler so it gets less points (lower specificity), or you make the declaration for the table within more complex so it gets more points and win. (If equal points the last one declared wins.)
 * Here's an example where ambox looses:


 * And here's an example where ambox should win:


 * And here ambox should also win since equal specificity but ambox is declared later:


 * Each HTML element is worth 0.1, and each class name is worth 1.0. You add the values together. I need to read more and test more, but I haven't the time right now. I will report back when I have verified this by testing it.
 * The problem here is that "table.wikitable td" sets the borders for all child td tags. While for instance the ambox only sets the borders for a td tag that has the "ambox-text" class in itself. So ambox does not damage td tags in other tables placed inside it. I have some ideas how we can make "wikitable" play more nice, I'll test it and report back later.
 * --David Göthberg (talk) 07:46, 18 August 2008 (UTC)


 * David...It has been a while since I have written a web page, but here goes. The CSS that I put in the heading will cancel out the border on any subtable in a class=wikitable. However, the elements within the cells will also have classes so their CSS should supersede the border:none and put their own borders into place. I would say, give the CSS in the header first, and if it fails, then go to the more complicated CSS if needed. LA (T) @ 08:19, 18 August 2008 (UTC)
 * The striken text is because I just tested it, and I was wrong. LA (T) @ 08:31, 18 August 2008 (UTC)


 * I have a solution. It works in my Firefox 2 and my Opera 9, but not in my very old Internet Explorer 5.5. Here's the code:


 * The ">" is the child selector. It means that only th, td and caption tags that actually belongs to the table.wikitable gets those settings. Any other tables placed inside it doesn't get affected at all. It is correct CSS 2.1. If it works in Internet Explorer 6 and up and in Safari then we should perhaps use it. I can't run IE 6 and Safari on my computer. I have prepared a test at User:Davidgothberg/Test31, can someone run that test and report the result here?


 * And I suggest we simply remove this:


 * Since the wikitable has the same background colour as the default  colour, thus no visible difference. And even when a skin makes a difference it is silly, I think if someone goes to the trouble to code mark some text in a table then it should of course get code colour.
 * --David Göthberg (talk) 10:13, 18 August 2008 (UTC)


 * Your testpage works for me in IE7. I agree with removing the 'code' hack. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 11:04, 18 August 2008 (UTC)


 * IIRC (and according to ), IE6 does not support the child selector. Also according to that link, Safari does support it. Anomie⚔ 11:53, 18 August 2008 (UTC)


 * Ouch, if IE6 doesn't support the child selector then we probably shouldn't use it. Since I guess there are still a fair amount of IE 6 users around, right? But we should verify the status of IE6 and Safari ourselves. I have learn't to not trust anything I read on the web. When I read up on the child selector to make the code suggestion above I found pages that claimed that IE 5 and up supported it, but my IE 5.5 does not support it. So, are there any IE 6 and Safari users around that can take a look at User:Davidgothberg/Test31 and tell what they see?
 * If IE 6 doesn't support the child selector, then the next best choice is to lower the "specificity" points for the wikitable class. (See my explanation about that in the beginning of this section.) Since I think the wikitable usually is the outer item (placed directly on the article page and not surrounded by other tables), while templates with tables in usually are placed inside the wikitable. I'll be back with a code suggestion when I have tested it properly.
 * --David Göthberg (talk) 05:28, 20 August 2008 (UTC)


 * I've found quirksmode to be accurate on this sort of thing. If those sites were saying it was supported in "IE5 for Mac", note that that was a completely different browser from IE5 for Windows. It used a completely different rendering engine and reportedly supported quite a bit that IE5 for Windows didn't.
 * When I throw together a quick test and load it up in my Wine copies of IE6 and Safari 3.1, IE6 fails and Safari succeeds. It would still be useful if someone with a "real" copy of either browser confirmed. Anomie⚔ 10:54, 20 August 2008 (UTC)
 * When we're saying it 'fails' do we mean that it fails spectacularly, or just doesn't fix the problem? If the latter, then it would still be an improvement (unless, of course, there's a more reliable method). <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 11:18, 20 August 2008 (UTC)
 * In this case, "fails" means IE6 ignores the CSS statement in question. Thus, for example, if "table.wikitable > * > * > td" were used to apply borders to the cells then IE6 would not apply the borders. Anomie⚔ 12:06, 20 August 2008 (UTC)
 * Which probably qualifies as a 'spectacular' fail :D . Another method, then. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 12:34, 20 August 2008 (UTC)


 * Anomie: Thanks for testing it in IE6 and Safari. I think that is enough for us to trust that we know the truth now.
 * Everyone: I tested with my old IE5.5: If we use the child selector ">" then as Anomie says the cells don't get any border. But we still get the border around the whole table and bolded text in the "th" cells. But an interesting thing is that when we use 'class="wikitable" border="1"' (see next section) then it works fine, then we get a nice border around each cell. So if we let the bots add that 'border="1"' as a side task (as we discussed in the next section) then some time from now most cases will be fixed. Then we can perhaps have a bot fix the remaining cases. And then we can perhaps switch to using the child selector ">".
 * But for the time being the only option left for us is to lower the "specificity" points for the wikitable class. Here is the code for that:


 * I have tested the code in my userspace and it solves it for the ambox and the other mboxes. It will not solve it for all tables inside wikitables, but at least for some of them. (They need to be declared after the ".wikitable" in our style sheets and they need to have a declaration for the td+th tags with at least specificity 1.1, see my examples further up.)
 * --David Göthberg (talk) 05:58, 21 August 2008 (UTC)


 * ✅ Done - I have now updated the code in MediaWiki:Common.css as described in my last example above. And I removed the ".wikitable code" class.
 * --David Göthberg (talk) 17:30, 23 August 2008 (UTC)

Wikitable borders without CSS
Resolved.

I happen to come across this discussion by accident, and since you are already working in this area, I would like to suggest that the code for class=wikitable be adjusted to solve this problem too: meta:Help:Table. --Timeshifter (talk) 11:55, 18 August 2008 (UTC)
 * As far as I can see, solving that issue would require replacing every instance of "class=wikitable" with "class=wikitable border=1", throughout wikipedia, a prohibitively large task. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 12:13, 18 August 2008 (UTC)


 * I have tried doing so for a few charts and tables. :) But it would be nice if the Wikimedia software did it automatically whenever class=wikitable is used in table wikicode. At least for new tables. I don't know about old tables and how things are currently cached. Maybe a bot could do it. I think it would be worth it. Bots do many less important things (in my opinion), so some bots could do this too. --Timeshifter (talk) 13:53, 18 August 2008 (UTC)


 * The 'wikitable' style is entirely an end-user construct - it has nothing more to do with the MediaWiki software than does.  So there's no way it could be done 'automatically' by the core software.  I'm also not entirely sure why it is so vital; given that the majority of reusers of our content are actually using the MediaWiki interface itself, copying our CSS files is a trivial exercise. I don't even want to think about how many instances of "class=wikitable" there are in our database (I would think hundreds of thousands if not millions). <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 15:12, 18 August 2008 (UTC)

(unindent) Help me out here. I am a basic webmaster, but I don't use CSS. So I guess I am using inline styles only. So I assume that the problem I am seeing can't be solved by changing CSS. But couldn't the wikitable icon in the editing toolbar be set up to add the inline style code or internal table element, border=1? I may be asking at the wrong place since this discussion is about CSS. The wikitable icon produces this:

Why couldn't it produce this:

If it did that, then the problem would be solved, I believe. Copying the CSS files is not a trivial exercise for most people because most people aren't experienced webmasters, and I believe most people are just copying Wikipedia stuff into email, basic blogs, basic web pages, etc.. --Timeshifter (talk) 23:25, 18 August 2008 (UTC)


 * I agree, the "Insert a table" edit button should use the more robust code that you suggest here. I have now tested it in my Firefox 2, Opera 9 and my very old IE 5.5, it worked fine in all of them. I see only pros and no cons in adding that code to the button. I looked around, it seems straightforward to add that to MediaWiki:Common.js/edit.js. Should I add it?
 * I have no point of view regarding if we should let a bot fix the existing cases on the pages or not.
 * --David Göthberg (talk) 09:05, 19 August 2008 (UTC)


 * Sounds good to me. Thanks for testing this. Looking at your user page, I assume you know of en:Wikipedia:Graphic Lab/Image workshop and Philip Greenspun illustration project/Requests. I mention this because they are examples of projects putting in a large amount of effort, time, and money to create and improve charts, graphs, diagrams, and other images for Wikipedia. This small change in the wikitable code (over time) will add hundreds of thousands of tables and charts for use even by newbies only using email to pass on the charts and tables. --Timeshifter (talk) 12:08, 19 August 2008 (UTC)


 * Timeshifter, instead of lifting tables from Wikipedia, why not just add a link to the article and section? That way this won't need to be an issue. LA (T) @ 18:45, 19 August 2008 (UTC)


 * It is not about me. I know how to copy, paste, link, create web pages, add borders, etc.. It is about the millions of Wikipedia readers who copy parts of Wikipedia pages and tables, and pass them on in various ways. We encourage people to copy stuff. --Timeshifter (talk) 20:40, 19 August 2008 (UTC)


 * I think that if it can be fixed (or be made 'less broken') by a trivial change such as you suggest, DG, then of course that should be done. I maintain that the problem is itself trivial enough not to justify the marathon effort required to propagate that change to existing tables. <b style="color:forestgreen">Happy</b>‑<b style="color:darkorange">melon</b> 21:25, 19 August 2008 (UTC)


 * Thanks. I just emailed out Legal drinking age to an email list since it is a hot topic in the news currently in the USA. I sent out the whole article and not just the link. That is because it is a snapshot of current laws, and the email list has an archive. The article has tables with the legal drinking age by country. Many people will not follow links in list email. It is easier to just put the info where they can't avoid it. They are interested in the topic, but not always interested enough to open link after link. I first had to add border="1" to all the tables first in the Wikipedia source page. Many people will try to email out parts of various articles with tables with varying success. It can completely baffle people when the table borders do not show up when they paste a table into their email. It is even more baffling when they email out the article anyway, and some people see table borders and some don't. Due to various factors, some of which I can explain ... --Timeshifter (talk) 22:02, 19 August 2008 (UTC)


 * Sending a hyperlink to the snapshot would do the trick. --Yecril (talk) 14:22, 22 September 2008 (UTC)


 * Okay, I have added 'border="1"' to MediaWiki:Common.js/edit.js. So now the "Insert a table" edit button adds that to new tables.
 * Regarding using bots to update old instances of 'class="wikitable"': I think Happy‑melon probably is right that this is a too small thing to be worth having a bot do almost a million edits. Instead I suggest we ask the bot owners that have bots that already edit articles to do this change. That is, make it so that when their bots edit articles for other reasons, then they can at the same time fix the 'class="wikitable"' cases. Thus it won't cost any extra resources, but still most old cases out there will be fixed over time.
 * --David Göthberg (talk) 04:56, 20 August 2008 (UTC)


 * Thanks! By the way, some people reading this may not realize that they need to bypass their cache in order to see the new wikicode produced by the "Insert a table" edit button. I will ask around if bot owners can help out. Is there a "bot central" I can also make the request at? Or several places I can ask at? --Timeshifter (talk) 14:06, 20 August 2008 (UTC)


 * Ah yes, you're right, if people want to see the new change immediately then they need to purge their browser caches.
 * And the place to ask for bots to help out is Bot requests. It's an amazing place, they are very helpful there!
 * --David Göthberg (talk) 22:18, 20 August 2008 (UTC)


 * Thanks again. I bookmarked it. --Timeshifter (talk) 03:47, 21 August 2008 (UTC)

Could somebody explain what problem is being solved here and what side effects are created? The title was just changed to something understandable; now the remainder is to follow. The wikitable style is used all over he place in complicated ways and we don't want to make a mess. &minus;Woodstone (talk) 18:13, 23 August 2008 (UTC)


 * No unwanted side effects as far as we know. And it solves two problems:
 * 1: It now looks much better when Wikipedia pages are shown without style sheets, for instance when a page is copied and sent in an email or saved to disk as plain HTML. Before our change that meant the tables then didn't get any borders at all. Now they fall back to the border="1" and thus look pretty okay in emails etc.
 * 2: More complex to explain. Frankly I only expect the CSS geeks to understand this one, so I suggest you simply trust us on this one. But here's my try at a "simple" explanation anyway: We have a problem with the current wikitable class. It makes it so that tables who are placed inside a table that uses the wikitable class often gets the wikitable borders and colours, even if those inner tables set something else. This often happens when some kind of box template is placed inside a wikitable. There are some ways to fix this, but the best way doesn't work in older browsers (the "child selector" solution), so we can't use that one. If all tables that use the wikitable class also had the border="1" then we could use that method, since then those old web browsers would fall back to use the border="1" instead, which would be pretty okay. For now we instead use the second best method (the "lower specificity" solution). But if/when we ever have updated all tables to use the border="1" then we can switch to the better method.
 * --David Göthberg (talk) 19:12, 23 August 2008 (UTC)


 * Can you state how, where and when the border="1" is added? And you are hopefully not serious to require that all editors now must code: class="wikitable" border="1"? &minus;Woodstone (talk) 19:55, 23 August 2008 (UTC)


 * I'm here because awards table, a template I monitor, had border=1 added. I don't think this is the right way to go – as some have mentioned above, it's not practical to ensure that every use of wikitable also has border=1. Gary King  ( talk ) 21:45, 23 August 2008 (UTC)


 * Woodstone: We have added the border="1" to the "Insert a table" button in the edit window. Thus many or perhaps even most new tables will have the border="1".
 * Woodstone and Gary King: No, we don't require that people use the border="1", but we recommend it.
 * Gary King: The reason to add border="1" is mainly the reason number 1 I stated above: To make our tables readable even when people copy and send Wikipedia pages through email or store them on disk as plain HTML or view them over lightweight interfaces for mobile devices and other such situations where the CSS code doesn't come with the page. There is no other way to achieve that. And adding the border="1" doesn't affect how the table looks on Wikipedia, so it has no negative effects.
 * The goal of reason number 2 will probably never be fulfilled, so you can disregard that one. But the day we decide to not support IE 5 and 6 anymore and thus start to use modern CSS code, then the border="1" will still make the tables readable in those browsers. But I don't expect that all our tables will have border="1". But the more the better.
 * I saw you reverted my edit to awards table and the edit comment you wrote when doing the revert. That shows you had misunderstood the purpose of that edit. My edit didn't change the looks at all of the table for those that surf into Wikipedia. But it greatly improves how that table looks when viewed without the CSS.
 * There are currently about 250 templates that use the wikitable class. I took a look at that list and picked out those that have names that sounded like they perhaps are used on many pages. And then I manually added the border="1" to them. Minimum work, maximum gain. :)) And that is why I happened to edit the awards table.
 * --David Göthberg (talk) 00:08, 24 August 2008 (UTC)


 * I never knew there was an "insert table" button, and even after your pointer it took me minutes to find it. It doubt if many people use it. But as long as the tables display correctly without it in normal browsers that's ok. You say you made the wikitable class "lighter", to allow overrides, but I cannot detect any differences. What was modified? &minus;Woodstone (talk) 08:37, 24 August 2008 (UTC)

Woodstone: Yeah, I had not noticed that "Insert a table" button myself until recently. But since we added the border="1" to that button we see that lots of new tables get that addition, so apparently many people are using that button. But I have no idea if it is a majority or minority of the new tables that are created that way. Another thing we can do is to update the help pages about tables to recommend using border="1".

Yes, I made the wikitable class "lighter". Here is the diff for the edit I made to MediaWiki:Common.css. And here is a simplified example of what I changed and a comparison with the code for the ambox. First the old code:

With the old code above if an ambox is placed inside a wikitable then it looses. Thus the ambox td cells will get wikitable borders, which looks pretty bad.

But in the new code below ambox wins since it has the same specificity points but is declared later, thus the ambox td cells don't get any border.

We could of course instead have increased the specificity of ambox so it wins over the wikitable. Like this:

But then we would have to edit all classes for all boxes that might be placed inside a wikitable. So by lowering the specificity for wikitable we fixed a lot of cases at once, both current and future cases. (And hey, this way saves some CSS code so it makes our CSS files smaller.)

And here is some extra technical details, don't bother about it if you don't understand it: For instance the ambox does not damage the table cells of tables placed inside it, since ambox has the "ambox-text" class placed directly in its own td cells and doesn't say "change the border for all child td cells" like the wikitable does. Unfortunately we can not make the wikitable play as nice, since then people would have to add class="wikitable" to each td cell in their tables. And we can not use the child selector ">" on the wikitable class, since that doesn't work in Internet Explorer 5 and 6.

CSS is messy stuff...

--David Göthberg (talk) 10:02, 24 August 2008 (UTC)


 * Thanks David for your patient explanations. I had been looking at that diff and saw only a few blank lines moved around and no change to the content. Now I see it's not the content, but the definition that is changed. I understand now and am totally reassured. Good work. &minus;Woodstone (talk) 11:29, 24 August 2008 (UTC)