Now vendor prefixes have become a problem, want to help fix it?

Today is a noisy day in the land of web development and the reason is a meeting of the W3C CSS working group where several people representing browsers discussed and agreed on supporting webkit prefixes in other browsers in order to “not break the web”. Read the notes of the meeting and search for vendor-prefix to get the original information.

This spurred Daniel Glazman, chair of the CSS working group to write a call to action to save the open web. Glazman has been opposed to the concept of vendor prefixes in the past and had some good arguments.

UK Developer and author Remy Sharp has a very detailed post on the subject called vendor prefixes about to go south where he discusses the dangers of supporting alien vendor prefixes in browsers.

Bruce Lawson also chimed in and actually has a quote that very much resonates also my feelings about the issue:

Personally – PERSONALLY – I’m pretty depressed about all this. I’ve spent 10 years – pretty much since IE6 came out – evangelising cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around[...] And now we’re doing the same again.

I took the opportunity to release something I already wrote in December, a call to arms to proactively fix browser-specific code on GitHub. Glazman disagreed with this approach but here is what I think:

• That browser vendors find themselves considering supporting the experimental prefixes of other browsers is sad. Everyone I know working on browsers advocates supporting the competition – it is what keeps us going
• The idea of vendor prefixes was to allow to try things out and become redundant over time. A try before you buy and a chance to test various approaches and then agree on one way as the non-prefix version. This hasn’t happened in the case of webkit- (or hasn’t happened fast enough)
• There are many reasons for that, one of them being the amazing success of Apple mobile hardware. Developers were asked to build exclusively for those and had to fight for extra time to test and support other browsers.
• Regardless of this being a bad thing we have to move forward and think of how we could avoid this issue in the future
• It is not hard to add at least a fallback to a non-prefixed version of the CSS effect. It is also not hard to replace overly zealous browser sniffing with a sensible feature detection.
• A lot of the code that gives the impression that webkit- is the only necessary feature to add is available on GitHub. Github by definition is a social network revolving around code and code there is meant to be amended, fixed and added to.
• So if you have a few minutes of your time, and you see something that is webkit only and can easily work in other browsers (or needs a non-prefix fallback) – why not fork it, do the fix and send a pull request?

This mess has partly been created by developers, the least we can do is help fix it. And it gives people a chance to help who are not planning to build their own massive library or solutions but care about making them work in the wider world of the WWW.

If there is one thing I learned so far is that “the only thing you need to support” on the web is a very fleeting concept. IE6 was the best and most amazing browser to support. WAP was the future, then imode, then XSLT to create HTML from XML… Do not believe the hype.