MediaWiki talk:Common.css

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

Restore default style for HTML cite element

We used to wrap entire citation lines in a element, in some old citation templates. Now we are using HTML5, and the standard prohibits this kind of use. The element should be styled as italic by default, and can continue to be restyled for particular purposes (like citing a chapter, which appears in quotation marks instead of italics).

The italic styling will not interfere with readability, but it will help editors find any remnants where the element has been (mis-)used in this way.

The selector cite should be removed from the style sheet:

/* Default styling for titles of works, styling for the title of an article
   within a periodical, or a contribution within a compilation. */
cite,
.citation cite.article,
.citation cite.contribution {
    font-style: inherit;
}

 —Michael Z. 2013-02-27 22:15 z

Previous conversation was at Template talk:Citation#Semantic HTML. —Michael Z. 2013-02-27 22:17 z

As best I can see, this was added because cite was used to enclose an entire citation at one point, and italics was not desired. Here is some discusion. Under HTML5, <cite> is now only for titles. To me, restoring the default is proper. We aren't currently using <cite> in any of the citation templates, but I suspect we will add it down the road. --— Gadget850 (Ed) ^talk 12:44, 18 March 2013 (UTC)

Sure why not. We should probably fix those {{quote}} templates that use it, but then I don't see why we need this defined here any more, restoring the default seems proper. —TheDJ (talk • contribs) 20:59, 19 March 2013 (UTC)

I will take on that task. --— Gadget850 (Ed) ^talk 22:08, 19 March 2013 (UTC)

If there is no objection, then I will make that update when I have a block of time. I have a list of templates that will need to be updated. --— Gadget850 (Ed) ^talk 20:57, 27 March 2013 (UTC)

 Done --— Gadget850 (Ed) ^talk 00:46, 28 March 2013 (UTC)

"font-style: italic" for cite and cite.periodical

Given the above removal, is this CSS still needed, or can it be removed as well?

/* Styling for the title of any work within a citation,
   or specifically the title of a periodical. */
.citation cite,
.citation cite.periodical {
    font-style: italic;
}

「ディノ奴千？！」^{? · ☎ Dinoguy1000} 21:53, 24 May 2013 (UTC)

Should be OK. I can't think of any template where these classes are used. --  Gadget850 ^talk 00:28, 25 May 2013 (UTC)

Obsolete skin files

Shall I go ahead and delete all the obsolete skin files for Simple, Chick, Standard, Nostalgia and Myskin? — Edokter (talk) — 18:01, 23 April 2013 (UTC)

It appears that the old skins

• ⧼skinname-chick⧽
• ⧼skinname-standard⧽
• ⧼skinname-myskin⧽
• Nostalgia
• ⧼skinname-simple⧽

now fallback on Vector. --Redrose64 (talk) 18:11, 23 April 2013 (UTC)

Vector is the default fallback for 'any' unknown skin name. Due to removal, these skins are now effectively unknown. If you had them enabled, then they are still set in your prefs btw. If we were to change the default to VectorOmega, you would get that skin since your 'set' skin is still unknown. Only if you actively switch you preference, you will set a new 'fixed' skin for you as a user.—TheDJ (talk • contribs) 18:17, 23 April 2013 (UTC)

(e/c) Why not, if something comes back, we can undelete without a problem. —TheDJ (talk • contribs) 18:17, 23 April 2013 (UTC)

Done. Now to clean up the CSS catalogue. — Edokter (talk) — 19:02, 23 April 2013 (UTC)

"Updated since last visit" markers

It has been over a year since watchlist notification was turned on, only to be hidden immediately after. Now that the CSS has long been changed to allow better control over how to show changed watchlist items, I proposed to change the bullets back then, which met no opposition, but I never got around to implement it. So if there are no objection, I can put CSS in place the will replace the standard bullets ( and ) with green bullets ( and ), and re-enable the reset button. — Edokter (talk) — 14:07, 4 May 2013 (UTC)

Fonts

There is a discussion and request (here) for better support for more fonts, which would involve a change to this page. If there are any comments about this, please can you do so over there? — Martin (MSGJ · talk) 20:10, 21 May 2013 (UTC)

