CSS Vendor Prefixes!

Updates Again

So @t (Tantek) via a @meyerweb @alistapart interview: This is the key point

“In addition, we are considering only supporting the -webkit- prefixed version of a property if and/or when we also support the unprefixed version.” Where we is Firefox Moble.

@meyerweb delivered a great interview, asking simple, pointed questions that needed to be asked. And @tantek did an excellent job answering them directly. All in all, it makes the kerfuffle over this seem a little less relevant, or does it? I take exception with a few assertions.

  1. “When users see a substantially worse experience in a different browser on the site on the same device, they blame the browser, not the site, nor the device.”: Um, most users don’t know what a browser is, much less have multiple ones installed on a mobile device and know enough to blame one over the other.
  2. “Should we give up on vendor prefixes now, despite their imperfect but impressive track record?”: This was asked by Tantek. Is this a joke? No. Of course not. The implied meaning here is unclear to me.
  3. “As web developers, there are few key things we can do…”: And then goes on to list things, which, as far as I can tell, are what developers should be doing anyway.

While I do agree that the responsibility for doing things right and doing the right things falls on developers, this whole things is starting to feel like Mozilla/Firefox Mobile whining.

Here is the problem: Supporting another agents vendor prefix takes away the ability of the developer to control (by virtue of which prefixes are implemented) which agents receive this information.

  • Developers: Keep doing your job. CSSWG nor Mozilla cannot make you do or not do it well.
  • CSSWG: Don’t bail on vendor prefixes.
  • Mozilla: Browser-up.


@plniss clarifies: http://remysharp.com/2012/02/09/vendor-prefixes-about-to-go-south/#comment-370255“Having a vendor prefix in a specification will simply not happen, ever. What has been discussed is simply adopting the WebKit implementations of those properties as the standard, however the standardized properties will not have the -webkit- prefix.”

Huzzah! Furthermore:

“The issue here is other vendors implementing support for -wekbit- prefixed properties in direct violation of the standards.”

#word However, the CSSWG can’t make browsers not do stupid things.

@ppk sounds off: http://www.quirksmode.org/blog/archives/2012/02/the_vendor_pref.html – I disagree with the idea that developers aren’t responsible and love the idea of -beta- prefixes.

@dandean pointed me to this: http://infrequently.org/2011/11/vendor-prefixes-are-a-rousing-success/ – #word. Also, -beta- would be better, though responsibility stays in developers hands.

@catalinred retweeted: http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/ – more of the same responsibility song. #like


The more I think about it, -beta- would have it’s own challenges. Sure, we’d know we’re doing something experimental – which is good, but it would prevent us from targeting specific user-agents, or NOT targeting them. That would kinda suck.

I’m still sorting through all the articles posted and the initial discussion, and while certainly folks have passionate opinions – which is a good thing! – perhaps things will look better in the morning. After a breath. After a snack. How I would love some toast right now.

There’s http://lea.verou.me/2012/02/vendor-prefixes-the-css-wg-and-me/, and http://daneden.me/2012/02/css-prefixes/, and http://www.kryogenix.org/days/2012/02/09/on-vendor-prefixes-in-css-and-vendors-implementing-them, and http://remysharp.com/2012/02/09/vendor-prefixes-about-to-go-south/, and http://www.brucelawson.co.uk/2012/on-the-vendor-prefixes-problem/, and the original discussion.

Btw, how fantastic is it that this discussion was so published? Huzzah for standards bodies! And also for everyone sharing their thoughts and participating. Not to be too much of a Gumdrops Gary, but this whole process is awesome. It’s the future of humanity. #theInternetWillSaveUs

If you haven’t watched the When We Build video, do so.

It is our responsibility as designers and developers to do the right thing. We know how and the resources from where to grab the stack of vendor prefix fallbacks that covers our targeted user agent audience, and remains standards compliant (using the non-prefixed versions).

Standards bodies are here to slow everything down a bit. Not be so hot-headed. To establish a path that will endure. Browser/Agent makers are here to meet the needs of the now. Implement all the newest proposed features. Make up new features. This creates an inherent tension between the two. This tension is good. And designers and developers have the glory of deciding how to proceed. What to implement for whom based on their target audience.

Being a designer/developer really is the best job.

It seems some respectable folks are coming down on the side of doing away with vendor prefixes. I don’t understand that. Though, to be fair, I’m not respectable. If browsers/agent makers are threatening to shoots the standards body in the head (by incorporating support for vendor prefixes explicitly), is it really a rational response for the standards body to shoot itself in the head (dropping vendor prefixes altogether)? I don’t think so.

The standards folks can’t stop browser/agent makers from doing something stupid.

I have found this vendor prefix route to be far superior to what we used hafta do, what with comment escaping hacks, or relying on the incorrect implementation working correctly in it’s incorrectness. Bleh. That sucked. Prefixes are much better. Plus as the path for the future gets rolled out, ever onward, and old prefixes fall away in favor of supported implementations, they do no harm. We should still remove them anyway.

The standards folks can’t stop designers and developers from being lazy.

These things we build are alive. The go on and on. They require love. The need to be pruned at the right times and for the right reasons. Designers and developers who aren’t doing the right thing won’t be designers and developers for too much longer. Putting code in production on behalf of clients for the world to consume is a sacred trust. We are the defenders of how the new world will be. It is a total rush. Even when it is tedious.

Hopefully everyone will take a day off from this sensitive area. Do some work. Read. Whatever. And come back to this when you’re feeling calm. It’s natural to get heated over this – it is important. But let’s not do anything rash.

We are where we are because of the path that lies behind. Let’s try to remember that.