MediaWiki talk:Common.css/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

→

Archive 15

.keyboard-key

Resolved.

Yesterday AzaToth added the ".keyboard-key" class to MediaWiki:Common.css. It is used in {{keypress}}. As far as I can see he added the class without any prior discussion. Here is the version he added:

/* Style declaration for visual keys descriptions, for [[Template:Keypress]]*/
 
.keyboard-key {
    border-width: 0.2em;
    border-style: outset;
    border-color: #cecbc7;
    background-color: #f0ece8;
    padding: 0.1em 0.4em;
    font-size: 0.8em;
    white-space: nowrap;
}

I think we should change it to look like this:

/* For key descriptions, for [[Template:Keypress]] */
span.keyboard-key {
    border: 0.2em outset #cecbc7;
    background: #f0ece8;
    padding: 0.1em 0.4em;
    font-size: 0.8em;
    white-space: nowrap;
}

These CSS files are loaded by every visitor of Wikipedia, thus we have good reasons to try to keep these files small. Thus my code above uses a shorter comment and a more compact notation for the box border. (And I find the shorter border notation easier to read.) And I added "span" since as far as I know this class is only used in spans, thus I think it makes it clearer where and how this class should be used.

However, {{keypress}} is used on less than 100 pages. And I don't think we are going to style these keyboard-keys differently in other skins. Thus I don't see any reason to have this class here in MediaWiki:Common.css. Those styles can just as well be defined as style="" in the template code. If the class name is still in the template (but doesn't need to be defined anywhere) then users can still style the keyboard keys by adding code in their /monobook.css and using the !important keyword to override the styles. (If we ever decide to style these keyboard-keys differently in other skins then we can at that time add the class here in MediaWiki:Common.css.)

--David Göthberg (talk) 04:46, 23 March 2009 (UTC)

My assumption on seeing the edit was that it must have included blacklisted styles, that can't be added to normal wikitext. However on looking more closely none of the styles added jump out at me as likely to be blacklisted. I agree with DG that if the styles can be applied directly at the template, then they should be applied directly at the template. They're not widely used enough to justify styling here. Happy‑melon 08:25, 23 March 2009 (UTC)

I agree. Common.css styling is only useful if something needs to be override-able by the user or when the CSS is shared with many other templates. One template on 100 pages is not enough.... Besides, with a class name, but the styling in style=, you can at least still accomplish the first case. --TheDJ (talk • contribs) 13:21, 23 March 2009 (UTC)

Perhaps it was premature, the basic idea was both that some page might have rather many keys displayed, so the duplication of the style tag seemed wrong; also, it was a way to enable the use of :before; but it is not that important, so if you feel it's overdoing it, it can pass. _→AzaToth 14:28, 23 March 2009 (UTC)

Oh, this is interesting. How did you plan to use :before in this case? I have no idea how you plan to use it, but normally you should still be able to use ":before" even if we remove the class from MediaWiki:Common.css, since we should of course leave the class name in the {{keypress}} template (so the template can be styled by users by using the !important keyword).

But note that ":before" doesn't work in all browsers, and we can't style output that is placed with ":before", thus I think we should avoid using that as far as possible.

--David Göthberg (talk) 15:59, 23 March 2009 (UTC)

 Removed Happy‑melon 16:44, 23 March 2009 (UTC)

Floating editnotices

Y Done

I am planning to add a little code to MediaWiki:Common.css to fix a problem with right and left floating editnotices. In edit preview such floating notices stick down into the preview area. And in some browsers floating notices even overlap the edit [Show changes] view. This problem would also affect any other system message we show on edit previews, if the message is left or right floating.

I have seen this problem on user pages every now and then, but I don't remember which pages so I can't show any live examples. Instead I have coded up a demo over at User:Davidgothberg/Test51.

We have already done the same fix for category listings since it was much needed there.

All we need to do is to change this code in MediaWiki:Common.css:

/* Prevent boxes from overlapping the category listings */
#mw-subcategories, #mw-pages, #mw-category-media {
    clear: both;
}

To this:

/* Prevent floating boxes from overlapping any category listings,
   file histories, edit previews, and edit [Show changes] views */
#mw-subcategories, #mw-pages, #mw-category-media, 
#filehistory, #wikiPreview, #wikiDiff {
    clear: both;
}

Since my English is somewhat lacking: I appreciate any help in making the comment above that code short and clear, without being too nasty grammatically.

There are other ways we can partially fix this, like hardening the editnotice loader for user pages, but that doesn't fix it for the editnotices and system messages that we admins create. Of course, admins shouldn't do that kind of mistake. But it is anyway much easier for us and more robust to simply harden the preview.

--David Göthberg (talk) 13:28, 27 March 2009 (UTC)

I support this, but i would like to add "#filehistory", which has the same problem. --TheDJ (talk • contribs) 13:40, 27 March 2009 (UTC)

I also support this. I've added #filehistory above, and tweaked the comment a little. Happy‑melon 13:48, 27 March 2009 (UTC)

TheDJ: Hehe, this shows the advantage of first announcing even "obvious non-controversial" additions like this, since people often find some improvements. I tested and you are right, file histories have the same problem and the correct fix is as you suggest. Thanks for finding that one.

Happy-melon: I think it is clearer if the words in the comment and the IDs in the code are in the same order. (By the way, the first three IDs are all for categories.) And I think we should try to keep the comments short since every visitor to Wikipedia loads these CSS files, with comments and all. So I edited my example above to be the way I like it. (But it might still need some grammar fix?)

Here is Happy-melon's version for comparison:

/* Prevent floating boxes from overlapping subsequent sections
   in various places, such as category listings, edit previews,
   file histories and edit [Show changes] views */
#mw-subcategories, #wikiDiff,
#mw-category-media, #mw-pages,
#wikiPreview, #filehistory {
    clear: both;
}

--David Göthberg (talk) 15:12, 27 March 2009 (UTC)

Y Done - And it looks good in my test examples, [1] and [2]. If they still stick down into the section below then as usual you need to bypass your browser cache to see how it looks with the new version of MediaWiki:Common.css.

--David Göthberg (talk) 12:59, 31 March 2009 (UTC)

Bold and nowrap classes

I propose adding the following:

.bold {
   font-weight: bold;
}
.nowrap {
   white-space: nowrap;
}

These would used in Template:·, Template:Nowrap, Template:·wrap, etc in order to decrease the post-expansion size. --- RockMFR 22:48, 27 March 2009 (UTC)

These classes are too trivial for styles that can easily be applied inline. — Edokter • Talk • 23:38, 27 March 2009 (UTC)

They are certainly not too trivial. Many pages transclude them hundreds of times. --- RockMFR 05:55, 28 March 2009 (UTC)

I think RockMFR's idea has some merit. So for starters let's analyse the nowrap class:

1: First of all, this would probably mostly be used in template programming. Since for normal page code we have these:

{{nowrap| Text }}

{{nowrap begin}} Text {{nowrap end}}

2: It would be easier to type and would be easier on the eyes to use for instance:

<span class="someclass nowrap"> Text </span>

Instead of:

<span class="someclass" style="white-space: nowrap;"> Text </span>

Of course, in many templates it would just be

<span class="nowrap"> Text </span>

Instead of:

<span style="white-space: nowrap;"> Text </span>

But that is also shorter, both visually and for the parser and it means less data to send over the wire. (Less data to transfer saves work both for the Wikipedia servers and means faster page loads for users with slow connections.)

3: But it would take some more steps for a new editor to find out exactly what the "nowrap" class means. But since the name is kind of obvious I think that won't be much of a problem. So the class is probably slightly more user-friendly. But still, having a class for it is an extra complication, and is one more thing we can screw up. For instance it will cause problems when people copy our templates to other language Wikipedias.

4: This means that every browser that visits Wikipedia will have to load a slightly larger CSS file, but that many articles will have less data in them. So question is if we use the "dot templates" like {{·wrap}} enough often that this will on average save bandwidth or not? We know that the average user visits five articles in one session. And we know that the CSS files are set to be cached in the browsers for 31 days. But we also know that many browsers reload the CSS files on every session or once a day or so. So we don't really know the ratio between CSS load and page load, but we know it is at least 5 page loads per CSS load.

So I visited a number of random articles and saw that the dot templates are used pretty often. (That is, there were navboxes with dotted lists.) And I think most users visit (large) well established articles, not just any random page, and such articles have a much higher frequency of navboxes. But it's a tough call, I don't know for sure if this will save bandwidth or not. I would have to look at many more pages to know for sure.

Now let's look at the bold class:

1: Some of the pros and cons above does apply.

2: But for bold we have wikimarkup:

'''Text'''

And:

<b>Text</b>

So using <span class="bold"> Text </span> sure wouldn't be easier to type or read.

3: I don't think we will use class="bold" enough often that it will save any bandwidth. Instead I think adding the class to the CSS file will cost more bandwidth in total.

4: Using class="bold" means our text looses its bolding when copied to other Wikipedia projects, or when copied and sent via email (people do that more often than you might think), or when saved to disk if the user doesn't save the "complete" page. (By the way, I think loosing the nowrapping in these situations doesn't matter as much.)

So, in total I think that the nowrap class might be a slight improvement, but I will have to investigate it a lot more to be sure. But I am pretty sure that the bold class would be a net loss. So sorry RockMFR, my recommendation for now is that we do not add these classes.

--David Göthberg (talk) 12:26, 28 March 2009 (UTC)

