You’ve probably seen talk the last couple of weeks about browser
makers moving to adopt the -webkit prefix in their non-WebKit browsers.
Mozilla appears to be leading this move and the response from the
developer community has been to strongly suggest this as a very bad
thing.
Through the above, browsers and standards bodies can see how everything is working and ideally the information helps finalize the spec at which point browsers and developers move to support the non-prefixed version only.
If we as developers have been doing things right we already have that non-prefixed version in our code and nothing breaks.
However all is not perfect.
With that information I can make an informed choice about whether or not to use something and just as importantly where in the stack from “has to work” to “cool feature for those few who’ll be able to see it,” it should be added.
As developers we should do a better job of using vendor prefixed properties. We shouldn’t rely on them to the point of our sites breaking without them. We should lean toward not using proprietary features, except at the top of the progressively enhanced stack. And we should be better about using all vendor prefixes instead of just one or two.
Those of us who write about things like multi-columns and flexbox should be clearer about what is part of the working spec and what’s proprietary and not evangelize the proprietary as ready for use.
Vendors could dial back a bit on the proprietary stuff and drop support for prefixes once they are no longer needed. The W3C for it’s part could speed up its own process moving specs to the recommended stage.
We could all do something to help the situation.
Here then are some of the articles I’ve collected these past couple of weeks. They aren’t in any specific order other than the order they found me. A search for vendor prefixes will lead to plenty more.
The Issue
In a nutshell vendor prefixes exist to allow browsers and developers experiment with css properties like transitions that aren’t quite standardized yet. Each browser uses their own prefix, -webkit, -moz, -o, -ms, etc. and when we want to implement one of these properties we should use all these prefixes along with the non-prefixed version.Through the above, browsers and standards bodies can see how everything is working and ideally the information helps finalize the spec at which point browsers and developers move to support the non-prefixed version only.
If we as developers have been doing things right we already have that non-prefixed version in our code and nothing breaks.
However all is not perfect.
- Some vendor prefixed properties are not part of the spec.
- Some are proprietary and may never find their way into the standards.
- Some web developers are using these proprietary properties.
- Some browsers feel the need to support these proprietary properties or be seen as less capable.
- Some specs are often painfully slow to become standards.
What Can We Do?
I won’t pretend to understand every nuance of what’s at stake here. As a developer my main concern is I want to be able to transform an element here or animate something there and I just want to know how to do that and which browsers it will work in.With that information I can make an informed choice about whether or not to use something and just as importantly where in the stack from “has to work” to “cool feature for those few who’ll be able to see it,” it should be added.
As developers we should do a better job of using vendor prefixed properties. We shouldn’t rely on them to the point of our sites breaking without them. We should lean toward not using proprietary features, except at the top of the progressively enhanced stack. And we should be better about using all vendor prefixes instead of just one or two.
Those of us who write about things like multi-columns and flexbox should be clearer about what is part of the working spec and what’s proprietary and not evangelize the proprietary as ready for use.
Vendors could dial back a bit on the proprietary stuff and drop support for prefixes once they are no longer needed. The W3C for it’s part could speed up its own process moving specs to the recommended stage.
We could all do something to help the situation.
Additional Resources
Again I won’t pretend to understand every nuance in this issue and it’s possible I’ve mischaracterized a few things above. I’m still trying to sort some of this out, but think it’s important enough to want to present the issue sooner rather than later.Here then are some of the articles I’ve collected these past couple of weeks. They aren’t in any specific order other than the order they found me. A search for vendor prefixes will lead to plenty more.
- Call For Action: The Open Web Needs You *Now*
- Vendor Prefixes – about to go south
- This Must Not Happen!
- Unfixed
- TL;DR on Vendor Prefix Drama
- CSS vendor prefixes threaten open web
- Best Practice for Programming with Vendor Prefixes
- Every Time You Call a Proprietary Feature “CSS3,” a Kitten Dies
- The Vendor Prefix Predicament: ALA’s Eric Meyer Interviews Tantek Çelik
- SitePoint Podcast #150: The Vendor Prefix Kerfuffle
- Pre-fix the web!
- 7 Solutions to the CSS3 Vendor Prefix Crisis
- The vendor prefix mess
No comments:
Post a Comment