MediaWiki talk:Common.css

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

iPhone compatibility

Moved from WP:VPT Happy‑melon 20:09, 14 December 2008 (UTC)

I started a discussion at Talk:Main Page and was redirected here. I have a proposal to add a line of code to Wikipedia (and potentially the entirety of the Wikimedia Foundation) that better enable compatibility with the iPhone (and I guess anything else running Mobile Safari - though I'm not aware of any). Though Wikipedia on iPhones is a small market, the code doesn't hinder any accessibility with other platforms, so there's no harm done to anything else - only benefits for iPhone users. When viewing the Main Page (and some other articles) on an iPhone, the left column's text(TFA, DYK) is much larger than the right column's text(ITN, OTD); this causes massive whitespace under OTD that looks ugly. Also, the licensing information at the bottom of the page, the tabs across the top ("edit this page," "watch," etc.), and user links ("Username," "my watchlist," etc.) in the top right corner of the page are oversized. Apple proposes a fix for this by modifying the "-webkit-text-size-adjust" parameter in the body tag's CSS of the page, suggesting "-webkit-text-size-adjust:none". Well, this method works for the iPhone but prohibits zooming in and out on Safari (and Google Chrome, as well as any other webkit browsers). After experimentation on User:Dudemanfellabra/Sandbox2, I've found that changing "none" to "100%" ("-webkit-text-size-adjust:100%") fixes the problem. Zooming in and out in Safari/Chrome works, and the iPhone displays the page correctly. I've tested the code firsthand on Windows (Google Chrome, FF2/3, MSIE 6/7/8, Opera 8/9) and Mac OS X (Camino, FF2/3, Opera 9, Safari 3.2); the site appears the exact same on desktop browsers with the code added, and the zoom function still works, and the iPhone works better. Also, if it helps, through Browsershots.org, I've tested it on several Linux/BSD browsers just for safe measure. All other browsers seem to work fine with the code, so I propose adding "-webkit-text-size-adjust:100%" to Wikipedia's body CSS. --Dudemanfellabra (talk) 19:59, 14 December 2008 (UTC)

If you want this Wikimedia-wide, your best bet is to try to get it into the core software via Bugzilla request. Probably skins/monobook/main.css if it is mostly for Monobook (or skins/common/shared.css for all skins). However, this will cause it to fail validation. However², the head Wikimedia/MediaWiki dev Brion VIBBER is a total iPhone fan boy, so he may go for it. Note that this'd be perfect for media="handheld", if the iPhone bothered to 'grok' it. --Splarka (rant) 08:37, 15 December 2008 (UTC)

This went to bugzilla:16654; in my testing, the change makes article pages much harder to read (illegibile in portrait mode), so probably isn't the way to go for now. --brion (talk) 19:00, 18 December 2008 (UTC)

multi-columns

.references-2column must surely be redundant to div.columns-2, no? I'm sure with a bit of co-ordination we can use these to consolidate both the somewhat messy contents of {{reflist}} and these two definitions here. Happy‑melon 23:28, 21 December 2008 (UTC)

AFAIK, references-2column is an old method of creating a 2-column reference list that is still in use in some articles; it could probably be replaced with reflist, but someone (probably working from a DB dump, or maybe the toolserver) would have to actually do it. All the classes in {{reflist}} are there to support user overriding of the behavior after many complaints at Template talk:reflist (some people just can't stand multiple columns for some reason), as far as I know they aren't actually defined in any of the global CSS files at this time. Anomie⚔ 03:04, 22 December 2008 (UTC)

Not really. .references-2column lets the browser balance the two columns, while .columns-2 requires that the user picks the breaking point—and that doesn't always work out right. —Ms2ger (talk) 15:24, 22 December 2008 (UTC)

captions are off-center

This style sheet currently contains;

.infobox caption {
    font-size: larger;
    margin-left: inherit;
}

caption

header	header	header
data	data	data

caption

header	header	header
data	data	data

and I believe that the margin-left: inherit; should be removed. The value inherited is currently 1em, from a few lines above this rule. It may have once had some value, but it is currently only serving to push captions off-center to the right; see top example, at right. In the second example, I've included an explicit style="margin-left: auto;" for the caption element to undo the issue.

Am I missing something? This has wide effect and I suspect that it has discouraged the use of captions in favor of headings, which is unfortunate from a semantic perspective; tables should have captions.

There is a similar rule;

.wikitable caption,
.prettytable caption {
    margin-left: inherit;
    margin-right: inherit;
    font-weight: bold;
}

caption

header	header	header
data	data	data

caption

header	header	header
data	data	data

and I believe the two margin inherits should also be removed here.

I've included an explicit style="margin-right: auto;" in the second table at right to undo the problem. In this example, the first caption is a bit off to the left. The correct fix is to remove these lines, not to use 'auto' (and '0' can really hose old Firefox).

Also, the other remaining bits are rather dubious as they are pretty much the default anyway. nevermind

There is also the issue that this code is extant on hundreds of wikis and if there is consensus to change it here, the change should be propagated all over the place.

fyi, I'm using Firefox 3.0.5 and see this issue in the other modern browsers, too.

Comments?

Cheers, Jack Merridew 08:34, 23 December 2008 (UTC)

These rules were added back in 2005 (infobox and wikitable), AFAICT without any discussion. I agree that they should be removed, but I think we should ask User:Ed g2s first. —Ms2ger (talk) 18:03, 23 December 2008 (UTC)

I agree, this does not seem like something that should be applied to ALL headers, but was targeted at some kind of specific case. I favor removal. With or without edg2s consent :D --TheDJ (talk • contribs) 18:25, 23 December 2008 (UTC)

The inherit margins seemed to fix the off-centre issue at the time. One should probably consult the CSS specification. Although it may not go into that much detail... ed g2s • talk 22:21, 23 December 2008 (UTC)

(to all) I am quite familiar with the CSS spec ^;) I have encountered this issue elsewhere and in real-life. Removing these will fix a lot of captions out there. There may be local fixes in place on second or third tier templates to address the issue, but this removal will simply render those moot. If there are some cases way out in left field where this somehow affects something, the place to address the issue is out in whatever locality. I have no doubt that these rules were well-intentioned and that they may-well have been entirely appropriate at the time; times change — MediaWiki has changed, browsers are smarter (well, some of them are).

caption

header	header	header
data	data	data

caption

header	header	header
data	data	data

While getting the rendering 'pretty' is desirable, my core concern is semantics. If this issue has, in fact, deterred many folks from using proper captions, it amounts to a profound long-term setback for the projects. Having semantically correct captions on tables is core to proper accessibility of pages to things like screen readers and to correct analysis of page content by search engines. Fixing this issue is only a first step. A great many tables place what should be a caption-element in a top row-spanning cell that might not even be a th-element; it's made big and bold and blue and may have a background-color for extra meretriciousness. With proper css and template/table implementations, whatever desired rendering can be achieved with a true caption. Terima kasih. Cheers, Jack Merridew 04:59, 24 December 2008 (UTC)

nb: I've added a mock-up of how to fake a caption appearing 'inside' the table; it's not really, but the borders make it appear to. Cheers, Jack Merridew 15:34, 24 December 2008 (UTC)

 Done this seems to be the right way to proceed. Happy‑melon 15:52, 24 December 2008 (UTC)

Terima kasih (thank you). nb: I've just adjusted the examples I gave above to restore the incorrect behavior on the upper of the two pairs. Also, there was an issue with the final example that places the caption 'inside' the table when rendered by WebKit; TBD. Cheers, Jack Merridew 05:04, 25 December 2008 (UTC)

I've tweaked the 'inside' example and added another variant that gets WebKit working a bit better; will pick at this another day and build some working example elsewhere. Cheers, Jack Merridew 10:36, 27 December 2008 (UTC)

Can we add "textarea {font-family:inherit;}", please?

There's a discussion going on at Wikipedia:Village pump (technical)#Textarea_font_change where a bunch of us Safari users are annoyed that, as a result of bug 1941, text fields have been switched to use monospace fonts by default. This affects primarily Safari as Safari is slightly odd in that, by default at least, its textareas use multispace fonts. Bug 1941 aimed to specifically stamp out this inconsistency, and while a consensus on the English Wikipedia that this was a bad idea won't get the software changed for everyone everywhere, a consensus on the English Wikipedia can get our local Common.css file to countermand the default setting, by adding textarea {font-family:inherit;}. There are two questions which would be a primary barrier to adding this code:

• Does adding this code cause problems for other browsers, or otherwise change their normal behaviour for the worse?
• Is there any specific opposition to adding such code?

If this code works well enough, I'd like to add it. Would users who have other browsers, especially Internet Exploder, please test the rule using their monobook.css? {{Nihiltres|talk|log}} 18:53, 24 December 2008 (UTC)

Breaks Firefox 3 on Linux, the textarea inherits "sans-serif" from the body rule in main.css. Anomie⚔ 19:09, 24 December 2008 (UTC)

Gah. I'll look into making this a Gadget, then. Thanks for the input. {{Nihiltres|talk|log}} 20:25, 24 December 2008 (UTC)

This talk page exists for a reason

Guys, you really really should test your CSS and discuss it here first.

• Site-wide CSS that affects millions of viewers for up to 30 days is not a sandbox.
• Don't even make small changes without some discussion, you can fuck things up dramatically.
• Don't even change comments without discussion, you'd be surprised what can break.

--Splarka (rant) 22:50, 10 January 2009 (UTC)

Agreed. I admit I have made un-discussed changes in the past, but after a few incidents, I've learned what Splarka says is true: even minor changes can break the site. And cache is a bitch. I've reverted Happy-melon's changes, which from the outside seems kinda dickish, but we really do need to be careful with the site-wide JS / CSS. --MZMcBride (talk) 22:57, 10 January 2009 (UTC)

I accept and fully support the premise that A) changes that have a visible effect or change functionality should be discussed, B) that changes that don't gain immediate unanimous support should be reverted and discussed (and readding reverted code is strictly taboo), and C) that we need to be extra extra careful with CSS and JS. However, I don't think I can agree with MZ's conclusion that any change, no matter how trivial, should be discussed. And I think we can agree that, as edits to Common.css go, this is pretty trivial :D. Of course that was not my only edit, and it was in response to me screwing up my first addition by using the wrong comment syntax (reverted within a few seconds). But that last edit was an attempt to learn from past mistakes in the true wiki fashion.