We now have a HUGE fontstack added that benefit a very low number of users. This is ten times worse then the original Unicode fontstack that was removed over a year ago for that same reason. I propose we remove this, as the benefits are very vague. — Edokter (talk) — 16:39, 8 June 2013 (UTC)

Reiterating my intention to remove this... I want some cases to prove this code is indeed needed, else I intend to remove it. — Edokter (talk) — 21:37, 22 June 2013 (UTC)

MediaWiki:Mobile.css documentation

There are a huge amount of various definitions for .hlists in MediaWIki:Mobile.css. The hlist class is used in the mobile skin ui and today we ran into various problems with the mobile's site design in a deployment (which adds talk pages to the beta mode of the site) due to existence of rules in MediaWiki:Mobile.css. I had no choice but to remove them temporarily as I couldn't work out how to make the css rules more specific and this seemed like a better option then reverting an entire deployment.

https://en.m.wikipedia.org/wiki/Special:MobileDiff/558513706...558513848

I'm hoping to be able to reinstate this in a different form with your help. Apologies for this inconvenience.

It would be useful if these rules were better documented and made more specific where possible to show where they are used so when these occasions do arise I can do something better than deleting them. For example in this case I suspect some of the rules are used by infoboxes so it would be good if they were only _targeted to infoboxes.

I've also spent a lot of time removing unnecessary CSS rules on mobile which were copied and pasted from MediaWiki:Common.css but were actually unused. Would be great if someone could have a look through and see if anymore are unnecessary. It's essential we keep the CSS on mobile as lean as possible to minimise the download size.

Feel free to chat with me on #wikimedia-mobile in irc.freenode.org — Preceding unsigned comment added by Jon (WMF) (talk • contribs) 22:42, 5 June 2013 (UTC)

@Jon (WMF): We should talk; I build hlist. I cannot imagine what kind of trouble you are getting. hlist is invoked only when called upon. Several templates use it, mainly navbox. The parts you just killed now makes them (and everything else hlist) illegible, as the list items are no longer separated. hlist should only affect HTML lists. It cannot be more specific, because it has a fairly broad application, BUT it should not interfere with other elements. I really like to know what errors you are getting, because having no separators in horizontal lists is pretty bad. (There is a test page here for stand-alone hlists.) — Edokter (talk) — 19:22, 6 June 2013 (UTC)

This is a simple classname clash. Jorm used hlist as a way to make a list horizontal. Per chance, we are using the same classname, but next to making the list horizontal, we added functionality on top to add list separators. There are two options, either we change the classname, or mobile project changes their classname. —TheDJ (talk • contribs) 09:35, 7 June 2013 (UTC)

I call precedence then; the hlist class has been in use for over a year now here. Whatever he introduced should be reverted, because the existing uses for hlist are now severely broken in mobile. As a side note; why is Jorn trying to reinvent the wheel? — Edokter (talk) — 17:08, 7 June 2013 (UTC)

I suppose you mean Jon, not Jorm? If Jon, it might be worth e-mailing him, as he seems pretty inactive on this wiki (other than to modify mobile.css). I agree that it was pretty disingenuous of him to just delete a whole chunk of mobile.css without actually fixing the source of the problem. — This, that and the other (talk) 11:15, 9 June 2013 (UTC)

Hey... the reuse in CSS is incredibly important [1]. On mobile this is EXTREMELY important when you consider problems that effect mobile such as data charges and bandwidth. Every little helps. So I take your 2 options and provide a 3rd option - "Make mobile project and Mobile.css classes more compatible".

Firstly, I made a minor tweak to the CSS to limit these rules so that they work on the stable deployed version of Wikipedia but not the beta site (who's ui uses it) until I can work out better ways to dealing with this. We have another deployment window on Tuesday before which I hope to fix this clash. I hope this keeps us all happy for the time being since it means your navbox styles work and it means the beta site does not look completely broken preventing users from using talk and editing which I'd argue are very important :)

