MediaWiki talk:Common.css

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

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.

.IPA class

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

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

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

-- Lukas Vacek

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

-- Lukas Vacek

Template documentation styles

{{editprotected}}

The green template documentation boxes are created by Template:Template doc inline. It has its styles hardcoded, but also has the currently unused class "template-documentation" in its header. So I suggest moving its styles into common.css so the template docs can be skinned.

Please add:

/* For template documentation */
.template-documentation {
  clear: both;
  margin: 25px 0 0 0;
  border: 1px solid #aaa; 
  background-color: #ecfcf4; 
  padding: 5px;
}

I took the liberty of adding a proper margin on top so templates and their docs won't come to close. Later on I will change the template so it only uses this class and no hardcoded styles. (Note, never use that template directly, instead see Wikipedia:Template documentation.)

--David Göthberg 08:54, 18 September 2007 (UTC)

 Done - I added the code as is to the bottom of the sheet, it looks fine. Nihiltres^(t.l) 14:41, 18 September 2007 (UTC)

Thanks. Only question now is how long to wait. Since we just learnt the hard way with the .ambox classes that Wikipedia has set CSS caching to a month or so and that some browsers seem to honour that! Perhaps we should request a lowering of the default caching to 1 week?

--David Göthberg 15:02, 18 September 2007 (UTC)

{{editprotected}}

The 25px margin-top seems excessive. I propose decreasing it to 1em, as I've done to {{Documentation}} in this change, to make the transclusions at for example WP:SONG#Infobox flow better. A 1em margin-top combined with the box should be enough to keep the doc separate from the preceding content. --PEJL 19:43, 19 October 2007 (UTC)

Y Done - quite reasonable. :) Nihiltres^(t.l) 20:38, 19 October 2007 (UTC)

Thanks. (I've restored the change to {{Documentation}}, because of the caching issue noted above. I guess it can be removed one month from now.) --PEJL 22:29, 19 October 2007 (UTC)

Problem with floating wikitables

Continued from Help talk:Table#Problem_with_floating_wikitables. Shinobu 11:54, 22 September 2007 (UTC)

Sometimes one might want to float a wikitable. Currently, when you simply add style="float:left" or style="float:right" to the wikitable this yields an ugly effect. A screenshot serves to illustrate this effect. It contains four tables. The first two are floating right and left using only style="float:left"; the ugly effect clearly shows. The next two tables demonstrate how the tables should look; this was faked using extra inline CSS. Screenshot.

The effect is sufficiently ugly that wikitables cannot be floating without using inline CSS, which is a bad solution. It is my opinion that either the wikitable CSS class should be better behaved when style="float:left" or style="float:right" is added (if this is at all possible) or two extra CSS classes should be defined, for tables that float left or right.

As a closing remark, I would like to note that this effect appears in all browsers I have: Safari, Konqueror, IE and Firefox, regardless of fontsize, and window width. The screenshot was taken from Safari, but differences from what is seen in other browsers are only noticable on the pixel-level, i.e. they are very small indeed, at least on my computer. Shinobu 11:54, 22 September 2007 (UTC)

It's because the padding/margins assume block layout. "right" and "left" classes like for thumbnails are needed. —Simetrical (talk • contribs) 18:30, 7 October 2007 (UTC)

So... any objections to adding the following?

table.wikitable.left,
table.prettytable.left {
    float: left;
    clear: left;
    position: relative;
    margin: 0 .5em .5em 0;
}
table.wikitable.right,
table.prettytable.right {
    float: right;
    clear: right;
    position: relative;
    margin: 0 0 .5em .5em;
}

(Markup based on the "floatleft" and "floatright" classes in monobook/main.css that are used for thumbnails. We could almost use them as is, but they seem to come with some annoying extra rules that italicize text in paragraphs and such.) —Ilmari Karonen (talk) 18:59, 7 November 2007 (UTC)

• Could you please explain the purpose of position: relative; here?
• Why limit the new classes to wikitable and prettytable only?

∴ AlexSm 21:00, 7 November 2007 (UTC)

The only effect the "position: relative" appears to have is to establish a containing block for any absolutely positioned elements.[1] I'm not sure it's needed; it's been part of the "floatleft"/"floatright" classes since forever (I've only been able to trace it back to rev:2909), but it might be obsolete or it might have some purpose specific to image thumbnails. As for making the declarations apply only to "wikitable"/"prettytable", the idea would be that we can later add similar declarations for other classes without having to worry about conflicts. I'm assuming that there are currently no CSS rules applying to the classes "left" and "right" by themselves; if we were to make these declarations non-"wikitable"-specific, we'd have to be damn sure that those class names aren't used anywhere else at all. —Ilmari Karonen (talk) 22:42, 7 November 2007 (UTC)