I think some balance is needed here, between maintaining code integrity and avoiding unnecessary bureaucracy. I think that saying "discuss every possible change before making it" falls on the wrong side of that line. My philosophy remains "discuss changes in functionality, test all changes rigorously, and revert&discuss all changes on the slightest request". So in line with that, now MZ has reverted: does anyone object to the changes I made here and to Common.js to skin and dynamically style the show/hide buttons? Happy‑melon 14:49, 11 January 2009 (UTC)

I disagree with the comment that these lines of code should be removed in two thousand eight, but apart from that, I'm fine with them. However, I think you should've put the real code on the talk page for a few days before adding it—multiple pairs of eyes see more than just one. —Ms2ger (talk) 15:29, 11 January 2009 (UTC)

No objection from me. I agree that trivial edits like bugfixes, comment edits and minor styling changes shouldn't go through red tape. Anything else should be posted fro review first. — Edokter • Talk • 15:32, 11 January 2009 (UTC)

Best practices for editing these pages?

I finally took the time to put words on a page vis how I see our Best Practices in editing system messages, particularly the skin files: WP:EI. I don't think we need anything as pretentious as a policy or guideline to control how we work on these files, but it would be nice to have something to point to to ensure we're all reading from the same song sheet. Comments and criticisms would be very welcome. Happy‑melon 23:06, 11 January 2009 (UTC)