If those classes would be added (I don't think they should), can we at least settle on a more meaningful name? —Ms2ger (talk) 13:03, 28 March 2009 (UTC)

My reason for adding these wasn't for bandwidth (though overall it will end up saving a surprising amount). These should be added to reduce the post-expand template size, which is real limiting factor in some articles. For navbox templates using these, it decreases the expand size by about 10%. This is a huge amount when you consider the wide usage. --- RockMFR 16:02, 28 March 2009 (UTC)

Another thing to consider is that Template:· may not even need the span it is using - I think bold tags around the dot would give the same result. The span seems to be leftover from when that template used nowrap. If that's the case, we probably wouldn't need the bold class at all. --- RockMFR 16:08, 28 March 2009 (UTC)

Ms2ger: Eh? What would be more meaningful names? And remember, they should be short, otherwise there is no gain in having them.

RockMFR: If I remember correctly: Unfortunately the MediaWiki parser is/was buggy. It internally converts <b> </b> and ''' ''' tags first to bold spans, then back to HTML <b> </b> tags. And its handling of span tags in the intermediate step is buggy, so it mixes up the start and end spans with other surrounding spans. Actually, in a way it is too smart: It fixes when people overlap bold, italics and other tags in the wrong way. Unfortunately sometimes it "fixes" a bit too much. So using the span tag caused the least problems, as far as I remember.

Of course, there is always a chance that MediaWiki has been fixed since then. I probably can dig up my old test examples if someone wants to rerun the tests. (But I won't do the testing, since I have many more meaningful, urgent and interesting things to do.)

Anyway, if you have a problem with the post expand size in an article, then you should seriously consider if you are using too many and too large templates on that article, or you should consider breaking that article up into several articles.

--David Göthberg (talk) 16:57, 29 March 2009 (UTC)

Reducing Print.css

Resolved.

All declarations in MediaWiki:Print.css basically set display:none; The entire page can be significantly reduced.

/* Don't print the following:
/* 1: Do not expand URLs within citations for printing. The URLs should be included explicitly, to avoid confusion */
/* 2: When in mainspace, don't print article message boxes */
/* 3: Don't print navboxes and sisterproject boxes */
/* 4: Removes useless links from printout */
/* 5: Remove noprint, metadata and disambiguation indicators */
#content cite a.external.text:after,
.ns-0 .ambox,
.navbox, .infobox.sisterproject,
#privacy, #about, #disclaimer, .editlink,
.noprint, .metadata, .dablink {
    display: none;
}

Anyone willing to do so? BTW. we should also consider adding .ns-0 #contentSub to this list. It is the redirect notice in mainspace. (Redirected from ....) --TheDJ (talk • contribs) 14:14, 31 March 2009 (UTC)

The concept is sound. "Do not expand URLs within citations for printing" needs some clarification as URL expansion is suppressed only for references using citation templates. Perhaps "Do not expand URLs within citation templates when printing". I think we could use a better description than "useless links".

Perhaps:

/* Do not print:
/* 1: URLs within citation templates */
/* 2: Article message boxes */
/* 3: Navboxes and sisterproject boxes */
/* 4: Privacy, about, disclamer and section edit links*/
/* 5: Noprint, metadata and disambiguations */

--—— Gadget850 (Ed) ^talk - 15:14, 31 March 2009 (UTC)

TheDJ: If your goal was to reduce the number of bytes to transfer, then you failed since your version has more bytes. But that is because you added good comments, so if those comments would be added the old way then your version is more compact. And I find your version more readable than the old version. So I concur with your idea. However, I would like to do some changes (see explanation below the code):

/* 
Do not print:
1: When in mainspace: Article message boxes,
   navboxes and sisterproject boxes
2: Privacy, about, disclaimer, redirect and section edit links
3: Items marked as noprint, metadata or disambiguation
*/
.ns-0 .ambox, 
.ns-0 .navbox, 
.ns-0 .infobox.sisterproject,
#privacy, #about, #disclaimer, #contentSub, .editlink,
.noprint, .metadata, .dablink {
    display: none;
}

/* Don't expand URLs within citation templates when printing. 
   This item placed alone since older browsers disregard
   statements with ":after". */
#content cite a.external.text:after {
    display: none;
}

I changed the comments, partly per Gadget850's suggestion. (And I line wrapped the longer ones so they don't stick too far out for people like me that use smaller screen resolutions.)

I removed the start and end comment markers from all the lines, since they are only confusing and error prone. And I moved the remaining two start and end comment markers to be above and below the text so it is easier to add lines without damaging them.

I added some more ".ns-0", since I think that if someone prints a "Wikipedia:" page or a navbox template page then they probably want to see the boxes.

Older browsers don't understand the ":after" thing, so they disregard it. I have to test if they disregard just that statement, or the entire definition. I will report back on that. But I only have one old browser, so I took the safe path and lifted out the ":after" statement to a separate definition.

--David Göthberg (talk) 16:05, 31 March 2009 (UTC)

Good point. support all your comments. I also added #contentSub (for redirects). --TheDJ (talk • contribs) 17:14, 31 March 2009 (UTC)

I don't think any of the sisterproject boxes still uses infobox.sisterproject btw. Seems to have all been switched to mbox. So we should probably swap those out. (sisterprojects already have the metadata tag). --TheDJ (talk • contribs) 17:31, 31 March 2009 (UTC)

Some still do, e.g. {{Wikinewshas}}. —Ms2ger (talk) 19:06, 3 April 2009 (UTC)

Y Done - I have updated MediaWiki:Print.css with the code shown above.

--David Göthberg (talk) 05:26, 8 April 2009 (UTC)

Happy-Melon's change

HM maed this change. Are we sure that IE-old doesn't error out on that ? --TheDJ (talk • contribs) 12:15, 8 April 2009 (UTC)

According to quirksmode.org, IE doesn't support :target anyways. —Ms2ger (talk) 13:08, 8 April 2009 (UTC)

Indeed: IE hates all three of those rules equally, so lumping them together just means it fails on all three together rather than each one separately :D Happy‑melon 13:56, 8 April 2009 (UTC)

Good point :D --TheDJ (talk • contribs) 14:05, 8 April 2009 (UTC)

Infobox / ambox

Resolved.

Isn't there a way that we can make these two work better together so that the order of the templates doesn't matter. Right now if one puts in

{{infobox}}
{{ambox}}

then the ambox graphic is on top of and obscures part of the infobox.

If the ambox is placed first then it doesn't have this behaviour, but it seems like it shouldn't matter - i.e. the ambox shouldn't overlap other elements on the page regardless of its placement. --Trödel 19:22, 28 March 2009 (UTC)

Unfortunately, not without breaking the template in several usecases on other browsers. The current behaviour was very much selected to be as optimal for as many browser types as possible. --TheDJ (talk • contribs) 19:44, 28 March 2009 (UTC)

Infobox
This is an {{infobox}}.

That's odd. {{ambox}} is specifically designed so it shouldn't overlap anything that floats to the right or left of it. It is instead designed to become more narrow. And look at the examples I added here, it does what it should. We have tested it in lots of browsers. But you should anyway put the ambox first, since then it doesn't become squeezed.

So Trödel, can you link to a page where you have seen the problem? And what browser, browser version, operating system and screen resolution are you using?

--David Göthberg (talk) 17:43, 29 March 2009 (UTC)

Safari does this (in some cases). --TheDJ (talk • contribs) 23:11, 29 March 2009 (UTC)

I have tracked it. In the above case, it is caused by ambox not having any margin at the top, and thus "visually" being "higher" on the page than ambox which has 0.5em of margin at the top. --TheDJ (talk • contribs) 23:25, 29 March 2009 (UTC)

And to be even more specific. It's actually the -1px margin that ambox has that is the trigger for this bug, in this very specific usecase. --TheDJ (talk • contribs) 23:34, 29 March 2009 (UTC)

TheDJ: Gah! You are right, this is the old Safari and Opera float bug. And yes, it has to do with the -1px top margin that ambox uses.

I mixed it up, I thought I remembered it happened when ambox was above the infobox. (We used to have such a bug too...) I was confused by Trödel's statement that the ambox covered the infobox. When really it is the infobox that covers the ambox, at least in Opera. However if there is a right side image in the ambox, then that image covers the infobox. Perhaps that is what Trödel saw? (If he only could have linked to the example he saw and mentioned what browser he uses.) I added a right side image to the example above so those who have Opera or Safari can see what happens.

This is a browser bug and affects any object that floats right or left of an ambox. So it also affects image thumbnails that are shown next to an ambox.

This has previously been discussed at Wikipedia talk:Article message boxes#ambox/float overlapping in Opera and at MediaWiki talk:Common.css/Archive 5#Ambox and cmbox margin problems. The only good solution we have is to give the amboxes some margin. Of course, then they won't stack tight to each other anymore. But I think it is time we change to that, since it is not acceptable that the Opera and Safari users can't see our boxes properly.

Above is how it would look with the fix. I think that looks better than tight stacking. It also gives a little more margin between the amboxes and the text, which is a good thing. (We often get complaints that the boxes stack too tight to the article text.)

Below is an example with an infobox first, with a ambox following it, just like the example at the top of this section. But here it has 3px margins on the ambox, thus it works fine even in Opera and Safari.

Infobox
This is an {{infobox}}.

We have already done this fix in the {{cmbox}}. But the main reason we did if for the {{cmbox}} was that it makes it clearer where the border between two boxes are when there are big boxes with lots of text in. I think that would be true for the amboxes too.

So, do people agree we should give the amboxes 3px top and bottom margin?

--David Göthberg (talk) 01:56, 30 March 2009 (UTC)

Well, before we do that, i think we should test the + selector, like I first said in MediaWiki_talk:Common.css/Archive_5#Ambox_and_cmbox_margin_problems. --TheDJ (talk • contribs) 08:17, 30 March 2009 (UTC)

