MediaWiki talk:Common.css

From Wikipedia, the free encyclopedia

This talk page is automatically archived by Werdnabot. Any sections older than 31 days are automatically archived to MediaWiki talk:Common.css/Archive 3. Sections without timestamps are not archived.
Comment

This is the common CSS for all the skins. Use it only for styling things within the content area (stub notices, message boxes, spoiler/disambiguation messages, etc).

The following stylesheets call this one:
edit
Archive
Archives
  1. July 2005 – December 2005
  2. January 2006 – August 2006
  3. September 2006 –

Contents

[edit] metadata

I have some trouble exactly defining what this class is ment to me used for, it's defined only as:

/* Metadata */
table.metadata {
    border: 1px solid #aaaaaa;
    display: none;
    speak: none;
}

wich makes no sens at all (border and display:none for the fist, and defined for tables only for the second). I think it's ment to be like this:

.metadata {
    display: none;
    speak: none;
}

Off course this will require a lot of maintenance templates to be changed, as a lot of notices are defined as metadata. →AzaToth 15:34, 14 October 2006 (UTC)

The class is intended for the Wikipedia:Persondata effort. It is used by the {{Persondata}} template. Also, I think the notices generally use .messagebox, not .metadata. As far as I know, only Persondata uses that class. Mike Dillon 22:32, 21 October 2006 (UTC)
Templates like {{Cleanup}} are using the class metadata →AzaToth 14:55, 22 October 2006 (UTC)

Thanks for pointing out the more widespread use of .metadata. I looked at Wikipedia:Catalogue of CSS classes to see what it said about .metadata and it doesn't match with the current usage in CSS. The note about .metadata was added by User:JesseW in March 2006. The description "Used to mark metadata that should not be printed (?)" seems to be an attempt to describe this rule in Common.css, which at that time did just what it does now, completely hides all tables of class .metadata while giving them a thin grey border when they made visible (for all media, not just print).

The creation of the Persondata project page and the addition of this CSS rule were done on December 22, 2005 by User:Kaldari. This is where it gets interesting. I looked at the history of {{Cleanup}} to see if it was using .metadata on the day this rule was added to the stylesheet. It was using the .metadata class and moreover, the template was also using a <table>! So on December 22, all cleanup notices became invisible in CSS browsers. On seeing this, User:Beland reverted {{Cleanup}} to a previous version that used a <div> on December 23 with the message "The blue box is no longer showing up for me; reverting to older non-broken version", not suspecting that the cause of the problem was really with the new CSS rule added by Kaldari.

The class used by {{Persondata}} should be changed, since it is just in one template, and this rule should be changed to match the new class. Mike Dillon 15:35, 22 October 2006 (UTC)

Also, as with the hiddenStructure problem, it has been pointed out that Wikipedia:Persondata should not be done with CSS hiding because of accessibility concerns. Mike Dillon 15:45, 22 October 2006 (UTC)

The change I would recommend is changing the CSS selector in the rule above to use the #persondata id instead of the .metadata class:

/* Persondata */
#persondata {
    border: 1px solid #aaaaaa;
    display: none;
    speak: none;
}

That way it can target what it is intended for. The .metadata class on {{Cleanup}} and others predates {{Persondata}}, so the earlier, more widespread use should not have to change. Mike Dillon 00:00, 23 October 2006 (UTC)

That sounds fine to me. I just went with a more generic class name since I thought similar projects might also want to make use of the class, but that hasn't happened. I was not aware that there were any other templates using a class named "metadata". Sorry for the confusion. Kaldari 06:57, 23 October 2006 (UTC)
Migrating from .metadata to .persondata will be a bit tricky. As best as I can figure out, the steps for such a migration would be:
  1. Add new .persondata class
  2. Edit Persondata template to use .persondata class
  3. Wait until all 3,000 or so article caches have been refreshed (no idea how long this would take)
  4. Remove the .metadata class
