CSS vendor prefixes, again...
We still have a major problem in CSS wrt CSS vendor prefixes... We have -moz-*, -webkit-*, -ms-*, -o-* and more all over the place and we all agree that what we have is suboptimal. During W3C Plenary Meeting this week, we discussed CSS Gradients. Introduced by Apple with a -webkit-* prefix, we now have at least 3 incompatible versions of gradients spreading in Web pages. Being myself an HTML+CSS editor implementor, I can tell you this is pure hell for me. But beyond editing issues, it's also a strong issue for Web authors because they have to maintain multiple versions of the same property in their stylesheets to be compatible with browsers that are not cutting-edge. Let's face it: we have a problem with Gradients (a really great feature by the way) because a browser vendor shipped it to the masses and there is no way to prevent web authors for massively adopt immediately such a great feature. It happened in the past for Gradients, it will happen again for other features.
On another hand, browser vendors need a way to implement experimental features and ship them, even if it's only for testing purposes. The CSS WG decided a while ago that if a given feature is stable enough across browsers, it should move faster along the REC track and the CSS WG should issue a call for implementations, tested with an official test suite.
But that's probably not enough. We still have one issue here: the "extraction" of a given feature from a given spec is not always easy, requires editing work and it's not instantaneous with respect to W3C Process. And if we keep the feature in its original spec, it means we call for implementations before the spec reaches a global interoperability, and that's not what the W3C Process wants. Thinking out loud, I wonder if a better solution isn't the following one:
- new strictly-experimental prefixed properties and values can be shipped but they are disabled by default in content. It means that they will output a warning on the console at parse time and they will not be stored in the CSS OM, not honored in Layout. I understand this could slow down a little bit CSS parsers but nothing comes for free.
- these experimental features can be enabled by the user using a special "Debug" menu.
- a web page can programatically prompt the user to enable these features, through a new API probably on
document. App-level (what we call chrome CSS in XUL) CSS does not need that, experimental features are still enabled by default in app-level CSS. I think enabling should be domain-wide, not global.
- all experimental features are disabled again for all domains when the browser is updated.
Then browser vendors can still implement, ship, make the community test the implementation, allow Web authors use the features in experimental web sites.
Opinions? (again, I'm only thinking out loud here to start the discussion)