Requests for comment/Scoping site CSS
| Scoping site CSS | |
|---|---|
| Component | Frontend |
| Creation date | |
| Author(s) | Juliusz Gonera |
| Document status | stalled |
Background
[edit]Currently, custom CSS rules can be added globally by editing MediaWiki:Common.css (desktop) or MediaWiki:Mobile.css (mobile). This is used by many projects to add CSS rules commonly used by their communities for custom formatting within the articles.
Problem
[edit]- Unfortunately, those CSS rules are almost always global and might conflict with other rules defined by skins. They are a CSS equivalent of global variables. Enforcing administrators who edit those files to come up with unique CSS classes is unrealistic.
- The current ability to style all the page can lead to huge inconsistencies between different language projects. A reader of page X wanting to read the same page in a different language should have the feeling that they are still in the same website and haven't gone to an external project. nv:wiki is a good example. If people want to style a UI they should be exploring new skins rather than adding global rules as this leads to unnecessary CSS and larger page bloat and thus more inefficient pages.
- Custom CSS rules make designers' work more difficult. With them the design team will never be sure that the site looks like it is supposed to. The much needed redesign of the desktop web site will also be harder because the custom CSS rules will have to be checked after every design change.
Proposal
[edit]MediaWiki:Common.css should be deprecated and its use discouraged since every rule added there affects all the skins. Instead there should be a new MediaWiki:Content.css page where rules applied to article content can be added. If necessary (for a particular project or language), skin CSS overrides can be still achieved by editing e.g. MediaWiki:Vector.css for Vector skin.
Since MediaWiki:Content.css rules should be only applied to the article content, they could be scoped to work only for children of #content. It is unlikely that everyone who edits those rules will remember about this, but there is an easy way of post-processing the rules automatically. Assuming MediaWiki:Content.css contains:
.cool-list { color: red; }
.foo { color: green; }
we could wrap it using LESS nesting syntax:
#content {
.cool-list { color: red; }
.foo { color: green; }
}
and use a LESS compiler (now included in MediaWiki core) to generate the final CSS code.
Users editing the page would see the original CSS, not wrapped in #content { ... }, final CSS generation would happen behind the scenes.
Note: CSS in the User namespace would not be scoped, only the global one.
Questions
[edit]- When would be the final CSS compiled? It seems logical to compile it after every save and store it somewhere in parallel to the original page.
- Should we add a message at the top of the page saying that the rules are scoped
#contentafter saving? Or would it confuse users (do they even know that the article is inside a#contentdiv)?