Two questions: Is this the best way to proceed? Is there a specific time-to-live for article caches or would we have to wait until every article has been edited or purged? Kaldari 00:55, 25 October 2006 (UTC)
Most changes to templates go live immediately: all the appropriate pages are just purged from cache, and are rerendered the next time someone visits. The only exception is category links, since those take much longer to update; those are done on the job queue, as time permits (see Special:Statistics for how long the queue is at any given time). At least, that's my impression. —Simetrical (talk • contribs) 01:16, 25 October 2006 (UTC)
I'm not talking about .persondata, but #persondata. Since the id="persondata" is already on the template, there will only be the issue of CSS caching, about which browsers are pretty aggressive. I would change the CSS rule to "#persondata" first and remove class="metadata" in a day or two. Mike Dillon 01:45, 25 October 2006 (UTC)
Wouldn't the use of #persondata break the formatting if the Persondata template were used more than once in a article, for example in Wright Brothers or Brothers Grimm (hypothetical examples)? Kaldari 02:12, 25 October 2006 (UTC)
Yes. Mike Dillon 02:49, 25 October 2006 (UTC)
Uh, then I guess I'll proceed with the original plan, if that seems best. Kaldari 03:11, 25 October 2006 (UTC)
Cool. I think the multiple id thing was discussed at Wikipedia talk:Persondata once upon a time and my feeling is that it should be dealt with if and when it actually becomes a problem. Thanks for your help. Mike Dillon 03:25, 25 October 2006 (UTC)

Persondata is now visible on Wiki pages, and causing some angst (e.g. a well-meaning user deleted the persondata from John Howard). I think this is due to the latest change to the commons.css. Rocksong 09:13, 27 October 2006 (UTC)

Yes, this is now a major problem. Persondata is visible, and many users are deleting it from pages. We need to fix this right away. – Quadell (talk) (random) 15:35, 27 October 2006 (UTC)
Kaldari's changes were sound. The problem was almost certainly CSS caching in the affected users browsers. I think there just needs to be a few days wait to let everyone pick up the latest version of Common.css and then the change to {{Persondata}} will be safe to make. The only reason Persondata would have started showing up is if the user's browser had not yet picked up the new .persondata classes. Internet Explorer in particular is very aggressive about caching CSS. Mike Dillon 16:17, 27 October 2006 (UTC)
As I stated in Wikipedia talk:Persondata, I think we need to apply both classes to the template, for the time being. That way, anybody who has an old copy of the stylesheet in their cache won't see the persondata. After a while (months?) the extra class can be removed. —TheMuuj Talk 21:52, 27 October 2006 (UTC)
OK, I'll wait a month or so before making the switch. Unfortunately, it is not possible to assign two classes to the same template, but I'll be sure to wait an additional month or so before removing the .metadata class from Common.css. Does anyone know if there is a hard limit on how long Explorer will cache a CSS file? Kaldari 22:32, 1 November 2006 (UTC)
As I have stated before, we can apply both classes to an element, so I went ahead and did so. My custom stylesheet works, as should most previous stylesheets. —TheMuuj Talk 03:30, 2 November 2006 (UTC)
Thanks for updating the {{Persondata}} template. The declarations for table.metadata and .metadata-label can be removed from MediaWiki:Common.css. For those who aren't keeping track of all this:
  1. {{Persondata}} now has both .metadata and .persondata
  2. That means it is hidden for anyone with an old copy of Common.css (without .persondata), since the template still has .metadata
  3. It also means the template would be hidden for anyone with a new copy of Common.css if table.metadata were removed, since the template now has .persondata
  4. For anyone who wants to see Persondata, this would similarly work whether or not table.metadata and .metadata-label were removed from Common.css, since the template still can be made visible using either of its two CSS classes
  5. Once table.metadata and .metadata-label are removed from Common.css, all remaining coordination can be done within the Persondata project
It should be possible using search to find users with "table.metadata" in their monobook.css and tell them to change to table.persondata. Once that is done and the docs are updated, in a couple weeks the "metadata" classes can be removed from {{Persondata}}. Mike Dillon 04:05, 2 November 2006 (UTC)

Here's the search. Mike Dillon 04:12, 2 November 2006 (UTC)

Don't remove .metadata just yet. I'm not convinced this is a better plan than our original course of action. For one thing not all browsers support multiple class definitions. I haven't researched this yet, but I know that at least Netscape 4 doesn't. We should try to make sure that the impact of this change is as minimal as possible. It may be that TheMuuj plan is the best course of action, but let's not rush into it without thinking everything through and getting agreement first. Kaldari 05:51, 2 November 2006 (UTC)

Every browser created in the last 4-5 years supports multiple CSS classes. Netscape 4 is totally negligible. Having 10 years of web development experience, I can tell you that TheMuuj's plan is the best course of action. Mike Dillon 15:19, 2 November 2006 (UTC)
If you both think that's the best way to go, I'll trust your judgement. Kaldari 16:13, 2 November 2006 (UTC)

Now that over a month has passed, does everyone think it is reasonably safe to remove the .metadata class? Kaldari 19:35, 3 December 2006 (UTC)

