Requests for comment/ResourceLoader CSS Extensions

This page proposes the idea of adding a module that does more work parsing css in modules (and perhaps in inline styles as well for some cases) and handles various forms of syntactic sugar in it to make css in MediaWiki more useful.

It's proposed that the code that does the css parsing is implemented to run in multiple ways. Notably for example when encountering css it cannot understand (due to a css hack, etc...) the implementation should have two modes, one which will leave the rule or property as-is so that hacks will still work and another which will discard the css it cannot understand. Additionally it should have functionality that allows us to declare that every selector in a body of css should be prefixed with a certain selector. These things along with some other restrictions may make it possible for us to allow limited css embedded into WikiText editable by any user. Leading to the potential for painless css attached directly to templates without any mess of inline styles,

The following sections detail various syntax extensions intended to be supported in css loaded by resource loader, and some (noted in the section) intended to be supported in inline style tags as well.

Note while we're doing this parsing we may take advantage of the fact that we'll be able to count selectors. Besides the maximum number of separate stylesheets IE also has another stupid limit on the number of selectors in a single stylesheet. Hence trying to efficiently concatenate css and stop that issue can create another. Since we're parsing the css there may be some way to try and save that information in a way we can use to separate concatenated css out when it gets too big.

@-mw-extendedcss
These css extensions define an @-block that may be used for some of our css extensions. Some of our css extensions may be in conflict with normal css that has simply been included into ResourceLoader but not written to take advantage of these features. In those situations it's useful to have a block that will allow us to enable some features only within the block.

Hierarchy
A nested & syntax is defined to allow complex nested css to be written simpler: This syntax is not randomly invented just for Resource Loader. The syntax comes from the css3-hierarchies spec. These rules will likely be implemented with the same parsing rules as the spec and converted to multiple rules with full selectors in the output css.

The & isn't legal in old css so this shouldn't be in conflict with any existing css so this extension will be available without the need for the extended css block.

:matches
A subset of the css selectors4 :matches selector will be implemented. selectors4 does not allow combinatorial selectors inside :matches like  so it's only usable in cases we can expand to full rules anyways. However in some cases when the css3-namespace syntax is used in :matches it can be tricky to turn into a full selector. Considering it's not even usable yet and we have no need for it, any :matches including css3-namespace syntax will be left as is instead of being converted into multiple full css selectors and may trigger the code to duplicate the rule's contents to ensure that any normal selectors are not broken by the inclusion of a new selector current browser cannot parse.

Like the & this should not be in use in old css so this will be available without the need for the extended css block.

-mw-file( name )
A  syntax is defined for any place that accepts a url. The use of it expands to a url pointing to an uploaded file. I am unsure whether we want to use  or   for the thumbnails.

-mw-file can't be in conflict with any existing css so it is available without the extended css block. Additionally due to how useful this can be it will also be usable inside of inline css. Because -mw-file does not suffer from the vulnerabilities of url it will be permitted inside of WikiText where url is stripped out.

bawolf also adds that using this syntax we can also register image dependencies to pages using it inline. Stylesheets too. And the use of the thumbnail syntax rather than normal urls also allows us to make sure thumbnails are generated on wikis without 404 thumbnail handlers.

Automatic vendor compatibility
Various new css properties need multiple vendor prefixes in order to work in all supported browsers. The actual writing of this by hand is worthlessly verbose and prone to error. Part of the css extension intent is to allow a standard property to be written normally like  and then have all the vendor prefixes implicitly added.

It's possible for these to conflict with old css so they are only enabled inside of an extended css block. That however may possibly be reviewed and changed. With actual parsing it's possible that we could just kill off old stuff that's not necessary and expand it right. As long as no-one is abusing vendor prefixes to give different browsers different things.

Note that due to the buggy differences in implementation of display: box; between WebKit and Gecko (the previous replaced css3-box) and the deprecation in favor of a new css3-flexbox spec we won't be expanding the flexible box model properties. Note that this does not apply to box-sizing which is noted in other specs and we WILL be supporting vendor prefixes for.