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,

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.

Goals

 * Make writing css a little easier with nesting and selector grouping
 * Make modern standardized css just work in their shortest sanest form by automatically adding vendor prefixes needed for compatibility
 * Allow uploaded images on the wiki to be used inside css in a way that is well integrated into the wiki, reliable, and secure enough to allow for use inside of WikiText instead of only in site css.
 * Keep all enhancements compatible with existing css so that we can turn it on by default on all css files and safely offer the functionality within site and user css.
 * Make css secure enough to allow enough css support to have css embedded into WikiText such as infobox templates, message boxes, and layouts like the main page while being completely publicly editable.

Why not SASS or LESS?

 * SASS and LESS will incur two layers of processing cost. Neither support our @noflip or @embed so we would need to have our css processed twice once by SASS or LESS and another time by CSSJanus. While custom css processing code has the possibility to implement the same functionality as CSSJanus and usurp it doing both jobs at once. (LESS even seams to strip out css comments, meaning after processing we don't even have our @noflip or @embed rules to give to CSSJanus or CSSMin; among also breaking comment based IE hacks, including the IE5 one) Using our own code also lets us attempt to squash the IE maxiumum selectors issue.
 * SASS and LESS cannot give us -mw-file which allows background-images to come from wiki uploads complete with thumbnail generation and dependency linking to File: pages. Even if you manage to make something close it won't be safe for use in WikiText.
 * SASS and LESS are both languages of their own, they are not written to simply enhance css, but to sugar it with their syntax and are limited in a few ways we would want:
 * LESS at least is tripped up by things it can't parse. You have to add explicit escaping in order to write an IE filter. In other words LESS is incompatible with existing css without conversion that should not be necessary.
 * As far as I know, neither language has a sane syntax to express the case where you want to write a ::selection that needs to be completely duplicated into an extra ::-moz-selection because you can't use ::selection, ::-moz-selection because of css error handling rules.
 * Neither have the concept of understanding css properties. They won't fix your vendor prefixes. So you have to write messy mixins and functions and use those instead. Which is insane since you go into some completely separate syntax just to express what was supposed to be a single css property. This also means that you may not be able to do some things that are possible in the real property (most examples of these two with border-radius are simple functions that dump your input into properties; they don't take into account differences in syntax between implementations and hence can't support things like uneven elliptical radii). And of course also means that css authors will have to memorize which properties need prefixes and require mixins/functions and which properties don't; Instead of just being able to write their actual css and have the engine fix the properties that need vendor prefixes for them.
 * SASS and LESS just add syntax. They don't make it possible to securely allow css to be made editable by any user.

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

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

Additionally while filter and behaviors can often be used to give IE some css3 features these often have side effects and in some cases are incompatible with each other (eg: you can't use a border radius behavor and a gradient filter on the same element). Because of potential inconsistencies and other issues we can't generate IE compatible filters in a reliable way.

Vendor compatibility inside selectors is also intended. Right now the ::selection selector comes in ::selection and ::-moz-selection. The important thing being that because browsers are supposed to drop entire rules they don't understand, when you use a new selector like these you have to duplicate your entire css rule.

In other words, this css inside Resource Loader:

Will automatically become

;) though we could probably make it smarter:

I haven't thought of it yet, but we may introduce a syntax that will let you declare that you want a rule duplicated to separate selectors for compatibility. In other words a way that will let you write  but ensure that they are separated into two duplicated rules so that the > selector does not cause the   to not work in IE6.