Should be OK. We can try removing the "metadata" and "metadata-label" classes from the template first and see if anyone complains. It should have the same effect since it will make the CSS declaration have no effect. Perhaps a temporary link could be put into the template to tell people who are seeing it without enabling personal CSS where to report problems. Mike Dillon 20:14, 3 December 2006 (UTC)
Unfortunately, search seems to not be working at the moment, so we can't see if there are still people with "table.metadata" in their CSS. Those people will stop seeing the Persondata box. I expect there probably are... Mike Dillon 20:22, 3 December 2006 (UTC)
I just ran the search and it shows 175 hits for "table.metadata" in the User: namespace. Here's a list of all the people who seem to have "table.metadata" in their personal CSS (152 of them): User:Mike Dillon/.metadata users. So, if we make the change, Persondata may disappear for 152 editors who have enabled it. I didn't check if any of them had the CSS commented out. So, we might want to get a bot to leave a message on all of their talk pages. I don't think any bots have admin access to make the changes automatically. Mike Dillon 17:39, 4 December 2006 (UTC)
Per the Wikipedia:Catalogue of CSS classes description ("Used to mark metadata that should not be printed (?)," which made sense), I have been using .metadata on cleanup templates. As it makes intuitive sense for notices to be defined as "metadata", I think we should just make the class do what is least surprising -- namely, don't print.
From monobook.css:
 @media print {
    /* Do not print edit link in templates using Template:Ed
       Do not print certain classes that shouldn't appear on paper */
    .editlink, .noprint, .metadata, .dablink { display: none }
    #content { background: #FFFFFF; } /* white background on print */
 }
What I don't understand is why the above media-specific definitions aren't in common.css. -- PatrickFisher 00:24, 8 December 2006 (UTC)
I'm not sure if you missed it, but the reason may be that there is a more specific and conflicting use of this CSS involving the {{Persondata}} template. Once we've finalized cleaning up that template's use of this class, it will be fully in line with the stated use at Wikipedia:Catalogue of CSS classes. That being said, adding these changes for "@media print" would not really affect the Persondata usage since it is screen-oriented, so it may be safe to do now. Read my second message in this thread for the history of how we came to be in the current situation with this class. Mike Dillon 05:48, 8 December 2006 (UTC)

[edit] Improving template code

We should start to improve the code used in templates to conform to good authoring practices. As a "free encyclopedia", wikipedia should do more than pay lip service to accessibility, especially when improving accessibility will also improve the code, reduce the size of the code, and require very little effort to implement. —Michael Z. 2006-11-06 22:02 Z

[edit] Classes instead of id's

Disambiguation templates such as template:Disambig have <div class="notice metadata" id="disambig">. The #disambig id should be changed to a .dabnote class (changed the name to avoid confusion, and harmonize it with .dablink). There is no guarantee that only one disambig template will ever be added to a page, and HTML strictly requires id's to be unique on the page. The div tag would be <div class="notice metadata dabnote">. —Michael Z. 2006-11-06 22:02 Z

[edit] Divs instead of layout tables

Using a table to lay out template:Disambig and other disambiguation notices is contrary to WCAG's guideline no. 3: Use markup and style sheets and do so properly (checkpoint 3.3, a priority 2 checkpoint, says "Use style sheets to control layout and presentation").

This template message needs only a single div, with left padding and the image added in the background. Unfortunately, I can't enter an image into wikitext, so I can't show an example here, and this will have to be implemented as a class in the style sheet—that's the right way to do it anyway. The result will look the same in a visual browser, but avoid presenting screen readers with an un-summarized table to read or skip, and will reduced the amount of code in the page.

Common.css currently has:

#disambig {
    border-top: 1px solid #cccccc; 
    border-bottom: 1px solid #cccccc;
}

This could be changed to:

.dabnote {
    border-top: 1px solid #ccc; 
    border-bottom: 1px solid #ccc;
    padding-left: 50px;
    min-height: 50px;
    background: url(http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Disambig_gray.svg/30px-Disambig_gray.svg.png) no-repeat 10px center;
    font-style:italic;
}

Min-height isn't supported by MS Internet Exploder 6 (nor, I think, by 7), but this is just a fallback to ensure modern browsers draw the box correctly. The notices will still draw acceptably even in MSIE, as long as they contain some text.

The wikitext of the template would be greatly reduced from this:

 <div class="notice metadata" id="disambig">
 {|style="background:none"
 |style="vertical-align:middle;"|[[Image:Disambig gray.svg|30px]]
 |style="vertical-align:middle;"|''This [[Wikipedia:Disambiguation|disambiguation]] page lists articles associated with the same title. If <!-- you are viewing this online as opposed to as a [[hard copy]] and -->an [[Special:Whatlinkshere/{{NAMESPACE}}:{{PAGENAME}}|internal link]] led you here, you may wish to change the link to point directly to the intended article.''
 |}</div>

