MediaWiki talk:Common.css

• MediaWiki
• Meta
• Commons
• Wikibooks
• Wikiquote
• Wikisource
• Wiktionary
• de
• fr
• pl
• ja
• jbo
• it
• nl
• es

ca-delete !important

Why is the #ca-delete rule marked as !important? This is not necessary, as far as I can see. --- RockMFR 23:22, 13 August 2009 (UTC)

Printing out dates of old article versions: needed back

If I print out an article from its history, the pink banner which is visible on screen ("This is an old version of the page, as edited by xxx on xxx etc etc") does not print out (I've tried several pages). I'm sure it used to. Is this a deliberate change? If so, why? I found the printed banner just as useful as the one on screen.

Thanks for any info and help

89.48.77.8 (talk) 05:53, 19 August 2009 (UTC)

Shows up on "Printable Version" for me, and I don't see any recent edits to MediaWiki:Revision-info, MediaWiki:Revision-info-current, or MediaWiki:Print.css that would cause it. Odd. --Splarka (rant) 07:38, 19 August 2009 (UTC)

Oops, it is hidden. It is because of #contentSub ... {display: none;} on MediaWiki:Print.css added here. --Splarka (rant) 07:49, 19 August 2009 (UTC)

It is pertinent to have the date printed, back, I mean printed on the bottom of the printable version. This serves a minimum of "priority date" (publication date) e.g. for legal purposes where users like offical organisations save a printed or PDF-printed version in their repositories as prior art. Please can the persons in charge of this restore the #contentSub value for print.css so that the date is printed ? --Wikinaut (talk) 09:14, 20 August 2009 (UTC)

I have presented a solution at your original post on the Village Pump. ---— Gadget850 (Ed) ^talk 09:57, 20 August 2009 (UTC)

I've removed the relevant code from Print.css until we get a better solution. It's better to show stuff that we want hidden rather than to hide stuff that we do want shown (in my opinion). — RockMFR 21:09, 23 August 2009 (UTC)

Free pdf readers

Adobe icon is not free, AFAIK, and to use it make people feel that only Adobe proprietary software can be used to open PDF files, and that's fra from truth: see PDFreaders FSFE initiative. Maybe we could use this graphics (e.g. the last one), instead. --Nemo 17:41, 28 August 2009 (UTC)

We could, but I don't think we should. The icon is supposed to ADD information, a green unfamiliar icon will just confuse people. I vote we remove the pdf icon and replace it with a generic document icon. —TheDJ (talk • contribs) 18:01, 28 August 2009 (UTC)

I guess TheDJ is right, a new icon will only confuse readers. I agree with his proposal. --Locos epraix ~ Beastepraix 18:21, 28 August 2009 (UTC)

bugzilla:20428 —TheDJ (talk • contribs) 18:22, 28 August 2009 (UTC)

The icon does add information, since there's a clear "PDF" writing and a link to a place where you can download a free pdf reader (current icon doesn't do so). Or, we could use another icon (e.g. the one suggested by tpascal), and still link to that website. --Nemo 18:51, 28 August 2009 (UTC)

At 14px, the PDF is illegible. like on the current icon, but at least that is an icon that everyone recognizes. And we can't use the image to link anywhere, because it is pure CSS. —TheDJ (talk • contribs) 19:30, 28 August 2009 (UTC)

Why do we need a bugzilla case on this? The PDF icon is on Commons at File:Icons-mini-file acrobat.gif and is sourced from FamFamFam. If the image is really not free, then we upload a free image over top of the old. ---— Gadget850 (Ed) ^talk 20:51, 28 August 2009 (UTC)

Yes, that is the image. However, the image automatically applied to PDF links by mediawiki is hard coded into the software and changes to a file on commons won't affect it. Ale_Jrb^talk 21:04, 28 August 2009 (UTC)

Also note that it doesn't matter who made that actual icon, it contains the Adobe reader logo, which obviously has (many) rights reserved . Ale_Jrb^talk 21:08, 28 August 2009 (UTC)

I guess I'm missing something, as it appears to me the image is linked in the CSS as "http://upload.wikimedia.org/wikipedia/commons/2/23/Icons-mini-file_acrobat.gif". If the image is non-free, then it should not be on Commons. If I am right about the location, then the simplest solution is to find a free image an upload over the non-free version, thus updating every use. ---— Gadget850 (Ed) ^talk 22:03, 28 August 2009 (UTC)

I've nominated the image for deletion. If the image is deleted, we could possibly use File:Icon pdf.gif. — RockMFR 23:09, 28 August 2009 (UTC)

Standard background colors

Many tables on Wikipedia contain repetitive, scalar kinds of information. Some people made templates for this task such as {{yes}} which usually transclude a cell background color and a default text. These are widely used as far as I can see. I’d like to pose the question whether the colors and sets shouldn’t be standardized more and then moved to MediaWiki:Common.css as much as possible. Please see the collective Talk page. — Christoph Päper 13:07, 15 September 2009 (UTC)