Now I think about optimisation for mobile a lot. Yes it would be easier for us to choose a new css class here but reuse it exactly what we should be doing here. The .hlist is actually quite the widely used class outside Wikipedia. I've seen it in CSS files on the last 6 or so projects I've worked on. When I've encountered it in another projects it usually means "a list that is horizontal" and nothing else, although unfortunately here it seems to mean a lot more which I wasn't aware of. However that said I believe we should be finding patterns and working towards consolidation of MediaWiki:Mobile.css and mobile core css itself. We already have a terrible habit of reinventing the wheel (for example the CSS of infobox and navbox have a lot of overlap!) - if you visit the Barack Obama of Wikipedia with javascript disabled and run Chrome dev tools it reveals the scary fact that "505 rules (63%) of CSS not used by the current page." This is extremely wasteful. On mobile alas this is also slowly becoming a problem "133 rules (51%) of CSS not used by the current page". This bloat increases page load.

Note I am extremely interested in ways we can limit styling to only the pages that need it. I have been exploring template specific css in my research time (e.g. Template:Navbox would have a corresponding css file Template:Navbox.css). I have asked for better documentation in the MediaWiki:Mobile.css so I can understand what the rules are used for. I would love if you could provide this so we can optimise even further where necessary. Please please please don't see my edits as an attack but a challenge to improve loading times for our many increasing numbers of users in the global south.

I will keep you posted and sorry about this clash but I hope you see the potential here for greater good and don't see this as an attack on your work - more a teething problem! [1] http://www.slideshare.net/stubbornella/css-bloat Jon (WMF) (talk) 23:52, 9 June 2013 (UTC)

I suggest you check WP:CSS, although take it with a grain of salt, since it is quite outdated in places. (For example, .sysop-show is now used in speedy deletion tags, and probably other places too). But it will answer some of the questions in your mobile.css comments. In addition, the Wikipedia search tool actually picks up CSS class names: for example, searching in all namespaces for "nounderlines" shows that this class is actually used in very few articles and is probably not needed in mobile.css. As for "what is IPA?", what better place to look than an encyclopedia? — This, that and the other (talk) 00:25, 10 June 2013 (UTC)

Thanks This, that. I wasn't aware of WP:CSS and that is interesting - https://en.wikipedia.org/wiki/Wikipedia:Catalogue_of_CSS_classes#Classes was exactly what I was looking for. I'm aware of using search to find css class names although it's not 100% reliable (class="IPA foo", class="foo IPA bar" class="IPA" are all ways that the IPA class could be used) and it does worry me that certain rules are so underused. Ideally I would like to see rules commented with links to their templates to help understand their usage. Although I was aware of what an IPA is - I was more interested in how it was used. Looking at that table it seems to be exist there for "Font-selection fixes for Windows, for IPA". Looking closer I also see that the rule in Mobile.css is only removing an underline and mobile removes underlines by default - so this rule is unnecessary (https://en.wikipedia.org/w/index.php?title=MediaWiki%3AMobile.css&diff=559249441&oldid=559137660) - this is exactly why I'm challenging rules! :-) Jon (WMF) (talk) 16:19, 10 June 2013 (UTC)

The IPA rule is there to remove underlines on hover (and also for those who switch on "always underline links" in their preferences), because descenders are crucial to the understanding of IPA text. Do mobile platforms have an equivalent to "hover"? If not the rule can probably go. For the record, .compact-ambox is used by {{ambox}} in its compact form (e.g. {{expand section}}). Also, .rellink is used by {{rellink}} to produce "see also" and "main article" lines, e.g. Andrei Tarkovsky#Awards, and .dablink is likewise used by {{hatnote}} (I found these out by simply searching the Template namespace for "rellink" and "dablink"). — This, that and the other (talk) 05:26, 11 June 2013 (UTC)

I lie: .compact-ambox is used by {{multiple issues}} in order to hide the box, etc. around individual issue tags in the "new syntax" - you should have a play with it and see. I think these CSS rules need a bit of work: compare the desktop and mobile displays of issue tags in Alain de Lille and Matanivanua, for instance. There are plenty more articles to play with in mostly old syntax and mostly new syntax. — This, that and the other (talk) 10:58, 11 June 2013 (UTC)

OK, I was pretty pissed and frustrated to see navboxes broken again, until I realized I have the mobile beta site enabled. But in future, please provide any reasoning, including links, testcases and settings involved when making edits. Information is severy lacking. Now I would like to see pages where these failures occur, so I can gain some insight. — Edokter (talk) — 17:56, 11 June 2013 (UTC)