To this:

 <div class="notice metadata dabnote">
 This [[Wikipedia:Disambiguation|disambiguation]] page lists articles associated with the same title. If <!-- you are viewing this online as opposed to as a [[hard copy]] and -->an [[Special:Whatlinkshere/{{NAMESPACE}}:{{PAGENAME}}|internal link]] led you here, you may wish to change the link to point directly to the intended article.
 </div>

Output of the page will have the following code reduced from this:

 <div class="notice metadata" id="disambig">
 <table style="background:none">
 <tr>
 <td style="vertical-align:middle;"><a href="/wiki/Image:Disambig_gray.svg" class="image" title=""><img src="http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Disambig_gray.svg/30px-Disambig_gray.svg.png" alt="" width="30" height="23" longdesc="/wiki/Image:Disambig_gray.svg" /></a></td>
 <td style="vertical-align:middle;"><i>This <a href="/wiki/Wikipedia:Disambiguation" title="Wikipedia:Disambiguation">disambiguation</a> page lists articles associated with the same title. If an <a href="/wiki/Special:Whatlinkshere/Template:Disambig" title="Special:Whatlinkshere/Template:Disambig">internal link</a> led you here, you may wish to change the link to point directly to the intended article.</i></td>
 </tr>
 </table>
 </div>

down to this:

 <div class="notice metadata dabnote">
 This <a href="/wiki/Wikipedia:Disambiguation" title="Wikipedia:Disambiguation">disambiguation</a> page lists articles associated with the same title. If an <a href="/wiki/Special:Whatlinkshere/Template:Disambig" title="Special:Whatlinkshere/Template:Disambig">internal link</a> led you here, you may wish to change the link to point directly to the intended article.
 </div>

That's a reduction from 817 characters to 413. On one of the busiest sites on the Internet, even such a small reduction multiplied by billions of page views will save someone the cost of a server somewhere. There are probably many other templates which could benefit from such optimization. —Michael Z. 2006-11-06 22:02 Z

Side note: template:Disambig is currently transcluded into 70,928 pages. --Ligulem 22:46, 6 November 2006 (UTC)
Thanks. This doesn't mean much, but to give an idea of the magnitude, if each of those pages were transmitted only once, then this change would save 27.33 MB of transfer. Anyway, the important principle is to always reduce code where there are only positive side-effects.
(That also means we should get this right the first time, and not revert-war over changes to the template :-))
(Q1) How do you count the transclusions without paging through 142 "what links here" listings? (Q2) Does that include the template's redirected synonyms, like template:Disambiguation? —Michael Z. 2006-11-06 23:01 Z
(A1) I've used m:MWB to build the list. (A2) No. So there are even more... --Ligulem 23:39, 6 November 2006 (UTC)
Yay for replacing table layouts! — Omegatron 23:51, 6 November 2006 (UTC)

Update: I changed the class name to dabnote, avoiding confusion with the id name, as well as harmonizing with .dablink and saving another byte. —Michael Z. 2006-11-07 00:06 Z

Looks good to me. Making the site more accessible to all users, not just traditional browser users, is always a good thing. EVula 05:26, 7 November 2006 (UTC)

A couple of issues:

  1. The text is no longer vertically centered . . . because it's impossible to vertically center anything in CSS 2.1 except for table cells. That's not noticeable here unless you turn down font size a lot, at least not on my browser, but I note this because it's an issue for things like copyright templates.
  2. While Template:Disambig is already protected, using this treatment for most other templates would mean a sysop would need to change the background image, and a normal user couldn't.
  3. Using background-image means that the image's location won't be immediately obvious, since it's not clickable, and so it will be more confusing to change. That's why the software deliberately does not support easy use of unclickable images.
  4. Tables are so ubiquitous as layout elements that I strongly suspect that no user agent actually assigns them semantic value (unlike pretty much every other semantic tag). I would welcome counterexamples, but until you come up with one this looks like a solution in search of a problem.
  5. You could pare down the table markup as follows: 
    <table class="notice metadata dabnote">
 <tr>
 <td><a href="/wiki/Image:Disambig_gray.svg" class="image" title=""><img src="http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Disambig_gray.svg/30px-Disambig_gray.svg.png" alt="" width="30" height="23" longdesc="/wiki/Image:Disambig_gray.svg" /></a></td>
 <td>This <a href="/wiki/Wikipedia:Disambiguation" title="Wikipedia:Disambiguation">disambiguation</a> page lists articles associated with the same title. If an <a href="/wiki/Special:Whatlinkshere/Template:Disambig" title="Special:Whatlinkshere/Template:Disambig">internal link</a> led you here, you may wish to change the link to point directly to the intended article.</td>
 </tr>
 </table>
    That's 703 bytes, just over a third of your reduction. Byte count is not, of course, a major issue, at least not on the scale of a couple hundred bytes a page.