Remove mw-plusminus-pos

Please remove the following per rev:53289, now live in shared.css. — AlexSm 04:17, 18 September 2009 (UTC)

/* Coloured watchlist numbers */
.mw-plusminus-pos { color: #006400; } /* dark green */
.mw-plusminus-neg { color: #8B0000; } /* dark red */

Done by RockMFR. Locos epraix ~ Beastepraix 15:43, 19 September 2009 (UTC)

Add class for style examples

Could you please add .example { font-family: 'Georgia', serif; color: #006F00; }? The class example is used by {{xt}} which uses it for examples of styles, like this. (It is widely used on WP:MOS and some of its sub-pages.) Now the styling is specified in the template itself, but moving it here would save a few bytes each time the template is used, and would allow users to customize its style. (There is also {{!xt}} using the class bad_example and the style font-family: Georgia, serif; color: #B20000; like this, but it is an experimental template which isn't used yet.) --___A. di M. 21:15, 12 October 2009 (UTC)

See Wikipedia talk:Manual of Style#Green text. ___A. di M. 21:17, 12 October 2009 (UTC)

No need for sitewide CSS. Add the class to the template, and users can customise it using the !important keyword. Yes, it would save a few bytes on WP:MOS, but by adding the same bytes to the other 62,208,028 pages. Happy‑melon 21:49, 12 October 2009 (UTC)

Here are the detailed instructions how to use the !important keyword: Wikipedia:Catalogue of CSS classes#CSS caching is !important

--David Göthberg (talk) 13:11, 23 October 2009 (UTC)

Teletype style fix for Chrome

User Rd232 brought to my attention that teletype wikimarkup looks bad in Google Chrome. After some testing we deviced a solution that will make teletype look the same in Chrome as in all other browsers. Thus I intend to add this code to MediaWiki:Common.css:

/* Fix so <tt></tt> tags look the same in Google Chrome. */
tt {
    font-family: monospace, sans-serif;
}

The code is also parsed by all other browsers, but they already render teletype exactly like that, so it causes no visible change in them.

For the discussion and for our test examples that led to this solution, see Template talk:Nicecode. (We intend to delete that template once this fix has been added to MediaWiki:Common.css, thus that link will soon become red.) If no one sees a problem with this fix I will deploy it some day from now.

--David Göthberg (talk) 18:16, 23 October 2009 (UTC)

Just a note that this also affects code text,

pre text, and

/* source text */

There's a bug report on it somewhere IIRC. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:21, 23 October 2009 (UTC)

What exactly is the problem? Are you sure it will look exactly the same on all other browsers? Does this warrant a bug report for Chromium? —Simetrical (talk • contribs) 21:24, 23 October 2009 (UTC)

Simetrical: As I kind of stated above: See Template talk:Nicecode for the details. I didn't want to fill this page with a copy of that discussion.

And yes, it looks exactly the same on all browsers we have tested it on so far, except for in Google Chrome where it fixes the problem. And that CSS code is clear and simple. And for instance the CSS 4 standard has an informative section showing that the default look for the tt tag is "font-family: monospace". What we added is "sans-serif" which is the standard way to specify non-serif font, so should not cause any problems in any browser.

Dinoguy1000: I think I can fix it just as easily for <code>...</code> and <pre>...</pre>. I tested it in the three browsers I have: Firefox 2.0, Opera 9.02 and IE 5.5, and it didn't change their styles there. But I can't run Chrome on my OS so I can not see if it fixes the problem there. If you have Chrome, try adding the code below to your personal /monobook.css, then wait one minute for the servers to update, then bypass your browser cache.

/* Fix so <pre>, <code> and <tt> tags get normal text size 
   also in Safari, Konqueror and Chrome. */
pre, code, tt {
    font-family: monospace, sans-serif;
    t_font-family: times;
}

Note: I added the "t_" in front of the second line to remark it away. That's a quick and dirty way to remark away lines that I use in testing. Unremark the second line to test if your browser loads the code. (The second line will make it look ugly on purpose.)

So, does this fix the pre and code tags in Chrome?

I took a look, and it seems we can fix it for the <source>...</source> tags too, but that is much trickier.

--David Göthberg (talk) 02:26, 24 October 2009 (UTC)

Oh dear. I just checked how tt, pre, code and source tags look in lots of browsers, by using the nifty browsershots.org. The problem also affects Safari and Konqueror. Not surprising since they too use the KHTML/WebKit rendering engine. And just as Rd232 told me, the problem is that those tags cause extremely tiny text in those browsers. It looks really bad.

I didn't test in browsershots.org if our fix works, since I can't make browsershots load special CSS code. But I verified that those styles hardcoded into a span tag looked right in those browsers, so I am pretty confident. And I trust Rd232's word that it works, and I know it doesn't damage the looks in the browsers I have.

Could any Safari and/or Konqueror users confirm that the fix works. please?

--David Göthberg (talk) 03:07, 24 October 2009 (UTC)