Anne van Kesteren

In defense of CSS prefixes

ppk wrote about CSS vendor prefixes considered harmful the other day. Rich with superlatives and some seemingly uninformed ranting it makes an interesting read. Lets be clear though, CSS prefixes are not the problem. I think what dbaron from Mozilla brings up on www-tag is a whole lot more accurate:

I think the underlying issue here is less a problem with the mechanism than a problem that the working group has not been aggressive enough in advancing properties to Candidate Recommendation (or to some other status where we've agreed implementations can implement properties without prefixes).

In many cases, I think this is related to different properties within the same draft having different stability levels.

Prefixes have been useful as a means for the CSS WG to be able to justify making changes to syntax or behavior of properties. E.g. -webkit-border-radius was initially way different from how we finally agreed the border-radius shorthand syntax should be like. The behavior of -moz-opacity was different from how opacity turned out. We could have some kind of common prefix, but that does not address the issue of moving ahead faster. And in the end it seems that introducing new standard features faster is what people are asking for.

(As a side note, I agree with ppk that certain properties are just done for. If a property is already around without a prefix it makes no sense to add one, unless you are doing something woefully different. This is what happened with e.g. overflow-x and overflow-y. Although Internet Explorer 8 introduced -ms- prefixed equivalents of those properties as well, for reasons that I still do not understand.)

Comments

  1. Yes, I would agree - some properties can have their prefixes safely killed now - and that's the fault of the browsers who are still clinging to the prefixes, in my opinion. Of course if you kill a vendor prefix you better make sure that common practice is that everyone is using the non-prefixed version in addition to the vendor ones.

    On the other hand, killing all vendor prefixes would lead to madness (either incompatible implementations, no implementations or first-implementation-wins scenarios).

    How can the process of moving the recs along be made faster? Modularization was one way, I guess but even that seems not fast enough. Per-property specifications?!? :O

    Posted by Jeff Schiller at

  2. I agree with this wholeheartedly.

    Posted by Frans at

  3. Jeff, I do not think that smaller specifications is the solution. Modularization is a joke that makes some people feel better; in the end everything is intertwined and the sooner we accept that the better in my opinion.

    I think the short term solution can be a simple as the WG declaring certain properties stable enough for implementation independent of draft status. Longer term we should figure out if we align specification work even closer with implementation work I think.

    Posted by Anne at

  4. The main problem with prefixed css props does not come from implementers. It comes from people who advice to use them in production.

    They're experimental, right ? So developers, use them experimentally only.

    Posted by David at