Talk:Requests for comment/Scoping site CSS

Local wikis should still be customisable

As said on email: it's there to make things customizable, this is good - don't remove. Max Semenik (talk) 21:59, 16 July 2013 (UTC)

+1. I disagree with the assertion that common.css is only supposed to be for styling articles. Bawolff (talk) 23:46, 16 July 2013 (UTC)

+1. Also I've no idea how this can be enforced while also not breaking Gadget CSS. Limiting this in common.css, etc but not in gadgets' CSS will simply mean admins will create a default CSS only Gadget and put their changes there, and have it on by default.

Plus getting changes through Gerrit is not trivial, and can't be done on a per-project easily at all. Yuvipanda (talk) 00:04, 17 July 2013 (UTC)

+1. Disabling local wiki customization (and causing a major uproar in the communities) for trivial benefit is a bad idea. Anomie (talk) 15:18, 17 July 2013 (UTC)

It seems like there are two issues here and people are focusing on one aspect of it and not the other.

In my opinion MediaWiki:Common.css is a terrible vessel for site customisation.

It leads to duplicate css rules and thus css bloat and inefficiencies.

CSS is extremely hard to manage and a key aspect of site performance (this slide deck is really interesting btw http://www.stubbornella.org/content/category/general/geek/performance-geek-general/)

What if we provided better ways to customise wikis in LocalSettings.php or a Special:SitePreferences page?

The same customisation could thus be achieved but our css would be much performance.

e.g.

$wgVectorTextColor = 'black'; $wgVectorLeftNavBackground = 'gray';

If such a thing existed your local wiki customisation arguments disappear (the RFC can just say this is a prerequisite) Jdlrobson (talk) 18:22, 17 July 2013 (UTC)

LocalSettings.php is not sufficient. And personally, I expect that a more complex and much less flexible "Special:SitePreferences" would also not be sufficient. Anomie (talk) 13:46, 18 July 2013 (UTC)

I do agree that a better / nicer way to customize the look and feel of MW would be very nice and welcome. But for lack of imagination I can't think of how powerful/useful such a tool could be without offering full CSS / JS control, which brings us back to this problem. Yuvipanda (talk) 00:19, 17 July 2013 (UTC)

Indeed, at Commons we used it to make the migration to #babel more popular, we use it to make GesHi output (e.g. js pages or LUA modules) readable without a magnifying glass, we use it to make the AbuseFilter-rules textarea larger than only 3 lines which is in 99% of the cases not enough, we use it to make the save button-text bold, and there are fixes for various bugs and some features in it. I agree that most of this should be fixed/added in/to MediaWiki but seriously, you can't expect someone to install and config git review; especially not on Windows. Rillke (talk) 08:55, 22 July 2013 (UTC)

Local wikis should still be customisable (2)

"If people want to style a UI they should be exploring new skins rather than adding global rules"

WTF. You realise that users can't just add new skins right? And it's especially pointless when they just want to add a couple of new rules.

Wikis being able to be different from each other is a good thing. Krenair ^{(talk • contribs)} 02:43, 17 July 2013 (UTC)

See my responses to threads above.

Adding global rules leads to dead css code and a css mess and is a habit we should move away from. We should provide better ways to allow customisation. Jdlrobson (talk) 18:24, 17 July 2013 (UTC)

How is this better in that way? Users and site administrators rarely have direct access to skins, extensions, and the site configuration itself. Unmaintained css, wherever it is, will 'die'. Changing the functionality of existing features will simply break stuff, as what is proposed cannot be backwards compatible. As people have pointed out already, being able to customise the overall appearance of an existing skin is expected and well-used functionality. There is no good reason to remove this.

Adding a separate content-scoped css interface message that would be called after common.css and skin.css might not be a bad idea, however, since that way users could put all the content-specific things there. Be a little neater away from the wider-scope stuff, and since it's all content anyway, definitions could be a bit shorter since the #content bit would be added automatically... -— Isarra ༆ 20:18, 17 July 2013 (UTC)

Hmm, perhaps we could deprecate 'common.css' in favor of 'content.css', and have people do skin specific hacks in Vector.css and Monobook.css? That'll mean people who just want content custom styling could get them easily (hence fixing problems for mobile), without taking away any customizability. content.css can be 'scoped', leaving the rest of them as is. Yuvipanda (talk) 20:22, 17 July 2013 (UTC)

+1 - that does seem like a better arrangement. 216.38.130.164 21:53, 17 July 2013 (UTC)

There would still be plenty of valid uses for the common.css, even with a content.css added. It would be neater to have more of the stuff in the content.css, but the content is simply not the only thing all skins tend to share in common (or, in some cases, that groups of skins share in common). -— Isarra ༆ 18:22, 18 August 2013 (UTC)

Major customizations

nv.wiki is given as an example of a negative customization. This is a bit sad, because it is actually one of the nicest examples of customization. Not just because it is beautiful - that's a matter of taste - but because it shows a real need that some communities have: To customize their wiki to show something of their culture and to make it more comfortable, but without making a whole new skin. Because you know what happens when a new skin is made, right? - The developers, quite rightly, don't want to support it, and bam: VisualEditor doesn't work.

Arabic had a comparable cultural customization in the past, but the introduction of Vector broke it.

A clever separation of styles that takes into account the communities' needs for cultural customization without getting in the way of introducing new technologies is the way to go. Amir E. Aharoni (talk) 10:41, 17 July 2013 (UTC)

It was I that brought up nv wiki. I agree it's a great example of customisation and self expression however my main concerns lie around interface elements for users that flick between languages. Selected tabs change colours and the menus look different - user interfaces can be hard to learn and if things look somewhat different within the same problem this creates huge user experience problems.

I agree that people should be able to customise skins more easily but MediaWiki:Common.css is a terribly bad way of doing it. It leads to rules like this

#foo bar a {
  color: blue;
}
#foo bar a {
  color: #ccc;
}

