Talk:Requests for comment/Scoping site CSS

Previous page history was archived for backup purposes at Talk:Requests for comment/Scoping site CSS/LQT Archive 1 on 2015-07-10.

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?

This post was posted by Qgil-WMF, but signed as Qgil.

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?

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 :)

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

ps. something funny about 'descoping a proposal about scoping css' :)

Intentional :D

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? :)

Compass is better than LESS. Don't prejudice the solution by the choice of RFC titles.

This post was posted by SPage (WMF), but signed as S Page (WMF).

[citation needed] (but yes the RFC shouldn't prejudice the solution - it should be a hard fought battle to the death between the two..

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.

This post was posted by Mattflaschen, but signed as Superm401.

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

Is there any progress on this? Thanks!

Not really. I've been busy with more pressing matters lately.

Juliusz, is this maybe something I should mark as abandoned/dormant? Or maybe other front-end folks want to pick this up?

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.)

Anyone could pick this task up - doesn't have to be Juliusz. Thanks for laying it out, Quiddity.

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.

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.

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.

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.

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.

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;}/*";
   }

"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.

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.

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...

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.

+1 - that does seem like a better arrangement.

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).

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)

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.

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;
}

That's an argument against using global (Wikimedia-wide) css, not against local MW:Common.css.

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.

You can be interested by the sister RFC Requests for comment/Allow styling in templates.