MediaWiki talk:Common.css/Archive 5

This is an archive of past discussions about MediaWiki:Common.css. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 3

→

Deprecated classes

.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 Wikipedia: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 tswiki: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 Wikipedia: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 .spoiler 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)

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)

Not done: please establish a consensus for this alteration before using the {{edit protected}} 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" --TheDJ (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) --TheDJ (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. --TheDJ (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. {{reflist|2}} generates <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 {{Reflist|2}} 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 {{Reflist|2}}.

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 {{Reflist|2}}. 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:

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

—AlexSm 15:49, 30 June 2008 (UTC)

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. Titoxd^{(?!? - 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. Happy‑melon 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 ? --TheDJ (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 <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. --TheDJ (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. class="mainpage-left" vs style="border:1px solid #cef2e0;"); 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 {{imbox}}, {{cmbox}}, 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. Happy‑melon 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 !important 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? Happy‑melon 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. --TheDJ (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:

.reference-accessdate {display: none}

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. Happy‑melon 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 Wikipedia:Village pump (technical)/Archive 122#CSS talkpage detection 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 Wikipedia:Catalogue of CSS classes#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 Wikipedia: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; Wikipedia: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 Wikipedia: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 Wikipedia: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 class="vcard", but that only protects declarations of those classes from interfering with other classes. (By using ".vcard .logo { }".) 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#Double border lines. 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. --TheDJ (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. --TheDJ (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:

table.ambox {
    margin: 0px 10%;
}
.ambox + .ambox {   /* Single border between stacked boxes. */
    margin-top: -1px;
}

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#Add some top and bottom margin. 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#margin_bottom.

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#Simpler to use class names

--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: .pretzels-proposal-header {background:#FFF url('http://wiki.riteme.site/wiki/Image:Faded_globe.PNG') center middle no-repeat} I realise this is going out on a limb, but there seems to be no workaround. My proposal is here, if you're interested Pretzels^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! Pretzels^chatters 15:24, 3 September 2008 (UTC)

Why can't he ask people to input javascript:void(importStylesheet("User:Pretzels/monobook.css")); 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:

/* User:Pretzels background, for testing new main page layout. */
/* Remove this code in December 2008. */
body.page-Wikipedia_2008_main_page_redesign_proposal_Pretzels #pretzelsmainpageproposal-head { 
    background: white url('http://upload.wikimedia.org/wikipedia/en/c/c4/Faded_globe.PNG') no-repeat; 
}

--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#Image gallery colours, 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 Trinitron^TM (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#Font size reduction (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:Infobox#Global bump-up for the font scaling (current thread - Edokter states here that "88% is the only fontsize below the regular fontsize that renders consistently between browsers")
Wikipedia talk:Accessibility#Text size (Feb 2008)
Wikipedia talk:Accessibility#small text (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 <sup> and <small> are set at 90%, and someone does <sup><small>content</small></sup>, 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 style= 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 [talk] [cont] ‹(-¿-)› 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 [talk] [cont] ‹(-¿-)› 21:39, 29 August 2008 (UTC)

Here are more font size discussions:

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. — 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 smaller 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#Global bump-up for the font scaling (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#.references-small -> 92% and MediaWiki talk:Common.css/Archive 2#Please revert "resizing of footnotes by CSS", 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 Wikipedia:CSS, and Wikipedia:Catalogue of CSS classes#Stylesheets and JavaScript 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.

<html> is set to your browser's default font size. For most, this is keyword “medium” which by default renders at 16px.

<body> main.css applies font: x-small sans-serif; , which reduces the size by two keyword steps: 10px.

<div id=globalWrapper> main.css applies font-size: 127%; , with the comment “scale back up to a sane default”: 13px.

<div id=column-content> no font-size adjustment.

<div id=content> no font-size adjustment.

<div id=bodyContent> no font-size adjustment. Normal body text remains at 13px.

<table class=infobox style=font-size:88%> 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 font: x-small sans-serif; 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 <body> would probably improve consistency. Replacing the x-small 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? — Carl (CBM · talk) 21:00, 14 September 2008 (UTC)

Browsershots.org is working again. See [1] 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 ol.references and is it used? This appears to over-ride the font size defined by .references-small with Internet Explorer. --—— Gadget850 (Ed) ^talk - 11:41, 8 September 2008 (UTC)

Span for autosigned text

I am planning to add this style:

.autosigned { font-size: small; }

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? — 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#Text too small. However, if some users find {{unsigned}} too small and they don't mind editing personal CSS file, wouldn't they want to redefine all <small> 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. — Carl (CBM · talk) 20:39, 10 September 2008 (UTC)

I object. per my comments at Template talk:Unsigned#Text too small. 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? — 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#Proposed increase. —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 "!important" 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 "!important" 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:

<span class="unsigned" style="font-size: 90%;"> </span>

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)

If we were to hard-code a font size, font-size: small; 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. — Carl (CBM · talk) 23:14, 10 September 2008 (UTC)

CBM: Okay, since you say "font-size: small;" is better, let's try the different sizes and see how they look:

Normal text: