Is vendor-prefixing JavaScript APIs a waste of time?
The IE blog has had a couple posts recently about new JavaScript APIs that are vendor prefixed: http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficie... http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficie... Here's one of their code examples: ----8<---- // Future-proof: when feature is fully standardized if (window.requestAnimationFrame) window.requestAnimationFrame(draw); // IE implementation else if (window.msRequestAnimationFrame) window.msRequestAnimationFrame(draw); // Firefox implementation else if (window.mozRequestAnimationFrame) window.mozRequestAnimationFrame(draw); // Chrome implementation else if (window.webkitRequestAnimationFrame) window.webkitRequestAnimationFrame(draw); // Other browsers that do not yet support feature else setTimeout(draw, PERIOD); ---->8---- There are a couple things to notice: 1) The requestAnimationFrame API has a vendor prefix in all of these implementations, making this code ugly. 2) The vendor prefix isn't buying us anything because this code assumes that the final, non-prefixed version of the API will work the same way that the vendor prefixed version works! If web developers are going to assume that future, non-prefixed versions of the APIs work the same way as current prefixed versions of the APIs anyway, we shouldn't bother with prefixed versions because we're already locked in to the current behavior, even without the prefix. Adam
I share this concern, but I don't think there's anything special here with respect to JavaScript APIs. The same argument applies to how people are often encouraged to use CSS property vendor prefixing. div { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; } I'm fairly ambivalent on this. It's not clear to me how much it buys us, but I can think of examples where it has worked well (e.g. gradients) because we were able to push the code out and get just enough usage to get useful feedback, but the usage wasn't so widespread that our hands were tied for the final API. There's been an immense uproar about vendor-prefixing on a number of w3c and whatwg mailing lists in the past year or two. Noone seems especially happy with the current tradeoffs, but noone has made a better proposal yet either. Ojan On Sat, Jul 9, 2011 at 12:56 PM, Adam Barth <abarth@webkit.org> wrote:
The IE blog has had a couple posts recently about new JavaScript APIs that are vendor prefixed:
http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficie...
http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficie...
Here's one of their code examples:
----8<---- // Future-proof: when feature is fully standardized if (window.requestAnimationFrame) window.requestAnimationFrame(draw); // IE implementation else if (window.msRequestAnimationFrame) window.msRequestAnimationFrame(draw); // Firefox implementation else if (window.mozRequestAnimationFrame) window.mozRequestAnimationFrame(draw); // Chrome implementation else if (window.webkitRequestAnimationFrame) window.webkitRequestAnimationFrame(draw); // Other browsers that do not yet support feature else setTimeout(draw, PERIOD); ---->8----
There are a couple things to notice:
1) The requestAnimationFrame API has a vendor prefix in all of these implementations, making this code ugly. 2) The vendor prefix isn't buying us anything because this code assumes that the final, non-prefixed version of the API will work the same way that the vendor prefixed version works!
If web developers are going to assume that future, non-prefixed versions of the APIs work the same way as current prefixed versions of the APIs anyway, we shouldn't bother with prefixed versions because we're already locked in to the current behavior, even without the prefix.
Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
ArrayBuffer has gone [mostly?] without vendor prefixing, CSS transforms and RAF (requestAnimationFrames) went with. createObjectUrl has been touch-and-go. As a dev, I look at RAF and CSS transforms and wonder why vendors couldn't agree to those two ahead of time. Then there is createObjectUrl and ArrayBuffer, which have had their unexpected changes in (WebIDL) specs and prefixing. It'd be nice to see a -fast track- decision process which might be tapped upon for future methods. If the four large vendors agree on a method name through a fast track process, perhaps devs could skip some vendor prefixing. The issue there, of course, is that vendors would be tacitly agreeing to implement such methods. And while they may agree internally and add it to their road-map, company policy may prohibit public acknowledgment. For example, I doubt any vendors object to the basic Typed Array types, and those types are not currently prefixed. -Charles On 7/9/2011 1:33 PM, Ojan Vafai wrote:
I share this concern, but I don't think there's anything special here with respect to JavaScript APIs. The same argument applies to how people are often encouraged to use CSS property vendor prefixing.
div { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; }
I'm fairly ambivalent on this. It's not clear to me how much it buys us, but I can think of examples where it has worked well (e.g. gradients) because we were able to push the code out and get just enough usage to get useful feedback, but the usage wasn't so widespread that our hands were tied for the final API.
There's been an immense uproar about vendor-prefixing on a number of w3c and whatwg mailing lists in the past year or two. Noone seems especially happy with the current tradeoffs, but noone has made a better proposal yet either.
Ojan
On Sat, Jul 9, 2011 at 12:56 PM, Adam Barth <abarth@webkit.org <mailto:abarth@webkit.org>> wrote:
The IE blog has had a couple posts recently about new JavaScript APIs that are vendor prefixed:
http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficie... http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficie...
Here's one of their code examples:
----8<---- // Future-proof: when feature is fully standardized if (window.requestAnimationFrame) window.requestAnimationFrame(draw); // IE implementation else if (window.msRequestAnimationFrame) window.msRequestAnimationFrame(draw); // Firefox implementation else if (window.mozRequestAnimationFrame) window.mozRequestAnimationFrame(draw); // Chrome implementation else if (window.webkitRequestAnimationFrame) window.webkitRequestAnimationFrame(draw); // Other browsers that do not yet support feature else setTimeout(draw, PERIOD); ---->8----
There are a couple things to notice:
1) The requestAnimationFrame API has a vendor prefix in all of these implementations, making this code ugly. 2) The vendor prefix isn't buying us anything because this code assumes that the final, non-prefixed version of the API will work the same way that the vendor prefixed version works!
If web developers are going to assume that future, non-prefixed versions of the APIs work the same way as current prefixed versions of the APIs anyway, we shouldn't bother with prefixed versions because we're already locked in to the current behavior, even without the prefix.
Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Jul 9, 2011, at 22:46 , Charles Pritchard wrote:
It'd be nice to see a -fast track- decision process which might be tapped upon for future methods. If the four large vendors agree on a method name through a fast track process, perhaps devs could skip some vendor prefixing.
The issue there, of course, is that vendors would be tacitly agreeing to implement such methods. And while they may agree internally and add it to their road-map, company policy may prohibit public acknowledgment.
The problem isn't with the naming, but more with the signature, with design changes, and with specification bugs. There are regularly some slight tweaks (e.g. the nullability of a parameter) that will change behaviour, sometimes quite radically. I think that part of the problem is that developers are treating prefixed methods in the same way as they treat prefixed CSS properties. With the latter, chances are that if the code was intended to be anywhere near production, you have a fallback for browsers that don't support the property at all, prefixed or not. Therefore, if the syntax changes and the unprefixed variant you've included fails to do anything, the site is still usable (barring bad luck in how the new syntax interprets data written to the old, which is unlikely). If you do the same with methods though, you risk blowing things up. I think method prefixing is very useful — it gives a lot more leeway for the standards process to fix bugs even in the face of an experimental feature having shipped to tens of millions of users (in fact it's probably more useful for JS than for CSS). But we should do a better job explaining to authors that prefixed methods are meant to be experimental, and that until such a time as a stable definition for a given method is produced the unprefixed variant should simply never be used. Yes, this means a need to update code later. It's just the cost of using experimental methods. I can't fault authors for making this mistake though, code like the one in that IE blog is a common fixture and a quick search couldn't seem to unearth decent advice in this area. -- Robin Berjon - http://berjon.com/ - @robinberjon
Vendor prefixing has proven to be vital to allowing one vendor to experiment with an idea before it has broad support for implementation by other vendors. It also means that we don't need to have coordination between vendors about release schedules for new APIs. Related to that, it also means that we don't dig ourselves a hole by introducing APIs we might later regret, which helps avoid web platform fragmentation. We get the opportunity, via renaming, to greatly alter the behavior of an API and converge on standards. Despite the blog post you quote, RAF is actually a great example of vendor prefixing working well. The original version of mozRAF doesn't work like the current one [ http://weblogs.mozillazine.org/roc/archives/2010/08/mozrequestanima.html]. Note, how it didn't take any arguments, but instead signaled the user via a MozPaintEvent! When we built webkitRAF, we decided that a function argument was better. Mozilla agreed and then changed their implementation. Note, I believe they had never shipped the first version to a stable channel, so it was easy for them to make the change. Sometimes, you can think you are confident enough and have enough agreement on an API to go ahead with a non-vendor prefixed implementation. We did that with Blob.slice. The spec was written by Arun from Mozilla, and there was a lot of review and debate about the API. Mozilla even had an implementation, but they had not shipped it yet. We figured it was unlikely to require vendor prefixing. Well, it turns out that on the eve of Firefox 4, someone realized that it should change to be more like Array.slice. Unfortunately, we had already shipped the old Blob.slice. Our remedy in this case was pretty awful. See http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0222.html. Safari hadn't yet shipped Blob.slice, so only Chrome was impacted by the change. Brendan made a pretty convincing argument that one vendor shipping non-prefixed shouldn't shackle others into implementing the same API [ http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0201.html]. The FileSystem API is another interesting case. Opera has had a FS API forever, but it is totally different than the one that we implemented. The one we implemented for WebKit has not yet been implemented by other vendors, and we haven't really received much feedback. One can imagine that once others begin to implement that they will have interesting feedback that might lead us to wish the API were different. Hence, it makes a lot of sense for the FileSystem API to be vendor prefixed. We get the chance for the non-prefixed version to be materially different. Back to the blog you quoted, I think it is very unfortunate that Microsoft (or any browser vendor) would advocate that people write code using untestable codepaths involving hypothetical unprefixed API. I hope the folks responsible for this one see this thread and fix the issue. Or, maybe someone knows how to get in touch with the right people at Microsoft? -Darin On Sat, Jul 9, 2011 at 12:56 PM, Adam Barth <abarth@webkit.org> wrote:
The IE blog has had a couple posts recently about new JavaScript APIs that are vendor prefixed:
http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficie...
http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficie...
Here's one of their code examples:
----8<---- // Future-proof: when feature is fully standardized if (window.requestAnimationFrame) window.requestAnimationFrame(draw); // IE implementation else if (window.msRequestAnimationFrame) window.msRequestAnimationFrame(draw); // Firefox implementation else if (window.mozRequestAnimationFrame) window.mozRequestAnimationFrame(draw); // Chrome implementation else if (window.webkitRequestAnimationFrame) window.webkitRequestAnimationFrame(draw); // Other browsers that do not yet support feature else setTimeout(draw, PERIOD); ---->8----
There are a couple things to notice:
1) The requestAnimationFrame API has a vendor prefix in all of these implementations, making this code ugly. 2) The vendor prefix isn't buying us anything because this code assumes that the final, non-prefixed version of the API will work the same way that the vendor prefixed version works!
If web developers are going to assume that future, non-prefixed versions of the APIs work the same way as current prefixed versions of the APIs anyway, we shouldn't bother with prefixed versions because we're already locked in to the current behavior, even without the prefix.
Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
participants (5)
-
Adam Barth
-
Charles Pritchard
-
Darin Fisher
-
Ojan Vafai
-
Robin Berjon