where the first rule is overwritten in the css cascade. Ideally there should just be one rule:

#foo bar a {
  color: #ccc;
}

Jdlrobson (talk) 18:16, 17 July 2013 (UTC)

That's an argument against using global (Wikimedia-wide) css, not against local MW:Common.css. Arthur Rubin ^en.Wiki (talk^en.Wiki) 22:52, 21 July 2013 (UTC)

De-scoping the proposal

I think it is a nice and useful thing to split UI and Content styles separately, than have them in same CSS file. If the RFC can be modified to say that (content-scope some site-wide CSS, do not content-scope others), I think it will have a lot more support. It'll also solve the problem of displaying content appropriately styled in various places while also not removing any existing functionality. Thoughts? Yuvipanda (talk) 20:34, 17 July 2013 (UTC)

Creating an entirely new (and equally powerful) way of letting users customize the site is a *huge* task, so removing that monkey off this RFC's back would make things a lot better :) Yuvipanda (talk) 20:36, 17 July 2013 (UTC)

That sounds like a good idea and good first step. Separating ui styling changes from article styling into MediaWiki:Ui.css would be a useful distinction and would allow the scoping of Common.css

To help with adoption we could imagine making this an opt in thing to allow time to move relevant styles from MediaWiki:Common.css Jdlrobson (talk) 21:12, 17 July 2013 (UTC)

ps. something funny about 'descoping a proposal about scoping css' :) Jdlrobson (talk) 21:13, 17 July 2013 (UTC)

Intentional :D YuviPanda (WMF) (talk) 21:46, 17 July 2013 (UTC) 21:20, 17 July 2013 (UTC)

So ideally, this should be split into multiple RFCs. The ones I can think of, so far:

1. LESS support for RL.
2. Separate CSS(LESS?) that applies just to content, and is scoped as such.
3. An easier way to custom-style your wiki that does not require you to edit CSS, and also can be as flexible as the current one.
4. Remove customizability via Site / User CSS.

1 and 2 should mostly get general support, and *should* get what we want (content styles that we can load by themselves without conflicting the UI). 3 is awesome, but also very hard - and does not have a clear use case. 4 is akin to taking away internet from a hackerspace (or wikitext from wikimedians :P) and is a lot, lot harder - and of limited benefit.

So... split this? :) Yuvipanda (talk) 21:44, 17 July 2013 (UTC)

Compass is better than LESS. Don't prejudice the solution by the choice of RFC titles. S Page (WMF) (talk) 00:22, 31 July 2013 (UTC)