Sorry for the delayed response - it happens for me on the example above - I am using Chrome (which uses the same engine as Safari if I'm not mistaken). And the original place I saw it had the graphic on the right side of the ambox which overlapped on top of the infobox (which was on top of the ambox as you expected). It was like the graphic bled through the Infobox which was on top. I favor giving it a margin; however, since some favor no margin, what happens with a 0 margin instead of -1? --Trödel 14:13, 30 March 2009 (UTC)

I just reviewed the referenced archive discussion. I agree that the double margins are ugly. I'd go with the 3 px margin as suggested by David above. --Trödel 14:16, 30 March 2009 (UTC)

Here is the example Because it uses {{future building}} one can not adjust the style like one can for a standard ambox. --Trödel 14:24, 30 March 2009 (UTC)

Does the bug occur with a 0px margin? I would prefer the boxes stack properly, even if it means the border becomes 2px as a result. — Edokter • Talk • 14:36, 30 March 2009 (UTC)

With 0px the bug does not appear. If we combine that with the + CSS selector, we have proper behaviour on Safari, FF and IE 7/8 (as far as I know), but with 2px border lines on IE6. I'm not sure how this behaves in Opera, but it should be supported there as well. table.ambox + table.ambox { margin-top: -1px; } --TheDJ (talk • contribs) 15:22, 30 March 2009 (UTC)

Infobox
This is an {{infobox}}.

The above example works fine in Chrome. Note that I edited {{future building}} to use cmbox - which doesn't exhibit the same issues. --Trödel 16:35, 30 March 2009 (UTC)

Trödel: You should not use {{cmbox}} in articles, cmbox means "category message box". I reverted your edit to {{future building}} so it now uses {{ambox}}. Ambox = "article message box". Instead I fixed the Gila Valley Arizona Temple article by putting the ambox above the infobox. If you have the infobox first then the ambox becomes very squeezed in lower screen resolutions such as 800x600 and becomes even more weird on handheld units.

--David Göthberg (talk) 22:38, 30 March 2009 (UTC)

Thx - I was wondering why there was a cmbox and an ambox - I just figured it was version 3 of mbox :) - should have read the documentation --Trödel 23:08, 30 March 2009 (UTC)

TheDJ: You are right, there is the option to use the CSS adjacent sibling selector "+". Then it seems we can stack tight and get a single border in most browsers, without getting overlapping boxes in Opera and Safari.

Personally I prefer 3px margins, I find that better looking and easier to read. But some users prefer no margin (tight stacking).

But before we get into the design discussion: Let's test if the "+" selector works well enough, so we know if tight stacking even is an option. So gentlemen, I ask that you add the code below to your personal /monobook.css page, then wait a minute, then bypass your browser cache, then reload this page and check that all the examples here look okay in all browsers you have. And then report the result here. (The "!important" keyword in the code is to override the hardcoded styles in the examples above.)

table.ambox {
    margin: 0px 10% 0px !important;
}
table.ambox + table.ambox {
    margin-top: -1px !important;
}

My results are: Works fairly well in all three of my browsers, my slightly old Firefox 2.0, my slightly old Opera 9.02, and my very old IE 5.5. I no longer see any overlaps in my Opera, and all boxes stack tight. But I of course see a 2px border between the amboxes in IE 5.5 since it doesn't understand the "+".

Then don't forget to remove that code again from your personal /monobook.css pages, since it screws up the amboxes that use "small=left". If/when we use this code in MediaWiki:Common.css then we won't use the !important keywords. But it will still screw up the small amboxes (when we have removed the currently hardcoded small styles from ambox). I will try to figure out how to prevent the "+" code from screwing up those small amboxes, it will be an ugly CSS hack... (See? 3px margins are much better!)

--David Göthberg (talk) 22:38, 30 March 2009 (UTC)

This change works fine for me in Chrome - I reverted the change on the page I originally saw the problem on and it works there as well --Trödel 23:05, 30 March 2009 (UTC)

I just figured that we might as well set border-top: 0px.... That is probably safer... --TheDJ (talk • contribs) 23:08, 30 March 2009 (UTC)

table.ambox {
    margin: 0px 10% 0px !important;
}
table.ambox + table.ambox {
    border-top: none !important;
}

I don't think we should change from tight stacking to 3px margins for no reason what so ever. The format was carefully chosen, and i don't want to rattle any cages when it's not really necessary. And in my opinion the "small" mbox is a hack in itself, so no wonder that it breaks. --TheDJ (talk • contribs) 23:15, 30 March 2009 (UTC)

And in the mbox-small case.

1. Why is there border collapse ? Do we have mbox that contain borders? Because as far as i know this property only affects cell borders.
2. Why reset the top and bottom of a margin? for small ? should other defaults be used in the small case ? Seems weird to me.

--TheDJ (talk • contribs) 00:12, 31 March 2009 (UTC)

I have made this change to my css file - is there a page that demonstrates the use of ambox with the small parameter? --Trödel 00:40, 31 March 2009 (UTC)

Trödel: The small amboxes are for instance demonstrated in the {{ambox}} documentation. That is, click this link: {{ambox}}.

TheDJ:

3: Darn. Your "border-top: none;" idea seemed so nice. But it breaks in all browsers if two amboxes are stacked and the top one is more narrow due to some floating box before it. Then it gets visible that the lower one has no border. I added an extra ambox to Trödel's example above so it gets full width below the infobox in all browsers, so you can see what happens. (That infobox is just enough tall to make it so in some browsers the second ambox in Trödel's example gets full width, while in some browsers only the third ambox gets full width.) So it seems the "+" with -1px top margin is the only decent solution if we stack the boxes tight.

4: The small mbox isn't a hack, it uses perfectly fine standard CSS that works in all browsers. It's really the big amboxes that are more of a hack. Anyway, I have already designed and tested the CSS we need for the small mboxes to win over the new "+" ambox class. That is, so the small class gets higher "CSS specificity" and thus don't get overridden by the "+" class. By the way, I would like to place the small classes after all the other mbox code, since then the small classes only need equally high specificity. I think one should always aim to use the lowest possible specificity, since that makes the class easier to override (for instance style in other skins). But Happy-melon‎ insisted on having them before, thus they unfortunately have to have extra high specificity. (And that part is perhaps a bit hackish.)