I agree, Edokter, but at the same time, a lot of what we have put in mobile.css is itself "severely lacking" in information. — This, that and the other (talk) 00:53, 12 June 2013 (UTC)

I also agree, documentation everywhere would help better (hence the original request!). Please let me know what is unclear about mobile styling. In terms of the current issue, currently the damage is limited to http://imgur.com/EUwCdec on beta (notice the dots). Ideally we should be able to limit these rules to the content itself (#content on mobile #bodyContent on desktop) - this will avoid any overlap with the UI. The UI for mobile is still very much in a state of flux as we add new features such as editing and talk pages. Until we have some stability there are going to be a few clashes of this sort but a general agreement to limit the scope of rules in Mobile.css to #content (just the content of the article itself) should avoid any future problems of this kind. Is this acceptable to you? Jdlrobson (talk) 19:26, 12 June 2013 (UTC)

cite: included work titles

We cleaned up <cite> so that it formats titles in italics. This is great for main titles, but not for included works such as chapters and articles. Seems to me that we can create a class to style this:

.includedtitle:before {font-style: normal; content: '\22';}
.includedtitle {font-style: normal;}
.includedtitle:after {font-style: normal; content: '\22';}

Then you simply wrap the content in <cite class="includedtitle">...</cite> causing the font to show as normal and the content wrapped in quotes. Thus we have the semantics that <cite> adds to the title and the visual presentation of the included title. And yes, I know that the before and after pseudo-elements won't work in older browsers. This would also allow user to style the quotes however they like and allow porting to other sites that use different quote styles. --  Gadget850 ^talk 19:07, 7 June 2013 (UTC)

request to remove an ancient edit

Please look at this edit. basically, it assigns white background to images inside divs inside thumbs.

at the time, "monobook.css" really meant "wikipedia's CSS". however, when vector became the default skin, this specific rule was not transferred to either vector.css or common.css, with the bizarre result that monobook differs from the default skin not only in the interface, but also in the content. IMO, the content is supposed to be independent of the skin.

this caused some issues with recent changes to {{Chess diagram}} (which was switched to use Module:Chessboard, for vast improvement in performance, and modest enhancements of the capabilities). part of the move was changing the image files we use for the pieces themselves, to utilize "transparent background" images. this is a good thing to do on several levels, and it took another 3-4 weeks for someone to notice that this caused monobook users to see the pieces with white background (neither the "white" nor the "black" squares this template presents are really white).

we do use this technique of displaying one image on top of another in other places (e.g. the way "pushpins" are displayed in "location map" templates). this rule means that such uses can't be inside "thumbs", even though it will show perfectly for default/vector users, just because of monobook. i think this css rule should be removed: there is no justification to create this discrepancy between the different skins, and it's way too late to add it for non-monobook users (it's not even clear if this is a good rule). in short - please remove it.

peace קיפודנחש (aka kipod) (talk) 19:05, 12 June 2013 (UTC)

Actually, there is a similair rule in Common.css, div thumb img.thumbimage, which _targets thumb images more specifically. So it seems that rule is redundant. I'll remove it. — Edokter (talk) — 19:25, 12 June 2013 (UTC)

Thanks. peace - קיפודנחש (aka kipod) (talk) 21:49, 12 June 2013 (UTC)

Appearance of Wikidata edits in the watchlist

Edits to a Wikidata item currently appear in the watchlist as given below:

• (diff | hist) . . Fire retardant (Q1354051); 02:13 . . Kanags (talk | contribs) (Language link added: ta:தீச்சுணக்கு)

Of the contained links, i.e. diff, hist, page name, item number, user name, user talk, user contribs and (if contained) interlanguage link, only one is within en.wikipedia. All the other go to Wikidata or in the example above to ta.wikipedia. Therefore, I suggest the following two changes:

• Coloring all non-internal links (everything except the link to the Wikipedia page) as external links, i.e. in a brighter blue (like ta:தீச்சுணக்கு as opposed to Fire retardant)
• Adding a d in analogy to b for bot edits or m for minor edits

Thoughts? --Leyo 13:11, 13 June 2013 (UTC)