[citation needed] (but yes the RFC shouldn't prejudice the solution - it should be a hard fought battle to the death between the two.. 121.54.112.171 00:51, 31 July 2013 (UTC)

I also like the idea of splitting Common.css into Content.css and Ui.css (or UiCommon.css). Content.css would be scoped to the content, and Ui.css would be general CSS intended for the UI. Common.css could then be deprecated.

I still like the idea of Requests for comment/Allow styling in templates as a longer-term modular approach to content/templates. Superm401 - Talk 22:53, 18 July 2013 (UTC)

Performance impact

So the idea is to generate descendant selectors? Does that have a performance impact on the client side? Browsers might have some sort of optimisation for plain class and ID selectors, and sometimes there are a very large number elements selected by site CSS in an article. I know we've previously been burnt by attempting to use child selectors, which turned out to be ridiculously inefficient in Firefox at the time. Tim Starling (talk) 06:57, 19 July 2013 (UTC)

I think it is worth measuring the performance impact this would have. I've made a few sites using descendant selectors and they are nice and snappy. jQuery UI uses them extensively as well. Still we should test it. NEverett (WMF) (talk) 14:24, 19 July 2013 (UTC)

Descending selectors are already widely used in MediaWiki in its existing skins. I don't see the point about performance (yes there was a performance issue, but now that MediaWiki has decided to use HTML5 as the default, this already implies a decent implementation of CSS and fast selectors. Every HTML5 renderer already has a decent speed for descending selectors. The issues are generally elsewhere, in unexpected defects of the rendering (e.g. in the box model, or rules of inheritance, or placement problems in case of conflicting restriction rules such as width vs. left and right, centering and effect of margins) Verdy p (talk) 12:25, 22 July 2013 (UTC)

SASS

I see a lot of support for LESS here - where is the love for Sass? Not that I really care too much one way or the other but I enjoy Sass.

One of the big advantanged of the CSS preprocessors I see is that you can write you css in lots of little understandable files but scoop them into a big minified one for usage. Would we support that? NEverett (WMF) (talk) 14:31, 19 July 2013 (UTC)

There are advantages to both LESS and SASS - we just need to decide which one is best for MediaWiki.

To me this is also a big advantage.

I guess we'll end up with LESS or SASS depending on the first person who implements a working solution :) Jdlrobson (talk) 00:19, 20 July 2013 (UTC)

Confused: is this a MediaWiki or Wikimedia RFC?

This RFC has a point but I'm confused about the scope: are you proposing these changes with all MediaWiki users in mind or are you focusing on the Wikimedia case? Consistency across Wikimedia sites is good and therefore setting limitations might be a good idea. However, the average MediaWiki site doesn't have problems like having different wikis with different admins not talking to each other, all under a same umbrella.

If the problem is to keep visual consistency across Wikimedia sites then the solution goes probably through a community agreement (like sticking to consistent logos or to the five pillars). Setting technical limitations without community agreements will just open the door to potentially uglier hacks in order to differentiate.

For a 3rd party MediaWiki admin, MediaWiki:Commons.css is a simple way to customize your site without moving away from Vector (arguably the only skin out there with a long term support guarantee) and without hacking directly the skin with changes that will be overridden in the next upgrade. Any changes to the current status should consider these two factors and offer something just as good or better.

About CSS bloat/abuse, what is the performance price for a wiki site? A default MediaWiki installation has already a jungle of CSS files with little to no documentation. Maybe a simple list of DOs and DONTs would help MediaWiki:Commons.css tweakers to do the right thing more than hardcoded limitations? Qgil (talk) 08:24, 22 July 2013 (UTC)

scoped style for a specific page

We have too many pages that use CSS style everywhere. This complicates their editing a lot. Why couldn't we have support for a <style>...</style> element that would be scoped to the editable #content ? This would apply to lots of data tabes that or now require too much complex editing in each cell. Of course the same restrictions about the CSS supported would apply: no Javascript for example. But everything we can already insert in a style="" attribute should be possible to restyle elements via CSS selectors, automatically scoped within #content. Verdy p (talk) 12:09, 22 July 2013 (UTC)

You can be interested by the sister RFC Requests for comment/Allow styling in templates. ~ Seb35 16:45, 22 July 2013 (UTC)

Local wikis should still be customisable (3)

Implementing this proposal would break existing functionality, where CSS is currently used to style parts outside the #content or where CSS is dependent on selectors including elements above the #content.

Examples (perhaps these examples below could or even should be rewritten in a better way, but who is going to do so across all existing wikis?):

• la:MediaWiki:Vector.css (styling #p-lang in order to show {{Link FA}} stars)
• la:MediaWiki:Common.css (styling #p-lang in order to show {{Link FA}} stars)
• la:MediaWiki:Gadget-vultus-smallcaps.css (selector above #content) UV (talk) 22:03, 25 July 2013 (UTC)

Why Less?

I don't agree that Common.css is only for article styling, but ignoring that...

How can you use Less to enforce scoping?

What prevents someone from putting this in Common.css?

   }
   
   body {
       color: red;

or this?

   a.my_custom_navlink { position: absolute; top: -50px; left: -50px; }

The first example should set body text to red by closing the scope you wrapped it with. The second example should push a link above and to the left of the article content.

If you want to limit CSS, I think you need to parse it, whitelist specific properties and values, and prepend a content div selector to all selectors. GICodeWarrior (talk) 04:21, 11 November 2013 (UTC)

You could get round this by pre-parsing MediaWiki:Common.css and then wrapping it. The first example would then throw a LESS compiler error. I don't think the 2nd example is much of a problem. There is a limit to the sort of things you can do with this kind of selector. People should be able to do those if they really want.

It seems that there is interest (below) in splitting Common.css into Content.css and UI.css to make where rules apply more explicit. Jdlrobson (talk) 17:25, 11 November 2013 (UTC)

Fair enough. As long as you don't consider it "secure".

===More examples===

In this example, the body text is turned green. Fiddle: http://jsfiddle.net/YbPRh/

Less:

#content {

@test: "}body{color:green;}/*";

@test2: %('"%s', @test);

a {a:@test2}

}

CSS:

#content a {

a: ""}body{color:green;}/*";

}

In this example, the body text is turned red. JavaScript is used here though and would have to be disabled anyways. Fiddle: http://jsfiddle.net/spEL5/

Less:

#content {

a {a:`'"}body{color:red;}/*'`}

}

CSS:

#content a {

a: ""}body{color:red;}/*";

} GICodeWarrior (talk) 04:10, 12 November 2013 (UTC)

Outcome from Architecture Summit

Please see the discussion in the January architecture summit. If people have made more progress since then, we could talk about it at this week's RFC review meeting. Sharihareswara (WMF) (talk) 05:44, 26 February 2014 (UTC)

Next steps from RFC review meeting

From the Feb 27 RFC review meeting:

• ACTION: more research required on advanced possibilities for scoping site CSS
  • consider splitting that out from the core RFC so we can get simple things done faster Sharihareswara (WMF) (talk) 23:28, 10 March 2014 (UTC)

Is there any progress on this? Thanks! Sharihareswara (WMF) (talk) 21:13, 7 April 2014 (UTC)

Not really. I've been busy with more pressing matters lately. Juliusz Gonera (talk) 21:26, 7 April 2014 (UTC)

Juliusz, is this maybe something I should mark as abandoned/dormant? Or maybe other front-end folks want to pick this up? Sharihareswara (WMF) (talk) 17:18, 17 June 2014 (UTC)

A helpful first step (regardless of what happens after) would be for someone to create an uptodate list of all the CSS that's actually in use.

ie. Enwiki's en:Wikipedia:Catalogue of CSS classes has been "outofdate" for many years, which is regularly frustrating - eg. when I'm trying to determine where-the-hell "class:foo" is defined I find myself opening up 15 tabs, but often don't find the target.

I'm not expert enough to attempt a comprehensive summary, else I'd try. I beg of someone, to do this. Here, there, anywhere.

(And, it would help this RfC, by showing the scope more clearly.) –Quiddity (talk) 19:03, 8 April 2014 (UTC)

Anyone could pick this task up - doesn't have to be Juliusz. Thanks for laying it out, Quiddity. Sharihareswara (WMF) (talk) 17:18, 17 June 2014 (UTC)

Using classes more

vector: Apply content text style via .mw-body-content instead of #bodyContent was just merged and claims «The use of classes for content styling has been recommended and generally agreed upon, specifically in the context of the RFC about scoping site CSS» in order to «finally liberate content styles from the notion of a singular body div on a pag». Reviewers pointed out some possible side effects, they may want to elaborate.

However, the RFC doesn't say anything about this yet, can it be updated? Can the alleged problem can be solved "simply" by using classes more? It's been a MediaWiki development mantra for a while to always put new stuff in a class so that it can easily be overridden (also on wiki) and reused. Nemo 05:33, 4 May 2014 (UTC)

To clarify, the commit message was just saying that one should use classes instead of IDs. That's not even remotely a proposal or worthy to write an RFC about, but a simple state of fact about writing proper CSS. Using IDs in CSS is exclusively bad practice. Sometimes out of laziness we use an ID, but it would always be an improvement to replace or supplement an ID with a class.

Find me one case where an ID is better, and I'll proof you wrong :)

As for this RFC (scoping of CSS), scoping is hard or difficult regardless of whether one uses IDs or classes. It might be slightly easier to scope things with classes, but it's mostly unrelated. I'm not sure why this RFC was mentioned in the second sentence you cited. Krinkle (talk) 15:14, 10 May 2014 (UTC)