CSS prefixes are becoming a threat - but is Webkit really to blame? / Daniel Eden

It seems like the whole internet is up in arms today — and for good reason, too. The CSS working group recently had a discussion about the -webkit- prefix, which started something like this:

tantek: At this point we’re trying to figure out which and how many webkit prefix properties to actually implement support for in Mozilla
plinss: Zero.
tantek: Currently we have zero. Zero is no longer an option for us.

This is something to be concerned about. The whole idea of languages such as HTML and CSS is to encourage web standards. Standards that are supported across the board, on all devices and browsers. To suggest including the -webkit- prefix in the CSS specification is completely absurd, and goes entirely against the whole point of the CSS working group and web standards in general.

One particular statement that brings a fiery ball of anxiety to my throat came from Opera’s Florian:

We are currently losing market share because of not implementing -webkit- properties.

Wrong. Opera, Firefox, and Internet Explorer are losing market share for a few reasons, but definitely not because they’re not implementing -webkit- properties. The main reason they’re losing market share is because they’re not implementing the same properties as Webkit. That might sound like the same thing, but it really isn’t.

Most of the prefixed CSS properties supported in Webkit and other browsers are based on proposed standards. Things like box-shadow and border-radius. The problem with Firefox and Opera is that they’re late to the game — the game that, admittedly, Webkit are setting the rules for. It was Webkit who proposed the gradient syntax (which has since been replaced by Mozilla’s much neater syntax) to the CSS specification. Several months later, Firefox and Opera supported a similar gradient property. The same applies to CSS animations, which are now supported in Firefox and the upcoming Opera 12, as well as Internet Explorer 10. And the same again for 3D transformations. You can probably see the trend here.

Webkit (or more specifically, Apple) are innovating in web standards. They’re breaking the perceptions of the traditional web and are contributing an awful lot to the CSS3 and HTML5 specification. Being an open source engine, all of Webkit’s progress and implementation of new features is publicly available. Since Chrome is based on Webkit, it makes sense for Chrome to have a very rapid development cycle in order to implement these new features. This leaves other browsers left in the dust — it’s one reason Firefox has adopted a more rapid development cycle.

Webkit is also gaining traction because it’s everywhere. It’s in our iPhones, iPads, Android devices, Blackberry handsets, Nokia handsets. It’s built into Mac OS X. It’s advertised everywhere from billboards to Google’s home page — the number one most visited website in the world. It’s fast. It’s user friendly. It isn’t bundled with crap. It’s stable. It’s free.

Other browsers are losing out on market share because Webkit is a better browser1. Other browsers are losing market share because they’re late to implement experimental features which web authors and users enjoy. Experimental or not, that’s the truth. To me, this suggestion of including the prefixed properties in the specification means one of two things: the opposing vendors (Mozilla, Opera, MS) are getting lazy, or they’re waving the white flag. And neither of these things are Webkit’s fault.

What happens next

If this idea goes through (which I’m sure it won’t), it could be the end of standards as we know it. Implementing the prefix will not fix Firefox or Opera’s market share — it will make Webkit’s larger. It’ll encourage web authors to never bother writing properties with prefixes other than Webkit, let alone writing the unprefixed version at all. Remy Sharp makes some good suggestions on moving forward (but I have some reservations about some of the things he says, which are highlighted):

Fucking drop experimental prefixes. It’s unacceptable and a disservice to the developers working with your browser. You need to give timelines to dropping these things. Totally agree.
Non-production ready browsers should support experimental prefixes, production ready releases should not. If it’s Chrome 16 — the stable version — experimental support should not be baked in. The properties should be full available without the prefix.This, I’m not so sure on. Mainly because I work in Safari, and there’s only really a stable version of that (there’s the Webkit nightlies, but they’re just a pain to set up)
Work with the working groups (…Apple). Agree. There needs to be more open communication between Apple and the Working Group, as well as a lot more effort from other vendors to implement experimental features, regardless of their opinion on it’s use. That’s the point, isn’t it? They’re experimental. Why not ship them?

Just as Remy did in his own article, I’ll leave you with this:

plinss: If we go down this path we have broken standardization.

1. When I say “Webkit is a better browser”, I do of course know that Webkit is not a browser, but is in fact a layout engine. I’m actually referring to Safari, Chrome, Safari iOS, Android’s browser, Blackberry’s browser, and (in some devices) Nokia’s browser. It’s just much faster to say “Webkit”

http://twitter.com/SamusAranX Dr. HURR ITS SECRIT

“Webkit is a better browser“
As long as they can’t get border-radius and overflow: hidden; to flawlessly work together, I’ll always prefer Firefox to any other browser.
Just sayin’.
Anonymous

Hi Dan,

Great thoughts on the recent W3C CSS WG discussions. I also mostly agree with Remy on his points and his post overall. However, the WG, as relatively slow as it may be in implementing things, is not mostly to blame here. Browser vendors should implement WG standards quicker than they are now — some vendors are arguably taking as long as the standards development time itself to implement CSS properties.

I strongly agree with you that allowing one vendor’s implementation of a property to be set as a standard is correct, as long as they are generalized as a standard. As you mentioned, use –border-radius, not –prefix-border-radius. In many cases, I believe the WG-proposed CSS property name is used for these prefixes.

Also important to note is that Apple and other Webkit developers, to the best of my knowledge, did not implement most of the newfangled CSS prefixes before proposing them to the WG. They don’t define CSS standards, they just respond, like the WG, to the Web development/design community. Yes, before the WG is able to define implementation details, browsers often split paths in the shape of experimental prefixes, but the CSS WG eventually decides which implementation to include in the final spec. (Note that CSS3, just like HTML5, is still being heavily drafted, and will be for many years.) The biggest choke point in this process is the CSS WG’s agreement, and after said agreement, vendor implementation time, both of which seem quite eternal for some more complex/controversial CSS properties.

Also, a semantic correction:
“Webkit is a better browser.” — Webkit is a rendering engine. Firefox is powered by Gecko, IE by Trident, etc. If we’re discussing correct semantics, the essence of specifications and documentation, we need to use correct semantics in the first place.

Much of how the CSS WG works is similar to how other W3C Working Groups work, such as the HTML WG developing HTML5. Some things may not be obvious to some people in the context of CSS spec. development, but if you look at them in the context of HTML spec. development, it will make more sense.

On a more personal tone, Opera members in W3C’s HTML and CSS WGs don’t seem to know how to verbalize their ideas, or have the wrong ideas in mind. This is not the first time in the past couple of years that controversy has sparked due to a statement they made. Most of this heated discussion stemmed from the Opera member’s statement.

An ideal process would be:
1) Have WG member(s) propose property and potential implementation
2) Start experimental browser implementations of WG proposed properties (which may differ from initially proposed implementation; we are computer scientists and experiment)
3) Formalize these implementations in the specification
4) Browser vendors implement. (Ideally, this would be quickly after spec is given recommendation status.)
5) Have a happy Web developer/designer community.

TL;DR: W3C specification process works and discussion is a crucial part of it. Problem is that browser vendors do not deprecate experimental implementations nor incentivize developers/designers to not use experimental implementations afterwards. Correct this and we’ll get rid of the big elephant in the Web standards world.

Cheers,
Alesandro
- http://nath.is/ Nathaniel Higgins
  
  You beat me to that correction.
- http://www.ashkas.com/ David
  
  RE time for implementation — I remember a talk from one of the Opera devs at a conference I was at years ago. He stressed that implementation of standards was more difficult that it appeared, because of all the contingencies. Meant that the process was quite slow.
http://www.lukejones.me/ Luke Jones

The only word I can think of is ‘absurd’. Seriously, what are they thinking? I thought browser vendors were supposed to be made up of people who give a damn, not idiots.
- http://AlesandroOrtiz.com/ Alesandro Ortiz
  
  As I said in my comment, imho, only some Opera folks have an odd mentality about Web standards. I believe it’s just the culture at Opera, and not representative of most folks within other browser vendors.
Pingback: CSS Vendor Prefixes! | folktrash