WP1.0 quality assessment colours

I now know why the first attempt to add the WP1.0 assessment scheme colourings (as used by {{FA-Class}}, {{Category-Class}}, etc) didn't work: the CSS specificity of the wikitable declarations overwrote the puny ".assess-fa" declarations. Now I've fixed and tested the declarations with the ".mediawiki" qualifier; they should sit in the correct place in the hierarchy now.

/* Skinnable CSS for assessment grades */
.mediawiki .assess-fa       { background: #6699FF; }
.mediawiki .assess-fl       { background: #6699FF; }
.mediawiki .assess-a        { background: #66FFFF; }
.mediawiki .assess-ga       { background: #66FF66; }
.mediawiki .assess-b        { background: #B2FF66; }
.mediawiki .assess-c        { background: #FFFF66; }
.mediawiki .assess-start    { background: #FFAA66; }
.mediawiki .assess-stub     { background: #FF6666; }
.mediawiki .assess-list     { background: #AA88FF; }
.mediawiki .assess-na       { background: #F5F5F5; }
.mediawiki .assess-         { background: transparent; }
 
.mediawiki .assess-category { background: #FFA500; }
.mediawiki .assess-disambig { background: #00FA9A; }
.mediawiki .assess-image    { background: #DDCCFF; }
.mediawiki .assess-portal   { background: #808080; }
.mediawiki .assess-project  { background: #C0C090; }
.mediawiki .assess-redirect { background: #C0C0C0; }
.mediawiki .assess-template { background: #FFCCFF; }
 
.mediawiki .import-top  { background: #FF00FF; }
.mediawiki .import-high { background: #FF88FF; }
.mediawiki .import-mid  { background: #FFCCFF; }
.mediawiki .import-low  { background: #FFEEFF; }
.mediawiki .import-na   { background: #F5F5F5; }
.mediawiki .import-     { background: transparent; }

As well as providing increased skinnability, this will allow us to get rid of Bad Things like {{FA-Class col}}, resolve problems like this and allow us to move towards a clean and low-overhead way of implementing these assessments without such a plethora of templates. Happy‑melon 10:28, 14 January 2009 (UTC)

It looks good to me, it would be nice to see all those *-class (tl|col|whatever) templates deprecated and (eventually) removed. AFAIK, they aren't properly documented anywhere, their usage is generally unclear, and it's not even clear how many of them there are. Adding these styles would allow us to eliminate all but one template for each assessment and importance grade, and that one remaining template would be a preformatted, prelinked cell for project banners to use. 「ダイノガイ千？！」^{(Dinoguy1000)} 22:54, 14 January 2009 (UTC)

 Done. Plenty of time for more discussion while the decaching time runs. Happy‑melon 00:52, 18 January 2009 (UTC)

The eternal hunt for deprecated classes continues

Spent a happy evening today going through looking for deprecated classes. Found quite a few that are either unused or close to it; comments appreciated on the possibility of removing each of these. Happy‑melon 23:13, 13 January 2009 (UTC)

.same-bg { background: none; }

Was implemented way back in 2006, but only ever managed to find its way into one article, and was redundant there. Its only other appearances are in people's monobooks (why people feel the need to copy the entirety of common.css into their personal skin files is something that I will never understand :D). Happy‑melon 23:13, 13 January 2009 (UTC)

I don't really see the point of this one. No objection to removal. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)

.prettytable

There are only 500 uses of class="prettytable" remaining 'in the wild'. Should we make the final jump to replacing it throughout and removing the duplicate declarations? Happy‑melon 23:13, 13 January 2009 (UTC)

I think this is our oldest "deprecated" class. The time might be right to start removing it for good. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)

I realised, that in OpenOffice.org 3.0 export filter to mediaWiki syntax is .prettytable still used. I'm not sure what to do with that, but if it is deprectated, maybe someone shall tell them. (please forget my bad english :-)) Multimotyl (talk) 23:26, 20 January 2009 (UTC)

.infobox.standard-talk

I mean really, WTF? Added April 2008; I can see how it makes a certain amount of academic sense, but it's unused and thoroughly deprecated. Happy‑melon 23:13, 13 January 2009 (UTC)

Not so sure here. But likely won't hurt. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)

div.videolist, div.multivideolist

Template:Video is gone, and it wasn't using these nasty unclickable background images anyway by the end. .listenlist will eventually go the same way now that {{listen}} has been updated, but there are still a lot of transclusions of {{multi-listen start}} to clean out first. Happy‑melon 23:13, 13 January 2009 (UTC)

.hiddenStructure

Iff Template:Bug is resolved favourably, we can polish this off in the same way as prettytable. Happy‑melon 23:13, 13 January 2009 (UTC)

Not 100% sure on this. Probably from a Talk page point of view, this class might still be useful for reading trough history and stuff. --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)

.Boxmerge

Added in December 2006, never made it further from de.wiki than here. Found a description of what it was supposed to do here; regardless of intent, it's completely unused here except in people's monobooks again. Happy‑melon 23:13, 13 January 2009 (UTC)

Let it be gone. :D --TheDJ (talk • contribs) 00:09, 15 January 2009 (UTC)

Request - thumb in Infobox

{{editprotected}} I sugest adding this:

/* Remove left and right border from thumbs inside .infobox */
.infobox div.thumb {
    border-left-style: none;
    border-right-style: none;
}

Thumbnails have coded border to have some margin from the text they float in:

div.tright {border-width:0.5em 0 0.8em 1.4em;}

But it does not look good in infoboxes (see Nikon D300).

Please forget my bad English. Multimotyl (talk) 01:17, 21 January 2009 (UTC)

Removing the border does not fix any alignment within an infobox. The standard practice is not to use thumbnailing in an infobox at all. This code fixes nothing in my opinion. — Edokter • Talk • 03:56, 21 January 2009 (UTC)

I tried it in my own early mediawiki project [1] and tested in major web browsers (MSIE, Firefox, Opera, Safari). Believe me, it works. The change i suggested is quite easy, safe and works well. Multimotyl (talk) 09:28, 21 January 2009 (UTC)

Your example still shows the border, but not the margin. Having tested your code here, the margin is not adjusted, and effectively shows no change. The margin is necessary to stay clear of text. Removing it here will cause surrounding text to stick to the thumbnail. While that may look better in an infobox, thumbnailing is intended to use in article text. Within a box, you should not use a thumbnail, but a seperate caption. So, I'm sorry, but this code will not be added. — Edokter • Talk • 15:31, 21 January 2009 (UTC)

Upon further review, removing the margin itself when embedded in an infobox may be a viable option, but that needs more discussion. I still feel thumbnails in an infobox is redundant. — Edokter • Talk • 15:36, 21 January 2009 (UTC)

It is border which is white so it looks like margin :-). Actualy I wasnt talking about margin property of CSS, but about border property which looks like margin. So maybe it seemed to you like I don't know, what I'm writing about. Thumbnail inside infobox may be redundant, but on the D300 example it seems useful to have a caption to describe the image. It shows not only the D300 itself, but also a lens. —Preceding unsigned comment added by Multimotyl (talk • contribs) 18:14, 21 January 2009 (UTC)

The border does not determine the space next to the thumbnail; you code does not do anything to remove that (it actually adds whitespace above and below the thumbnail). Really, the best thing to quickly fix it is to add a caption to the infobox. I'l add the code for you, so you can see the result. — Edokter • Talk • 19:39, 21 January 2009 (UTC)

Here's the result. — Edokter • Talk • 19:46, 21 January 2009 (UTC)

Hey, I was mistaken with something. I forgot, that there is also a MediaWiki:monobook.css Which removes the border (under /* Remove white border from thumbnails */ ) and puts a margin instead of them. It starts to get confusing :-). Thank you for your patience. I thought, that if there is border on my site so there is one on wipipedia too. And unfortunately I have Firebuged only my site. :-).