1: When not using "border-collapse: collapse;", then different browsers give very different margins and padding. (And I mean the margins around the whole box, and the paddings inside the box.) So using border collapse makes our boxes look more the same in all browsers. The right-floating small mboxes really use border collapse too. But it is not obvious from the code, since it is not in the ".mbox-small" class since all the other mboxes already have border collapse in their default styles. (But there now are some right-floating boxes in article space that use the small class, so we might need to add border collapse to the ".mbox-small" class itself. I'll have to investigate that.)

When we made the left-aligned small amboxes we again ran into the problem that different browsers gave very different margins and padding when not using border collapse. And since the default ambox style doesn't use border collapse, then we had to add it to the ".mbox-small-left" class instead. If we add 3px borders to the big ambox, then we should give it border collapse too. I haven't experimented with it for ages, so I don't remember if there was any specific reason why the ambox default style doesn't use border collapse, perhaps we just didn't need it when having no margins?

2: When we designed the left-floating small amboxes we simply reused the old well established right-floating mbox style. (That style is actually much older than the mboxes, although we have tweaked it a little since then.) Thus we used 4px top and bottom margin for the left-floating small boxes too. Of course, you kind of have a point that for ambox (article space) it might be logical that the small boxes stack tight just like the big boxes do. But there are several reasons why I think we should not stack the small boxes tight:

A: That will get them closer to the text, something people have been complaining about for the amboxes all since we made them.

B: The small boxes are for sections, and we mostly only have one box at the top of a section. So how they stack towards each other doesn't matter much.

C: And considering the problems we have with the tight stacking big boxes then I didn't want to carry those problems over to the new small style.

--David Göthberg (talk) 02:02, 31 March 2009 (UTC)

Thx for the link - I should have come back and noted I found the small box samples on the documentation pages for the different mboxes. BTW - the addition of the third mbox in a row above caused the last mbox to shift to the right about a cm and does not have a top margin drawn on it in Chrome. --Trödel 03:26, 31 March 2009 (UTC)

However it does work if the infobox is lengthened. see this in the history --Trödel 03:29, 31 March 2009 (UTC)

We can't trust that the right floating box always is long enough. The floating box can be a small thumbnail image and there might be several cleanup boxes on top of each other. Or there might be two cleanup boxes in a section further down, right at the point where a long infobox happens to end. And the example with a lengthened box that you link to doesn't work in Firefox, since in Firefox that infobox still isn't long enough.

So it seems the best option we have (for tight stacking boxes) is to use TheDJ's original solution with the "+" with -1px top margin. I'd like to deploy that now, since it seems to work well enough. And I want to move the small classes to below all the mbox classes so they can override the mbox classes using as low specificity as possible. Do you people concur?

(For those that don't know what CSS specificity means: Don't worry, we'll take care of that. I can link you to some reading, but it will only give you a headache. It takes a lot of reading and experimenting to get a hang of...)

--David Göthberg (talk) 12:09, 31 March 2009 (UTC)

I support your proposed changes. --TheDJ (talk • contribs) 13:00, 31 March 2009 (UTC)

Sounds good to me. Now if we can only get the webkit guys to fix the multiple column link issue - my footnotes will be back to normal and I'll be happy :) --Trödel 13:02, 31 March 2009 (UTC)

Y Done - I have added the fix to MediaWiki:Common.css. But I used ".ambox + .ambox" instead of "table.ambox + table.ambox", since that saved me from changing the mbox-small classes. (Now it doesn't matter where we place the mbox-small classes.) The first example in this section now looks good also in my Opera 9.02.

TheDJ: Please accept my apologies for not listening to you properly. You suggested this fix ages ago.

All Opera and Safari users: Sorry that we didn't get around to fix this until now.

--David Göthberg (talk) 01:00, 10 April 2009 (UTC)

Print tweaks issue

Resolved.

Certain printing tweaks such as the examples at Help:User style#Print view tweaks no longer work. Any ideas? --—— Gadget850 (Ed) ^talk - 13:38, 8 April 2009 (UTC)

"don't work" is not really a good enough description, can you be a bit more exact ? --TheDJ (talk • contribs) 14:09, 8 April 2009 (UTC)

Certainly:

/* save ink and paper with very small fonts */
@media print {
    #footer,
    #content,
    body { font-size: 8pt !important; }
    h1 { font-size: 17pt }
    h2 { font-size: 14pt }
    h3 { font-size: 11pt }
    h4 { font-size: 9pt }
    h5 { font-size: 8pt }
    h6 {
        font-size: 8pt;
        font-weight: normal;
    }
}

This should reduce the font size of the printable version, but has no effect. --—— Gadget850 (Ed) ^talk - 14:21, 8 April 2009 (UTC)

It works in my browser. (Firefox 2.0 on WinME.)

Have you tried to wait a minute after the last change to your /monobook.css and then bypass your browser cache? And are you really using the monobook skin?

Even if you have bypassed your browser cache you might need to do it again, since MediaWiki:Common.css contained a serious error today between 11:23 and 11:59 UTC. Some browsers might have choked on that.

We did update MediaWiki:Print.css today. But I checked that code again, it should not affect your code. And as I said, it works in my browser.

And what browser, browser version and operating system are you using?

--David Göthberg (talk) 16:43, 8 April 2009 (UTC)

FireFox 3.08/WinXP, FireFox 3.08/Vista, IE7/Vista. Bypassed and purged multiple times since I started to play with this last night. My monobook.css has only these rules and monobook.js is now empty. If I just add:

    body { font-size: 8pt !important; }

Then the font in the article body does change, so I am sure that part is working. It just does not work when inserted in @media print. --Gadget850 (talk) 17:06, 8 April 2009 (UTC)

Just tested, it works in my Opera 9.02 too.

I hope you are not testing it by clicking on the "Printable version" in the Wikipedia "toolbox" menu? Since that doesn't work. You have to use the "Print preview" in the "File" menu in your web browser.

--David Göthberg (talk) 18:49, 8 April 2009 (UTC)

The word of the day is "frack"; the prize goes to David. I will take a SWAG that the printable font rendering is done by the browser during the print process? --Gadget850 (talk) 19:38, 8 April 2009 (UTC)

Hehe, another Cyloncomputer bug squashed! :))

And yes, your conclusion is right, it is the browser that decides what media type is currently valid. It works something like this:

When you view pages in your browser on your computer screen as usual, then they are of the type "@media screen". And when you print to paper, or do print preview in your browser then the type is "@media print".

The confusing part here is the "Printable version" in the Wikipedia "toolbox" menu. Your browser thinks that is just a normal web page. So it has the type "@media screen". And the "Printable version" really is just a normal web page, but the Wikipedia servers strip away all the menus and other surrounding stuff, and only keep the article content. I think it was originally meant so you can print the contents of the page, without getting those pesky menus etc. on the paper. Since our browsers didn't use to know what parts of a page it should strip away when printing. But they do now, see below. So nowadays it is mostly just a kind of print preview.

So what the "@media print { }" statement in the code above does is to tell the browser: "Use these styles only when printing".

Nowadays we use a lot of "@media print { .some-menu-class { display: none; } }" statements in the Wikipedia CSS files. That means we tell the browser to hide all those menus when printing. So nowadays we automatically only print the article content, without having to take the detour over the "Printable version". Nifty, isn't it?

You can read more about media types in the official CSS standard. (That link goes straight to the right page about the media types.)

--David Göthberg (talk) 20:21, 8 April 2009 (UTC)

Thank you very much. I just might file the serial numbers from your explanation and stuff it into Help:Printable as I try to make it a useful help page. I'm really a printer hardware guru, but I keep having to learn all this software stuff. --Gadget850 (talk) 20:30, 8 April 2009 (UTC)

I was experimenting with this only this morning (trying to finally work out what to do with the 40 lines of plainlinksneverexpand declarations we've got). The only difference between the HTML of the normal version and the "printable version" is which stylesheets are called, and in what order. Happy‑melon 20:24, 8 April 2009 (UTC)

Well and the fact that you are of course still in a "screen" mode as far as the browser is concerned. That's why @media print commands are not visible when you just click "printable version". --TheDJ (talk • contribs) 21:25, 8 April 2009 (UTC)

After reflecting on this, I am questioning the usefulness of printable version. See Help talk:Printable#Printable version. --Gadget850 (talk) 13:23, 9 April 2009 (UTC)

Making the preview bar... well, a preview bar

The current and the proposed preview header

I'm sure I'm not the only one who hates how poorly the preview message is segregated from the actual preview text. It looks like just another heading, indeed it is just another heading. With a little CSS, however, we can make it look like every other editnotice we use, which is IMO a huge improvement.

#wikiPreview > h2:first-child { display: none; }
.previewnote { 
    clear: both; 
    margin: 0.2em 0; 
    border: 1px solid #aaa; 
    background: transparent; 
    padding: 0.25em 0.9em; 
    text-indent: 0; 
}

The first line is indeed CSS3, which won't be supported on older browsers (although it is on IE7, amazingly). However, that line is just to hide the "preview" h2 ; it's not a showstopper if that header is still visible. On standards-compliant browsers it is, IMO, a big improvement. Thoughts? Happy‑melon 21:31, 8 April 2009 (UTC)

I just tried your code. If there is an editnotice above and a message box below (at top of article), then your preview notice gets really squeezed and not very visible. It just becomes a stack of boxes.

So I like the old default preview header better. Actually, I like the old header better even when there are no other surrounding boxes. Sorry.

--David Göthberg (talk) 21:48, 8 April 2009 (UTC)

Maybe a different border would make it standout more. border: 1px solid #ff0000; -- WOSlinker (talk) 23:34, 10 April 2009 (UTC)

Needs more top and bottom padding (maybe 0.4 or 0.5em). It might need a background color to stand out, too. Border also, maybe. A very good idea, though. Don't know about it being squashed though. This, that and the other _[talk] 08:01, 11 April 2009 (UTC)

I have thought more about this. To me the preview header is not only a message, it is also a delimiter. Above it we have editnotices and other such system messages, and below it we have the preview. Both the line under the "Preview" header and the line under the explanatory message looks like horizontal rulers, making it very much a delimiter.

Happy-melon is suggesting to use a box. But a box is not a delimiter, it is just a boxed message. But I think the preview header should be a delimiter and not just a boxed message. So I don't like Happy-melon's suggestion.

I added the screen dumps above so people can have a look. (Happy-melon made that image and showed it in other places, I just added it in this section.)

--David Göthberg (talk) 17:21, 11 April 2009 (UTC)

I think this is a great idea, the current one is hard to see. I think while we are doing this we should add a temporary dismiss button to hide the edit notice once when it is clicked. This is because the edit notice screws with position: absolute; parameters making me save multiple times to align it correctly. Thanks -- penubag  (talk) 20:21, 11 April 2009 (UTC)

word-wrap

cite {
    font-style: normal;
    word-wrap: break-word;
}

This is totally invalid: there is no property "word-wrap", as the error console on Firefox unhappily informs me every time I load a page. I am fairly certain that what was intended is this:

cite {
    font-style: normal;
    white-space: nowrap;
}

Am I missing something? Or can I make this change? Happy‑melon 14:26, 9 April 2009 (UTC)

CSS3 property. https://developer.mozilla.org/web-tech/2008/08/20/word-wrap-break-word/ --TheDJ (talk • contribs) 14:45, 9 April 2009 (UTC)

I see. So FF3 chokes on it why? :D Happy‑melon 16:10, 9 April 2009 (UTC)

Because only the nightlies support it so far. Second, this used to be an IE only property, but was later adopted by the CSS standards body. Whadda ya know, Microsoft created something useful :D --TheDJ (talk • contribs) 18:48, 9 April 2009 (UTC)

Firefox 3.1 (3.5) beta has it, or seems to. This, that and the other _[talk] 07:57, 11 April 2009 (UTC)

Performance issue caused by 282880677

Resolved.

I've reverted back to 282815267 due to a performance problem for Firefox users when viewing history pages. The addition of the ".ambox + .ambox" line appears to be what is causing the problem. Zomg CSS can do wacky things! --- RockMFR 19:18, 13 April 2009 (UTC)

Yikes, that's a nasty thing to be causing the errors reported. I've restored the other changes that (hopefully) aren't related. Happy‑melon 19:35, 13 April 2009 (UTC)

Honestly, this is a disgrace of the greatest kind. I cannot believe that FF falls over this problem SO hard. I find it such a disgrace that i will visit their IRC channel in a few minutes. In the mean time, i'm guessing adding table.ambox +table.ambox instead will make it significantly faster... --TheDJ (talk • contribs) 20:12, 13 April 2009 (UTC)

RockMFR: Not that any kind of bug surprises me anymore, but why do you think it is the ".ambox + .ambox" code that is causing the problem? We have had both "table.navbox + table.navbox" and "div.NavFrame + div.NavFrame" in MediaWiki:Common.css for quite some time without problems. I see that you left a comment at T19240 where you say that it has to be coded as "table.ambox + table.ambox" to not cause problems in Firefox. How did you come to that conclusion?

And please, don't anyone rush on and add "table.ambox + table.ambox" since it breaks the mbox-small classes. Let me fix that, I know how to do it without breaking the mbox-small classes. If anyone wonders: We added that code to fix a rather nasty float bug in Safari and Opera. See section Infobox / ambox above.

--David Göthberg (talk) 21:29, 13 April 2009 (UTC)

Breaks how? Does ".mediawiki table.mbox-small" have a higher specificity than "table.ambox + table.ambox"? If so, yuck :D we'd have to make it "html body.mediawiki table.mbox-small", and that's the highest specificity that it's possible to have :S Nowhere to go after that... or do you have a more cunning solution? Happy‑melon 21:48, 13 April 2009 (UTC)

Reading the reports, it's also a 3.1 only issue. probably a regression from earlier versions. And the fact that disabling histrowinit() solves the problem, indicates that it's actually the script that is becoming slower due to this change, and not the primary rendering itself. --TheDJ (talk • contribs) 21:59, 13 April 2009 (UTC)

Definitely not a 3.1-only issue. I've reproduced this on 3.0.8. --- RockMFR 23:25, 13 April 2009 (UTC)

Happy-melon: No, that's not the highest specificity it can have, there are several IDs you can use too, like #globalWrapper. But of course I have a more cunning solution. Simply use "body.mediawiki table.mbox-small" but place the mbox-small classes after all the other ambox/tmbox/ombox etc classes. I already tested that some time ago, works in all my browsers.

TheDJ: Nope, not a 3.x only issue. I use Firefox 2.0 and when I tested earlier today I hanged on a 250 long history list for some minutes. That was before RockMFR's "fix". I just tested once then. It didn't happen when I tested now. But people are saying it is intermittent, so we don't really know if it is fixed, right? And if my very old computer only hangs for some minutes just like the other, then it means it probably is a time out phenomenon and not just something that costs too much work.

RockMFR: I still want to know why you think it is the ".ambox + .ambox" code that caused it.

--David Göthberg (talk) 01:00, 14 April 2009 (UTC)

The issue is not intermittent. It is reproducible 100% of the time with the line in, and 0% with the line removed. --- RockMFR 01:09, 14 April 2009 (UTC)

Right, I have now tested it on the CSS page I load from my localhost web-server. I added and removed it several times, and you are right, it is reproducible 100% of the time.

But I still wonder, how did you find out? Why the big secrecy about how you found out?

--David Göthberg (talk) 01:48, 14 April 2009 (UTC)

Careful, DG, those IDs aren't consistent across skins (no globalWrapper in cologneblue, for instance). I was hoping you'd forget that we could just move them (:D), you know I'm not a fan, but I guess if it's a choice between that and making the declaration significantly more esoteric, we should go for that. Needs a good explanatory comment, of course, and I think we should move all the mbox-* declarations together, to at least keep them coherent. Happy‑melon 10:42, 14 April 2009 (UTC)

Looks like you guys are working on this, but the change to the ambox means that the if the infobox is above the ambox then the formatting is not correct in Google Chrome anymore. See Gila Valley Arizona Temple for an example. Please do not change the order as this is the test page I use for making sure this is working correctly - TIA --Trödel 03:03, 14 April 2009 (UTC)

Trödel: Yes, we are going to fix it so things look right in Safari, Opera and Chrome again. We are just discussing some details.

Happy-melon: Oh, thanks for the warning about that those IDs don't work in some skins. I didn't know that.

I don't want to move the other mbox classes down. I prefer to place things in the order they override each other, even when specificity allows us to put them in the wrong order. I find that more logical. And the other mbox classes are overridden in the ambox section.

And here is the code and comment I am thinking of using for the mbox-small classes:

/* These mbox-small classes must be placed after all other 
   ambox/tmbox/ombox etc classes. "body.mediawiki" is so 
   they override "table.ambox + table.ambox" above. */
body.mediawiki table.mbox-small {   /* For the "small=yes" option. */
    ...
}
body.mediawiki table.mbox-small-left {   /* For the "small=left" option. */
    ...
}

--David Göthberg (talk) 00:06, 15 April 2009 (UTC)

Gosh, this thread is a bit of a mess! Still we seem to be back in chronological order now. That comment looks good, and on second thoughts I agree with you about keeping the order of 'precedence' intact. So yes, actually do split them up. Happy‑melon 09:25, 15 April 2009 (UTC)

Y Done - I have added the "table.ambox + table.ambox" code to fix the Safari + Opera float bug. And I have placed the mbox-small classes after all the other ambox/tmbox/ombox etc classes to override the ambox+ambox declaration. All seems shipshape, my Firefox 2.0 doesn't choke on long history lists, and boxes float fine in my Opera 9.02.

--David Göthberg (talk) 19:38, 15 April 2009 (UTC)

Awesome guys! Thanks --Trödel 22:02, 15 April 2009 (UTC)

Metadata and dablink

Resolved.

The "metadata" and "dablink" classes are listed in MediaWiki:Print.css, and make it so items that use them are not printed. I would like to change their declaration so they only prevent printing when on article pages, since when we print pages in other namespaces we usually want to see all content.

The metadata class is currently used in templates for article space such as the {{ambox}}. We have actively removed the metadata class from templates only used in other spaces, so that they will print. But some templates are used in both article space and other spaces, and then we usually do use the metadata class, since it is more important how the printing of articles look.

It would be nice it the article templates could be printed when they are shown/demonstrated/discussed on other pages. Try viewing Wikipedia:Template messages/General in print preview and you will see what I mean.

There is also the "noprint" class. But we can't make that one print in other spaces since it is declared in common/commonPrint.css, a file which we admins can't edit. We also redeclare the noprint class in MediaWiki:Print.css, but that is mostly for clarity. But I think it can be a good thing that noprint always means noprint, since there might be some items in other namespaces that we actually never want to print. Although I have no idea what kind of items that would be.

So I would like to change this line in MediaWiki:Print.css:

.noprint, .metadata, .dablink {

To this:

.noprint,
.ns-0 .metadata,
.ns-0 .dablink {

--David Göthberg (talk) 23:51, 15 April 2009 (UTC)

I support this suggestion. And noprint indeed should always mean "don't print ever". --TheDJ (talk • contribs) 00:44, 16 April 2009 (UTC)

Agree completely, although I threw in a couple of linebreaks above which I think make it clearer what's going on. Noprint should mean No Print. Happy‑melon 09:58, 16 April 2009 (UTC)

Y Done - Thanks guys for the sanity check and confirmation. I have now updated MediaWiki:Print.css. Happy-melon, you are reading my mind. I was going to add some line breaks when deploying it, I just wanted to keep the code example simple.

--David Göthberg (talk) 10:28, 16 April 2009 (UTC)

Another one

The fragment

#EnWpMpBook { background-image: url("http://upload.wikimedia.org/wikipedia/en/7/7e/MP-open-book.png"); }
#EnWpMpSearch { background: url("http://upload.wikimedia.org/wikipedia/en/a/ae/MP-magnifying-glass.png") no-repeat top right; }
#EnWpMpSearchInner { float: right; width: 20em; text-align: center; }
#EnWpMpBook2 { background-image: url("http://upload.wikimedia.org/wikipedia/commons/8/8e/MP-open-book2.png"); }

seems to have been added in October 2005, for "testing purposes" for the proposed mainpage redesign. They don't feature on the current main page or the page linked from the edit summary, and I've never seen those background images in use anywhere on wikipedia. Ok to remove? Happy‑melon 19:17, 16 April 2009 (UTC)

I did a search in all namespaces for all those ids but I found no usage, I only found some old discussions. Seems you are right. So I concur, remove that code.

--David Göthberg (talk) 22:24, 16 April 2009 (UTC)

 Removed Happy‑melon 10:46, 18 April 2009 (UTC)

InChI and persondata

.InChI was added in November 2007 to some dispute, I think its "temporary" nature has probably expired by now. Only AFAIK used in {{InChI}}, to which I just added inline styles.

Not so sure about .persondata, it's certainly used on {{persondata}} which is much more widely used than {{InChI}}. But I still don't see why CSS declarations are required: surely the desired effect could be used by setting class=wikitable and display=none on the template? Happy‑melon 19:33, 16 April 2009 (UTC)

I'd say remove them. There's little reason to require non-styling metadata classes to be present in Common.css, especially if they're duplicating other classes in the process. 「ダイノガイ千？！」^{(Dinoguy1000)} 20:02, 16 April 2009 (UTC)

I say remove both. I have moved the .persondata declarations to {{persondata}} (like you did to InChI), but I'm not sure if it is used on any other templates. — Edokter • Talk • 20:23, 16 April 2009 (UTC)

It looks like just the one, although it has a whole WikiProject to support it... Happy‑melon 20:52, 16 April 2009 (UTC)

Darn... It wasn't without consequences. — Edokter • Talk • 22:54, 16 April 2009 (UTC)

Luckily, the fix I suggested works. — Edokter • Talk • 23:08, 16 April 2009 (UTC)

I agree, remove those classes. Using style="display: none;" on the template should work just as well. And note that the line "speak: none;" should not be necessary when there is "display: none;". (But sometimes "speak: none;" is used anyway, just to make sure.)

--David Göthberg (talk) 23:42, 16 April 2009 (UTC)

 Removed Happy‑melon 10:29, 17 April 2009 (UTC)

.notice

Does anyone know where or whether the "notice" style:

/* Style for "notices" */
.notice {
    margin: 1em;
    padding: 0.2em;
}

is actually used? Unfortunately it's a bitch to search for... Happy‑melon 09:30, 17 April 2009 (UTC)

Isn't this from the pre-ambox period ? --TheDJ (talk • contribs) 09:54, 17 April 2009 (UTC)

Confirmed, was used by the old disambig, and expand-section notices etc.. Currently only {{uw}} seems to be using it I think. Note that userwarnings are substituted..... :( --TheDJ (talk • contribs) 10:05, 17 April 2009 (UTC)

Well if that's the only one we don't need to worry: the styles here are overridden by inline styles in that template anyway. Happy‑melon 10:28, 17 April 2009 (UTC)

Yes, the "notice" class is from the pre-{{dmbox}} period. And yeah, before the other mboxes it was probably used in many more places.

Right, {{uw}} has had hardcoded styles that override both the margin and padding in the "notice" class since its first version. So at least with that one we should be safe. But we can't know what other substituted boxes have been using that class. This just goes to show the problem of substitution, we should forbid any substitution of boxes that have CSS classes and CSS ids...

I searched template space for "class notice" (without the " "), and found no usage cases of the notice class, except {{uw}}. But yeah, searching the other namespaces isn't doable since I get too many hits on other things. We could ask the nice people over at Wikipedia:Bot requests to run a smarter search on an off-line copy of the database. They do such runs there, they helped me before. But I think it might be overkill. Since all that class does is to add some margin and padding. So if we remove it the usage cases won't break horribly, they will just get less margin and padding.

The real nastiness would be if someone in the future would reuse that class name for a class that does something much more visible, thus any old substituted boxes might break horribly. Should we perhaps keep a list of "removed class names and ids, never to be used again" at the bottom of Wikipedia:Catalogue of CSS classes? (Or would that be a case of WP:BEANS?)

--David Göthberg (talk) 21:02, 17 April 2009 (UTC)

I don't think it's a security risk to keep such a list, since the only attack vector is to readd the classes to the site CSS doing something wildly different, which only admins can do. I think we can trust admins not to shove beans up our noses...

I would absolutely love a __NOSUBST__ behavior switch to place on Template:Foo that meant that {{subst:foo}} substituted to {{foo}} rather than the contents of the template. There are a lot of bugzilla bugs on similar issues that have been closed in all sorts of ways.

I agree that even if we break things by removing the class, it's not going to be significant breakage, all it will do is crush the margins in a little. And it makes our CSS that bit tidier and more compact. Happy‑melon 10:44, 18 April 2009 (UTC)

Incidentally, DG, what prompted you to write out the full page link to BEANS and then pipe it to the acronym?? :D

I don't mean that keeping the list of names to avoid is a security risk, as in "attacks". What I mean is that when future admins see the names in that list they might think: "Oh, good name, hasn't been used for ages, let's use that!". Or they might subconsciously remember a name they have seen in the list when they want to make a new class. So they perhaps won't even know they got the idea from that list. But as you said, I guess we have to assume that "admins do not shove beans up their noses". Although I have seen them do it many times. (Figuratively speaking of course, our Wikimedia pub nights here in Sweden aren't that wild! Besides, every kid in Sweden knows you don't stuff beans up your nose, we use peas for that. :)

Actually, I think it might be possible to make it so a template substitutes in its own name instead of its code when being substituted. But it would mean really ugly template code...

And regarding my WP:BEANS link: I claim temporary insanity. Or kind of, since I was very tired when I wrote that, almost falling asleep at the keyboard.

--David Göthberg (talk) 02:49, 19 April 2009 (UTC)

 Removed Happy‑melon 09:25, 19 April 2009 (UTC)

MediaWiki:Noarticletext

It would be nice to have this message have the same appearance as other system messages styled using the {{fmbox}} styles. However, the div that surrounds the message is given its own styles in monobook/main.css, which means simply using fmbox on the message produces a wierd 'nested' appearance. We could get around this by using styles here to 'cancel' the styles set in the default CSS, but much better simply to apply the fmbox styles to the div itself. We already do this for a number of messages using the "fmbox-warning" style; you can see that code already in place. The style we need here, however, is "fmbox-system", which is similar but has a light-grey background. As such, I intend to add the following:

div.noarticletext {
    clear: both;
    margin: 0.2em 0;
    border: 1px solid #aaa;
    background: #f9f9f9;
    padding: 0.25em 0.9em;
}

Comments? Happy‑melon 13:26, 21 April 2009 (UTC)

I agree with the addition of that code. And I agree that MediaWiki:Noarticletext should have the light grey system message background. I have done some checks and tests, your code is correct.

We have a similar issue with MediaWiki:Readonly lag. It can't use any wikimarkup at all, so it can't use {{fmbox}}. It is currently using transparent background. I would like to set that one to use our standardised margin and border, and preferably also the light grey system message background. If/when we add the style declaration above to Common.css, then we could add "#mw-readonlylag," above it to make MediaWiki:Readonly lag use it too.

Or we could add "div.fmbox-system," to the declaration above, and then add class="fmbox-system" to the div in MediaWiki:Readonly lag. I think that would be clearer. Since I don't want to style ids, I prefer to use them only for javascript to be able to efficiently find the boxes. And instead use classes for the styling, when possible. Thus avoiding using the id for two different things. But I have a feeling that Happy-melon doesn't want a "div.fmbox-system" class...

--David Göthberg (talk) 14:19, 22 April 2009 (UTC)

Lol! I think the solution to that particular issue is to bugfix the system message to accept wikimarkup, if that's possible. It should be; the message appears when the slave databases get too far out of sync with the master, so write actions on the master are prohibited to stop the situation getting any worse until the slaves catch up. It should still be possible to read from the slaves (or the master) to get any additional data that's needed as a result of allowing wikimarkup. I'll have a dig for it and maybe file a bug.

You're right that I don't particularly want to add div.fmbox-system, but it would be preferable to styling the id; I fully agree that that's not a good idea. Happy‑melon 14:36, 22 April 2009 (UTC)

Woho! So you agree to make the code above begin like this?

div.fmbox-system,
div.noarticletext {

If we add that, then I will document it properly in the {{fmbox}} /doc.

And regarding that MediaWiki:Readonly lag can't handle wikimarkup: Nah, don't bother filing a bug about it. It's good to also avoid reading from the database servers when they are lagging. (Of course, some editors trying to save pages probably cause much less database reads than all the readers accessing pages that are not in the cache servers.)

--David Göthberg (talk) 15:27, 22 April 2009 (UTC)

What, don't file a bug because it might hurt performance, or don't file a bug because if it got fixed I'd want the div.fmbox-system code removed? :D Hehe. It needs a proper comment, but I'll live with it...

/* Hardcoded fmbox "system" style messages, used in
  [[MediaWiki:Noarticletext]] and [[MediaWiki:Readonly lag]] */
div.fmbox-system,
div.noarticletext {
    ...

Happy‑melon 15:44, 22 April 2009 (UTC)

Nah, I'm not that sneaky. I just thought why bother the devs with it? They have more urgent things to handle, and we can handle this case nicely ourselves. And here is how I would like the CSS comment:

/* For div based "system" notices in the same style as fmbox. */
div.fmbox-system,
div.noarticletext {

Or perhaps:

/* Div based fmbox "system" style messages. */
div.fmbox-system,
div.noarticletext {

And then as usual we should document in Wikipedia:Catalogue of CSS classes where this class is used. I think that better matches the comment we have on the div based warning style. And your term "hardcoded" doesn't feel right to me, since in many cases we can hardcode using tables too. So to me "div based" is the key.

Or since it isn't clear that the "div.noarticletext" is a message-specific class since it doesn't start with "mw-", then maybe (but just maybe) make the comment like this:

/* Div based fmbox "system" style messages. Used in 
   [[MediaWiki:Noarticletext]] and [[MediaWiki:Readonly lag]]. */
div.noarticletext,
div.fmbox-system {

Note that I have put the page names in the comment and the class names in the code in the same order. Which we put first doesn't matter to me.

--David Göthberg (talk) 16:55, 22 April 2009 (UTC)

Well I just asked for SVN commit access myself, so the next time Brion checks his emails, I might be able to fix these things myself... I like the last of your proposed comments. I think it's important to say where the styles are used, or you might get overzealous admins <whistle> randomly removing the styles because they think they're unused...</whistle> :D Happy‑melon 17:38, 22 April 2009 (UTC)

 Added Happy‑melon 19:01, 23 April 2009 (UTC)

IPA/Unicode/Polytonic

I seem to be on a css roll, so moving along; all this code:

/* Support for Template:IPA, Template:Unicode and Template:Polytonic.
   The inherit declaration resets the font for all browsers except IE6,
   which chokes on the empty comments. Please copy any changes to
   [[Template:IPA fonts]] and [[Template:Unicode fonts]]. */
.IPA {
    font-family: "Charis SIL", "Doulos SIL", Gentium, GentiumAlt, "DejaVu Sans", Code2000, "TITUS Cyberbit Basic", "Arial Unicode MS", "Lucida Sans Unicode", "Chrysanthi Unicode";
    font-family /**/:inherit;
}
.Unicode {
    font-family: Code2000, Code2001, "Free Serif", "TITUS Cyberbit Basic", "Doulos SIL", "Chrysanthi Unicode", "Bitstream Cyberbit", "Bitstream CyberBase", Thryomanes, Gentium, GentiumAlt, "Lucida Grande", "Free Sans", "Arial Unicode MS", "Microsoft Sans Serif", "Lucida Sans Unicode";
    font-family /**/:inherit;
}
.latinx {
    font-family: Code2000, Code2001, "TITUS Cyberbit Basic", "Microsoft Sans Serif";
    font-family /**/:inherit;
}
.polytonic {
    font-family: "Athena Unicode", Gentium, "Palatino Linotype", "Arial Unicode MS", "Lucida Sans Unicode", "Lucida Grande", Code2000; 
    font-family /**/:inherit;
}
.mufi {
    font-family: Alphabetum, Cardo, LeedsUni, Junicode, "TITUS Cyberbit Basic", ALPHA-Demo;
}

Is apparently designed to execute only on IE6. Since we're in the business of using hacks here anyway, using this would seem to be a more targetted approach. Plus, will IE6 cough and die if we add some linebreaks so it doesn't run to five screen widths? That is, will this code work?

/* Support for Template:IPA, Template:Unicode and Template:Polytonic.
   The declarations with "*-" are ignored by all browsers except IE6
   (http://www.blackbeltcoder.net/2008/07/02/ie6-only-css-syntax-hack/).
   Please copy any changes to [[Template:IPA fonts]] and
   [[Template:Unicode fonts]].
*/
.IPA {
    *-font-family: "Charis SIL", "Doulos SIL", Gentium, GentiumAlt,
                   "DejaVu Sans", Code2000, "TITUS Cyberbit Basic",
                   "Arial Unicode MS", "Lucida Sans Unicode",
                   "Chrysanthi Unicode";
}
.Unicode {
    *-font-family: Code2000, Code2001, "Free Serif", "TITUS Cyberbit Basic",
                   "Doulos SIL", "Chrysanthi Unicode", "Bitstream Cyberbit",
                   "Bitstream CyberBase", Thryomanes, Gentium, GentiumAlt,
                   "Lucida Grande", "Free Sans", "Arial Unicode MS",
                   "Microsoft Sans Serif", "Lucida Sans Unicode";
}
.latinx {
    *-font-family: Code2000, Code2001, "TITUS Cyberbit Basic", "Microsoft Sans Serif";
}
.polytonic {
    *-font-family: "Athena Unicode", Gentium, "Palatino Linotype",
                   "Arial Unicode MS", "Lucida Sans Unicode",
                   "Lucida Grande", Code2000; 
}
.mufi {
      font-family: Alphabetum, Cardo, LeedsUni, Junicode,
                   "TITUS Cyberbit Basic", ALPHA-Demo;
}

I also suspect that the .mufi declaration is supposed to be IE6 only in the same way as teh others. Thoughts? Happy‑melon 15:42, 9 April 2009 (UTC)

According to Template talk:Mufi, it is used for certain characters mapped in the Private Use Area, hence the forced selection of particular fonts supporting this encoding is crucial irrespective of the browser. — Emil J. 16:35, 9 April 2009 (UTC)

I note that not a single article uses this template. I propose to merge this back to the template, it's hardly useful here. (remember to keep the class in the template so users can overwrite if needed.) --TheDJ (talk • contribs) 18:57, 9 April 2009 (UTC)

 Done, removing .mufi and adding the *- for the others. Unfortunately, it results in a lot of validation errors... is this desirable? Happy‑melon 13:03, 11 April 2009 (UTC)

I think the old solution with using "font-family /**/:inherit;" seems to be the better one. Since now I also get a lot of errors in my Firefox 2.0 error console, thus making it hard to debug pages. Oddly enough my Opera 9.02 error console doesn't show any errors at all. And those 33 errors we now get in the W3C CSS Validation Service are scary.

--David Göthberg (talk) 18:06, 11 April 2009 (UTC)

Happy-melon: I see you have changed back to the older code. And we now only get the old 5 errors in the W3C CSS Validation Service. Thanks.

--David Göthberg (talk) 19:42, 15 April 2009 (UTC)

I don't know if this is the place to ask, but some users complain that the IPA class, for example in {{IPA}}, forces the IPA loop-tail gee (ɡ) to display as a gamma (possibly γ?). This bug is discussed at Wikipedia:International_Phonetic_Alphabet#Voiced_velar_plosive. Is it possible to tweak the IPA class to avoid those fonts? kwami (talk) 22:38, 21 April 2009 (UTC)

I just remembered the following MediaWiki_talk:Common.js/Archive_Nov_2007#IPA_style_for_IE, when I noticed that we had an IPA in Common.js as well. The code is not DESIGNED to work only with IE6, it just stopped working with IE7 although still required. This reiterates our need for an IEFixes.css I think. What do you guys think. --TheDJ (talk • contribs) 22:49, 26 April 2009 (UTC)

I'd fully support that. Happy‑melon 07:23, 27 April 2009 (UTC)

Nospeak class

The previous section reminded me of some code I have in my to-do list. I would like to add this code to MediaWiki:Common.css:

/* "nospeak" class for items that should be seen but not heard.
   The following is correct, but the W3C validator doesn't accept it. */
.nospeak { 
    speak: none; 
}
@media speech, aural {
    .nospeak { 
        display: none;
        speak: none; 
    }
}

The code gives us a "nospeak" class that we can add to any item that we want to display visually, but not be read out by screen readers. The code declares the class in several ways so it should work in both old and new screen readers. There is a slight silliness: The W3C CSS Validation Service gives an error for the speech media type. In spite that "aural" is deprecated and "speech" is the new media type, specified in CSS 2.1.

--David Göthberg (talk) 23:45, 16 April 2009 (UTC)

Sounds like a good idea: the more abstract the classes we can make, the better. We have quite a few "don't display" rules, but I don't see that they can easily be combined. However, this should prevent any further proliferation except where genuinely necessary. Happy‑melon 09:27, 17 April 2009 (UTC)

Does any screen reader even support speak: none;? —Ms2ger (talk) 17:04, 17 April 2009 (UTC)

It was a long time ago we discussed these styles. I don't remember on which talk page, and I can't find it even with a Wikipedia search on all namespaces, weird. Anyway, I just had the result of that discussion in my to-do list, which is the code you see above. (Yes, I am over a year behind in my to-do list.) I remember someone pointed us to a table on some other website. The table listed which nospeak markup was supported by which speech software. The table showed that different speech software supported very different nospeak markup, some of them supported more than one markup, and some didn't honour any nospeak markup at all. So we concluded that the only way to cover as many speech sofwares as possible is to throw in all the markup we know of. Besides, all the markup above is correct and valid. And it doesn't cause any problems in any of my browsers (Firefox 2.0, Opera 9.02 and a very old IE 5.5).

Ms2ger: "speak: none;" is in the CSS 2.1 specification and as I interpret it it is the main way to suppress speech in CSS 2.1.

I think we should consider the addition of the nospeak class as an experimental addition. We can't guarantee it will work, but when it works we will save our "listeners" some time. And when it doesn't work, then it's no change from now. Let's see what things our editors will mark as "nospeak".

--David Göthberg (talk) 20:18, 17 April 2009 (UTC)

I was surprised to read that, but it is indeed (in an informative appendix).

I'm not sure if we should add it, though… It sounds a little too much like "hiddenStructure" to me. —Ms2ger (talk) 16:36, 18 April 2009 (UTC)

I think this is kind of the opposite to the old hiddenStructure hack. HiddenStructure did hide content for seeing users, but often failed to hide it for hearing users. And it was a silly way to hide things, since parser functions do a better job. While nospeak will hide content (if possible) for hearing users, content that we seeing users are seeing. Presumably content that is just annoying to hear. So if the hearing users hear it, they hear what we already see. So it won't be like with the hiddenStructure where seeing editors left lots of code and text in the page code, just because they thought it was invisible and would not be visible to anyone. But yeah, there is a risk that seeing users will assume that nospeak always works, and thus do bad things with it. Think of people adding ASCII art and then claiming that "nospeak will save the hearing users from hearing this". Oh the horror!!!

I admit I myself don't care that much about the nospeak class. I think I mostly put it together back then since there were some discussions/demands from the people from Wikipedia:WikiProject Accessibility. So my vote on adding this class is perhaps just "weak support". But still, it would be interesting to see how people would use it.

--David Göthberg (talk) 01:27, 19 April 2009 (UTC)

BTW. I asked User:Graham87, who has commented on this before, and he stated that speech/aural modes have hardly improved in the past year. All that CSS is still pretty much unused by ANY screenreader. So I don't really think we have a usecase for this at all unfortunately. :( However, on IRC we have been talking in -tech that it might be a good idea to create a "basic" skin that can be used for all the "media" types that we currently do not support (everything but screen, handheld and print), because these media types are currently largely "unskinned" in the mediawiki software. --TheDJ (talk • contribs) 12:08, 26 April 2009 (UTC)

Request

{{Editprotected}}

#bodyContent a[href ^="http://wiki.riteme.site/"] {
    background: none !important;
    padding-right: 0 !important;
}

Inserting the above code will remove external link icons on all links that lead to some place on http://wiki.riteme.site. I don't understand how this request can be controversial because it is a fix of a problem. An external link icon is for external links, not internal links. A fix should not be controversial. It is the same type of situation as this. Also see this discussion. If this does require discussion, then please start one and try to get as many users involved in it as possible so it is closed as soon as possible. This is a problem and needs to be fixed. Thanks. -- IRP ☎ 22:05, 28 April 2009 (UTC)

Oppose; not supported by IE. — Edokter • Talk • 23:51, 28 April 2009 (UTC)

Is it possible to create one that is supported by Internet Explorer? -- IRP ☎ 23:59, 28 April 2009 (UTC)

As far as I can see, no. It would have to be fixed in MediaWiki itself. — Edokter • Talk • 00:07, 29 April 2009 (UTC)

What about the secure server ? --TheDJ (talk • contribs) 00:25, 29 April 2009 (UTC)

(edit conflict) The lock icon will not be removed. The code above will only affect links that lead to pages within http://wiki.riteme.site/, not https://secure.wikimedia.org/. -- IRP ☎ 00:42, 29 April 2009 (UTC)

I'm not against this, but I do think it is a bad idea. This should be solved in the software, and it's likely even easy to do so. If anyone feels like coding a patch, replaceExternalLink(), includes/Linker.php and includes/parser/Parser.php should likely be points of interest according to Splarka and Simetrical. LinkHolderArray has all the iw and local links. --TheDJ (talk • contribs) 00:40, 29 April 2009 (UTC)

I was just requesting this as a temporary quick fix until Parser::replaceInternalLinks() is fixed. -- IRP ☎ 01:48, 29 April 2009 (UTC)

I understand, but still. One of my other fears is that people will forget to use class "plainlinks" where needed, because most "advanced" users would not have the ext.link symbol anymore, but IE users would still see it. It's one of these cases, where I think that hiding the problem will do as much harm as not hiding it. Like I said, no specific preference here. —TheDJ (talk • contribs) 19:40, 29 April 2009 (UTC)

Do you know where I can request a rewrite of the parser function? It has to be rewritten before it is used. -- IRP ☎ 20:32, 29 April 2009 (UTC)

You know that there's already a bug for it. If you want to do more, you'll either have to do it yourself or start bribing people. --Amalthea 20:44, 29 April 2009 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit protected}} template. — Martin (MSGJ · talk) 06:31, 29 April 2009 (UTC)

sup.reference

I've noticed there is often a need to add {{nobold}} or {{noitalic}} around <ref/> elements. I think that, in fact, it would never be desirable to have a bold or italic reference link, so I suggest adding the following code:

sup.reference {
    font-weight: normal;
    font-style: normal;
}

Comments? —Ms2ger (talk) 15:19, 30 April 2009 (UTC)

Sounds like a good idea to me. Happy‑melon 15:43, 30 April 2009 (UTC)

This will only apply to <ref> tags and not <references />, right? If so, sounds good to me. --MZMcBride (talk) 17:42, 30 April 2009 (UTC)

I have no problems with such an addition. —TheDJ (talk • contribs) 18:13, 30 April 2009 (UTC)

• No problem with it either, but when does one ever have a reference in the middle of bolded or italic text, and not at the end? Amalthea 19:09, 30 April 2009 (UTC)

I don't see any issues here; is that an example of a problem? ---— Gadget850 (Ed) ^talk 19:19, 30 April 2009 (UTC)

I figured it was intended mostly for table headers. --MZMcBride (talk) 20:59, 30 April 2009 (UTC)

I'm guessing that in infoboxes and stuff this could be handy. —TheDJ (talk • contribs) 14:36, 1 May 2009 (UTC)

Those are indeed the cases I noticed —Ms2ger (talk) 11:44, 2 May 2009 (UTC)

 Added Happy‑melon 10:56, 2 May 2009 (UTC)

Thanks —Ms2ger (talk) 11:44, 2 May 2009 (UTC)

Thumb backgrounds

When someone uses [[File:Foo.jpg|thumb]] on a user page, the background color is that annoying light blue. Which is fine if you don't override it in your /monobook.css subpage like I do. Is it possible to set the background color to none or transparent or inherit or something to make everyone happy? --MZMcBride (talk) 03:27, 1 May 2009 (UTC)

I'm confused, can you specify the specific backgrounds you are talking about above ? I have no idea when you talk abou the standard page background, standard thumb background and the self defined backgrounds.. —TheDJ (talk • contribs) 14:14, 1 May 2009 (UTC)

I override the nasty light blue with white. I think I just need to add code for .thumb ... --MZMcBride (talk) 05:41, 2 May 2009 (UTC)

Not quite sure what you mean either, but if you want to change the background of thumbed images, use .thumbinner {background:transparent;} — Edokter • Talk • 11:53, 2 May 2009 (UTC)

Plainlinks, redux

Looking through our current common.css, I recall the discussion we had a while ago about the plainlinks implementation. I dug through the archives, and was somewhat embarassed to realise that it's no less than five months since we essentially concluded what needed to be done. Essentially the decision was to completely deprecate the plainlinksneverexpand class in favour of the existing plainlinks implementation, and a new class nourlexpansion to handle the url expansions when printing.

As such, I intend to change the whole plainlinks section from this:

/*Add formatting to make sure that "external references" from [[Template:Ref]] do
  not get URL expansion, not even when printed. The mechanism up to MediaWiki 1.4 was
  that the HTML code contained a SPAN following the anchor A; this SPAN had the class
  "urlexpansion", which was not displayed on screen, but was shown when the medium was
  "print". The rules below ensure (a) that there is no extra padding to the right of
  the anchor (displayed as "[<number>]"), (b) that there is no "external link arrow" for
  the link, and (c) that this SPAN of class "urlexpansion" is never shown.
  ~~~~
*/
.plainlinksneverexpand {
    background: none ! important;
    padding: 0 ! important;
}
.plainlinksneverexpand .urlexpansion {
    display: none ! important;
}

/* Make sure that ext links displayed within "plainlinksneverexpand" don't get
   the arrow...
*/
.plainlinksneverexpand a {
    background: none !important;
    padding: 0 !important;
}

/* With MediaWiki 1.5, the mechanism has changed: instead of a SPAN of class "urlexpansion"
   following the anchor A, the anchor itself now has class "external autonumber" and the
   expansion is inserted when printing (see the common printing style sheet at
   http://wiki.riteme.site/skins-1.5/common/commonPrint.css) using the ":after" pseudo-
   element of CSS. We have to switch this off for links due to Template:Ref!
*/
.plainlinksneverexpand a.external.text:after {
    display: none !important;
}
.plainlinksneverexpand a.external.autonumber:after {
    display: none !important;
}

To this:

/* Add formatting to make sure that "external references" from templates 
   like [[Template:Ref]] do not get URL expansion, not even when printed.
   The anchor itself has class "external autonumber" and the url expansion
   is inserted when printing (see the common printing style sheet at 
   http://wiki.riteme.site/skins-1.5/common/commonPrint.css) using the
   ":after" pseudo-element of CSS. We have to revert this.
*/
.nourlexpansion a.external.text:after,
.nourlexpansion a.external.autonumber:after {
    display: none !important;
}


/* The legacy implementation of this was with "plainlinksneverexpand", which
   also simulated "plainlinks".  "plainlinksneverexpand" is deprecated and 
   should be replaced with "plainlinks nourlexpansion".  When this has been
   done, the rules below can be removed.
*/
.plainlinksneverexpand a {
    background: none !important;
    padding: 0 !important;
}
.plainlinksneverexpand a.external.text:after,
.plainlinksneverexpand a.external.autonumber:after {
    display: none !important;
}

Then, as described in the archive discussion, wait for decaching, then switch over the relevant templates to no longer use plainlinksneverexpand, then remove the second section. Any issues? Happy‑melon 14:46, 9 April 2009 (UTC)

I still support the original suggestion. I'm not sure if we have all cases covered, but personally, i don't see "the surpression of url-expansion in print" breaking for a short while as a huge problem when we did have an oversight. --TheDJ (talk • contribs) 18:51, 9 April 2009 (UTC)

 Doing... - new code is in, we can make the transition on May 12 or whenever we get bored (I agree that it's hardly earth-shattering if it briefly breaks). Happy‑melon 12:02, 11 April 2009 (UTC)

I just realized. Shouldn't "nourlexpasion" be in Print.css ? --TheDJ (talk • contribs) 12:56, 26 April 2009 (UTC)

That would probably make more sense, indeed. —Ms2ger (talk) 12:13, 1 May 2009 (UTC)

I think you're right (I was waiting for another comment, but AFAIK they're only added when Print.css is also called). I've added the rule over at Print.css; so we can actually remove the whole nourlexpansion section from here on 1 June. Happy‑melon 13:24, 1 May 2009 (UTC)

Usages

T means it needs to be corrected a 2nd time AFTER may 11.

Done:

• {{navbar}}
• {{include timeline}}
• {{rp}} [3]
• {{lx}} [4] - T
• {{ed}} [5]
• {{ed2}} [6]
• {{edi}} [7]
• {{edit}} [8]
• {{ed right}} [9]
• {{ed right2}} [10]
• {{ref}} [11] - T
• {{Coord/link}} [12] - T

Not Done:

• Please add additional cases of plainlinksneverexpand usage if you can find them !

Plainlinks

We also need to add a plainlinks definition to Common.css

/* this can be used in the content area to switch off
special external link styling */
#bodyContent .plainlinks a {
	background: none !important;
	padding: 0 !important;
}

This is because plainlinks is officially only defined for the monobook skin, and we are setting link symbols outside monobook as well. The alternate idea is to move all link symbol definitions to MediaWiki:Monobook.css. —TheDJ (talk • contribs) 19:19, 4 May 2009 (UTC)

Investigated. Of all the skins, only modern and monobook have a "plainlinks" definition. —TheDJ (talk • contribs) 18:19, 6 May 2009 (UTC)

 Added —TheDJ (talk • contribs) 18:29, 6 May 2009 (UTC)

T20708 Happy‑melon 19:45, 7 May 2009 (UTC)

Thanks ! —TheDJ (talk • contribs) 20:00, 7 May 2009 (UTC)