Remy Sharp writes
Browsers need to:
- 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.
- 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.
- Work with the working groups (…Apple).
I agree with all of these points, but at the same time, I can’t see it actually happening. I just can’t see Google or Apple actually removing features from their browsers and moving them all into beta in perpetuity (because let’s face it, the standards process takes far far too long). Even if this did happen, I can well imagine most developers (and people who want these features) just switching to the beta and using that as their default browser, as most betas are fairly stable these days. That’s not solving the problem. It’s just moving it to another place.
I’ve seen two comments on Twitter that really resonated with me about all this. The first, from psd
the problem with vendor prefixes is the namespace is used to target a browser vendor rather than disambiguating similar proposed features
And strikes me as the current problem with vendor prefixes. Sure, the best features win out in the end (take the gradient syntax for example), but as it currently stands, the best feature ties rather too closely into the browser that implemented it. The solution would then be to drop the browser specific prefixes, and adopt feature based prefixes that, when they become popular, other browsers can implement and test out as well.
The other comment on Twitter, was part of a conversation between Mike Mahemoff
and Alex Russel
and mentions the CSS Mixin proposal
, are never really a problem. This is, to a large extent, due to the presence of shims and polyfills, that abstract all the browser differences away with the inclusion of a single script tag (think the es5shim for example).
first (yuck again!). I’m going to name this “The Dart Approach”, as it aims to solve the problems with CSS by forcing you to write something that isn’t CSS. The CSS mixin proposal would solve all of this in one step by allowing you to include a single CSS file (presumably from a CDN somewhere) that includes cross browser definitions for non-standard features. Then you just keep going as normal, and should anyone want to use a webkit only feature, they can go right ahead, safe in the knowledge that if Mozilla, for example, implement a similar feature (with their own prefix), it will just automatically work (as soon as the CDN is updated of course).
Developers are lazy. Browser makers don’t want to remove features (or relegate them to beta only). As with Piracy, the solution is not to educate the pirates (or in this case, developers/designers/browser makers); the solution is to make it easier to be cross browser compatible than to not be cross browser compatible (in much the same way jQuery does). CSS mixins seems to be a good way to accomplish this.
The only real problem now, is how quickly we can get it through the standards process (a problem in itself).