font change

{{editprotected}}

Please change:

:lang(grc) {
       font-family: Athena, Gentium, "Palatino Linotype", "Arial Unicode MS", "Lucida Sans Unicode", "Lucida Grande", Code2000;

to

:lang(grc) {
       font-family: "Athena Unicode", Gentium, "Palatino Linotype", "Arial Unicode MS", "Lucida Sans Unicode", "Lucida Grande", Code2000;

The original Athena Roman font is no longer available. The current version of Athena Unicode gives "Athena Unicode" for its font family and not "Athena", and so is not detected.

Apparently Athena Roman can still be found, but there are reports that it doesn't play well with modern software. [2]. TCC (talk) (contribs) 02:23, 17 October 2007 (UTC)

It also might be worth changing the equivalent line for .polytonic, although to my knowledge this is no longer in use. TCC (talk) (contribs) 02:25, 17 October 2007 (UTC)

 Done. — Edokter • Talk • 14:57, 17 October 2007 (UTC)

CS3 ?

table.navbox tr:not(:first-child) th {
    background-color: #ddf;
}

This rule is here for Template:Navbox generic. Look at the two included examples on Template:Navbox_generic#Layout_of_table: in Firefox the rule works and the backgrounds under {group1} and {title} are different. Not so in IE and Opera (see Comparison of layout engines (CSS)). I really doubt CSS3 should be used in Common.css. Either not() should be removed (making the rule work in Opera and IE7, but not in IE6) or, even better, the whole rule should be removed and {{Navbox generic}} should be modified like {{Navbox}} which specifies inline styles for all rows and thus doesn't need any advanced CSS at all ∴ AlexSm 18:26, 17 October 2007 (UTC)

I think the background should not be defined inline. Instead, I think defining a sererate #id for the row headers would be more appropriate. — Edokter • Talk • 18:40, 17 October 2007 (UTC)

Actually, since {{Navbox generic}} has been deprecated in favor of {{Navbox}} (and thus shouldn't be (but not necessarily isn't being) used for any navigation boxes), this isn't terribly important. I'll put in an editrequest on Navbox generic anyways, though (unless someone beat me to the punch). --Dinoguy1000 ^Talk 04:58, 18 October 2007 (UTC)

I'll remove it; I have updated {{navbox generic}} with the default colors, so this rule isn't needed anymore. — Edokter • Talk • 11:57, 18 October 2007 (UTC)

What is the point of removing code that only rendered extra information to those using a browser better supporting CSS. Using style inline is a dirty solution and should be avoided whenever possible as it uses more bytes than if it set in the style sheets. Additionally it prevents users from accessing those elements using their monobook.css page. It wanted to support those users you always remove the negate function and swap the two colors around. —Dispenser 21:57, 5 November 2007 (UTC)

Agreed; unless the CSS3 code renders improperly in browsers that don't support it, there's no reason to not have the code. EVula // talk // ☯ // 22:25, 5 November 2007 (UTC)

In this particular case the code was only used for deprecated template and only good for Firefox but not for IE and Opera. I think that was a good enough reason to remove it. You're welcome to suggest :first-child (without :not) at {{Navbox}} talk page; don't forget to mention that this won't work in IE6. P.S. The statement about user's monobook.css is false: just use !important ∴ AlexSm 00:02, 6 November 2007 (UTC)

If the same can be done without CSS3, it should be done that way (using an extra class or id). There's absolutely no reason to use CSS3 if it can be avoided. — Edokter • Talk • 00:17, 6 November 2007 (UTC)

What about all the navboxen that don't use the template but are just plain tables with the navbox class? —Ruud 00:49, 6 November 2007 (UTC)

The CSS3 capable browsers loose their first TH color, for other browsers it stays the same (which didn't show the right color anyway). — Edokter • Talk • 01:02, 6 November 2007 (UTC)

Fundraising sitenotice

See also Wikipedia:Fundraising redesign —Preceding unsigned comment added by Squee23 (talk • contribs) 11:31, 23 October 2007 (UTC)

Template:RFCstyle I am getting really annoyed with the site notice now, and it looks like I am not the only one who hates it. What does everyone think about getting these disabled? Bushcarrot ^Talk _{Please Sign!} ^{Let's go Lightning!} 00:52, 23 October 2007 (UTC)

Kill it with fire. android79 00:59, 23 October 2007 (UTC)

Nuke it. Banner ads give me a headache. *Clarification: Fundraising is necessary, and a simple banner like the Wikimania banners would be fine. But this is way too much. I would support a better-designed one. Neranei (talk) 01:07, 23 October 2007 (UTC)

(3x EC) What happened a single line of text that could be hidden? Terminate with extreme prejudice. Oh, and you can hide it by adding .fundraiser-box{display:none;} to your monobook.css. east.718 at 01:10, 10/23/2007

Or, even better, marquee { -moz-binding: none } or marquee { display: none }, which only disables the scrolling. --cesarb 01:21, 23 October 2007 (UTC)

I know fundraising is necessary, and would tolerate a well-designed banner (which lost the eye-straining jerky scroll and actually identified itself as part of the semi-annual Fundraiser), but I agree that what has been presented here is not appropriate for a message displayed to all site visitors. It should be removed/replaced. Dragons flight 01:14, 23 October 2007 (UTC)

Replaced, not removed. It should be cut down, and have the option to hide, so it's not so intrusive. --86.29.37.121 01:17, 23 October 2007 (UTC)

For the record, I said "removed" in the sense that we shouldn't necessarily wait for a replacement to be created before removing it. If a replacement is made soon, then okay, if not, I would still encourage it to be removed for now. Dragons flight 01:22, 23 October 2007 (UTC)

I agree that a banner at all is okay, as long as it's not ghastly like this. Until there's a better one, I support the removal. i ^said 01:21, 23 October 2007 (UTC)

Please remove it, even with the "dismiss" it pops up from time to time, it's very distracting. DuncanHill 01:24, 23 October 2007 (UTC)

As hopefully all sysops who read this realize anyway, the banner was placed there by an employee of the Wikimedia Foundation acting, presumably, in his official capacity. Consensus isn't going to overrule the Foundation if it wants it to stay. Whether anyone removing it will get summarily desysopped I don't know, but it would hardly be unprecedented.

That said, yeah, it sucks. Thanks to whoever added the dismiss thing (which Brion said was fine, after the fact). —Simetrical (talk • contribs) 01:25, 23 October 2007 (UTC)

I am seeing no "dismiss" option. There should be one - if one cannot be added, the entire thing should be removed until it can be rewritten in such a way that it can be dismissed. I do not see why as someone who has donated I should have to be subjected to this annoying and distracting notice. It's worse than adspam. And I am not going to edit my monobook.css, because whatever is done should be done for all users, not merely those with superior technical skills. Orderinchaos 13:24, 23 October 2007 (UTC)

Try bypassing your cache; one was added recently. --ais523 16:09, 23 October 2007 (UTC)

Incorrect - a "Show more/Hide this message" was added recently. Bypassing my cache on three occasions in 12 hours has failed to rectify the problem. Orderinchaos 23:13, 23 October 2007 (UTC)

It looks like a true dismiss was added and then removed again. --ais523 11:53, 24 October 2007 (UTC)

IIRC, it was removed once a hard-coded dismiss button was added. --Dinoguy1000 ^Talk 18:09, 26 October 2007 (UTC)

I agree with that statement, however the notice has been altered; it is less "insane" and has addressed many concerns. Cbrown1023 talk 01:30, 23 October 2007 (UTC)

Bugger the Foundation. Some things are worth getting de-sysopped for. --Carnildo 01:31, 23 October 2007 (UTC)

(e/c)Delete. No prejudice against creating a replacement banner that does not scroll, with an option to close built in. Going back to the original format is better. Also, on another area of discussion a visually impaired user said that ad messed with their interface, so it's more than just an annoyance. ~Eliz81^(C) 01:28, 23 October 2007 (UTC)

{{sudo}}

I've filed a bugzilla request to have the <marquee> removed. Until such time as that is done, please add:

div#siteNotice {display:none}

to this page. Once it's removed, the notice can be put back. Thanks – Gurch 01:48, 23 October 2007 (UTC)

 Not done no longer scrolls and if you want this done, contact the staff. Cbrown1023 talk 01:53, 23 October 2007 (UTC)

The scrolling notice in one window eats 54% of the CPU in one of my browsers; makes it difficult to use more than one window in Wikipedia, or do anything else while Wikipedia is up. We already went through this mess on Wikinews. (SEWilco 02:02, 23 October 2007 (UTC))

The scrolling is also interfering with the goal of writing the encyclopedia. On my fast machine the scrolling interferes enough with the edit window that positioning or multiple backspacing become jerky and unpredictable. (SEWilco 02:02, 23 October 2007 (UTC))

And on my not-so-fast machine, most images have been stalling out ever since the banner appeared. This is not a good solution. —Josiah Rowe (talk • contribs) 03:18, 23 October 2007 (UTC)

Sorry, it's OK at the moment (after I quit my browser and restarted it, the images are loading fine). Ignore the above. —Josiah Rowe (talk • contribs) 03:38, 23 October 2007 (UTC)

sofixit

Would people be willing to help to sofixit? discussion on admin's noticeboard --Kim Bruning 02:39, 23 October 2007 (UTC)

Actually, I've made a seperate page for this now, Wikipedia:Fundraising redesign. Dragons flight 05:12, 23 October 2007 (UTC)

And I've already thrown a heap of stuff on there. :-) --Kim Bruning 05:32, 23 October 2007 (UTC)

Unnecessary class

Keeping Common.css as bloated as possible? What's wrong with inline CSS or using several classes on one element? ∴ AlexSm 15:52, 7 November 2007 (UTC)

Where is this class even used? --Dinoguy1000 ^Talk 17:15, 7 November 2007 (UTC)

Apparently, only in {{InChI}}. — Edokter • Talk • 17:21, 7 November 2007 (UTC)

Heh, I saw that before I posted. I've really got to learn to search before I speak... ^_^;; --Dinoguy1000 ^Talk 17:37, 7 November 2007 (UTC)

In any case, it probably shouldn't be in Common.css. I asked Physchim62 why he put it in. — Edokter • Talk • 18:29, 7 November 2007 (UTC)

The class marks off an item of metadata which most human readers neither wish not need to know, but which is essential for the automagical indexing of chemical compounds. The principal is the same as for Persondata, but the metadata are different, hence the new class. The objective is to allow searching of Wikipedia by chemical structure. Physchim62 (talk) 18:54, 7 November 2007 (UTC)

Then perhaps the class should have been simple metadata { display: none; speak: none } from the start? Right now it can be at least merged with persondata class above ∴ AlexSm 21:00, 7 November 2007 (UTC)

It can hardly be merged without breaking persondata, as far as I can see, which is why I created a separate class with a separate name. Physchim62 (talk) 21:08, 7 November 2007 (UTC)

Why is that? Search engine don't actually look at the class name, do they? All it does is control the display. For .persondata it's too late to change it's name since it is being used to much, but it's not too late to create .metadata for InChI and possible future metadata templates. I'll implement it now, and I would urge to convert InChI to use .metadata instead. — Edokter • Talk • 21:49, 7 November 2007 (UTC)

Let's not use "metadata" for this; we have a bazillion templates with class="boilerplate metadata" floating around. —Ilmari Karonen (talk) 22:08, 7 November 2007 (UTC)

Oops... Any other suggestions? — Edokter • Talk • 22:15, 7 November 2007 (UTC)

Yes, I suggest we accept the current situation, which has a perfectly good rationale behind it. If you wish to deal with metadata in a more "rational" sense, we can always have a longer discussion in a forum which receives more traffic. Physchim62 (talk) 12:30, 8 November 2007 (UTC)

Leaving it as it is isn't good enough. This is the most appropriate forum, beside the Village Pump maybe, but this is more of an administrative issue then it is a technical one. We can't have Common.css fill up with seperate, yet identical metaclasses that are only used in one template. So we need to come up with a classname that serves any future metaclasses. — Edokter • Talk • 13:16, 8 November 2007 (UTC)

Leaving it as it is is perfectly good enough, you yourself are not the personal guardian on Common.css. I shall place posts on VPP and VPT this afternoon. Physchim62 (talk) 13:20, 8 November 2007 (UTC)

Actually, I do regard myself as one (of many) guardians if this and other system files, and there is nothing wrong with that; this page is loaded with every pageload, therefor each addition must be discussed beforehand. There is nothing "pretentious" about it. I'm actually more inclided now to just remove the class, as you seem to misunderstand that Common.css is not to be used for adding low-use classes, which are better served in-line. We add them when they become high-use. We just had a major cleanup, and I for one like to prevent another one. — Edokter • Talk • 13:52, 8 November 2007 (UTC)

Your time (and the servers') would be better used in discussion of the relevant points. Physchim62 (talk) 17:10, 8 November 2007 (UTC)

Sorry? What are the relevant points then? Your rational that "the metadata is different" doesn't hold; you could easily have used persondata and it would have worked fine. Or at least you could have put the name in the same class (as I did) instead of ceating an entirely new, duplicate class. I will repeat though that Common.css must be as small as possible, that is something you cannot dismiss. Now, please come up with a new, generic, metadata class name and use that one instead. Because .InChI isn't going to be around much longer. — Edokter • Talk • 17:43, 8 November 2007 (UTC)