Web standards are not always the best choice. They just generally are. When they confer no benefit whatsoever, there's no point in sacrificing ease of use or even prettiness for their sake. By all means move inline style to classes, and change the id to a class, but don't move the image to CSS or change the table to a div. —Simetrical (talk • contribs) 21:41, 3 December 2006 (UTC)

On second thought, this might be an okay choice for moving to div, but still don't move the image to CSS. —Simetrical (talk • contribs) 05:51, 7 December 2006 (UTC)
I'm pretty sure the image clicking thing has more to do with providing one-click access to the image details to comply with the GFDL. Mike Dillon 22:57, 3 December 2006 (UTC)

By the way, if you can't figure out how to get an element to behave as well as the table did, you can always just use display:table and make it behave like one. — Omegatron 00:30, 4 December 2006 (UTC)

Except that IE6 doesn't support display: table;. —Simetrical (talk • contribs) 05:51, 7 December 2006 (UTC)
And really, how many people really use IE? Only perhaps 80% of the population... EVula // talk // ☯ // 05:58, 7 December 2006 (UTC)

[edit] Other templates

What other templates need this treatment? (apart from {{disambig}} and its variations) —Michael Z. 2006-11-06 23:54 Z

[edit] Messagebox tables require inline styles

Many cleanup templates use the messagebox style and a table to align images. This table must have the attribute style="width:100%;background:none" to behave as expected. Can we add the following to common.css?

.messagebox table {
  width:100%;
  background:none;
}

Which would eliminate that inline styling. -- PatrickFisher 00:38, 8 December 2006 (UTC)

[edit] Rollback

Why have all rollback links suddenly made boldface? (Radiant) 21:37, 18 November 2006 (UTC)

Yup. Looks ugly in bold. --Ligulem 00:05, 19 November 2006 (UTC)
Undone for now (because I don't see any discussion on the subject and I do see dissent here). (Radiant) 14:36, 20 November 2006 (UTC)
They used to be bold when viewing diffs, but not when viewing a user's contribs. (This was before they existed on page histories) – Gurch 12:25, 23 November 2006 (UTC)

[edit] CSS error

FireFox's error console reports the following CSS error on every page:

Warning: Unknown property 'column-count'.  Declaration dropped.
Source file: http://en.wikipedia.org/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=2678400
Line: 33

An error, cross-browser compatibility issue, or typo? haz (talk) e 20:23, 6 December 2006 (UTC)

This has been discussed at MediaWiki talk:Common.css/Archive 2#references-2column class breaks Firefox and MediaWiki talk:Common.css/Archive 3#Minor non-compat bug. I believe it was left as is as a "harmless" compatibility issue. Mike Dillon 21:35, 6 December 2006 (UTC)

[edit] Consistent styling for edit-page messages

It is requested that an edit or modification be made to the protected page.
Please remove this template after the request is fulfilled.

There's some inconsistency in edit-screen messages at the moment; it was suggested on MediaWiki talk:Talkpagetext that there should be a CSS class that can be used for consistent styling. I'd like the following to be added to common.css (originally taken from MediaWiki:Longpagewarning:

.editscreenmsg {margin: 0 0 1em; padding: .5em 1em; vertical-align: middle; border: solid #aaaaaa 1px}

(It could be argued that this should go in monobook.css, as it's an interface message, but placing it in common.css is the least change to the current situation.) It would be nice if MediaWiki:Talkpagetext, MediaWiki:Longpagewarning, and MediaWiki:Newarticletext were all updated to use the new class (resulting in no visible changes to the first two, and only a slight change to the third), but I'll put up {{editprotected}} messages after the class is added if necessary. --ais523 09:16, 7 December 2006 (UTC)

Isn't this what .standard-talk is for? —Simetrical (talk • contribs) 02:31, 8 December 2006 (UTC)
standard-talk is for divs/tables placed at the top of a talk page. This is for divs/tables added by the software above the edit box when editing a page, and looks quite different. --ais523 14:56, 12 December 2006 (UTC)
Retrieved from "http://en.wikipedia.org../../../c/o/m/MediaWiki_talk%7ECommon.css_e2a2.html"