I share this concern, but I don&#39;t think there&#39;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><br></div>

<div>div {</div><div>    -moz-box-sizing: border-box;</div><div>    -webkit-box-sizing: border-box;</div><div>    box-sizing: border-box;</div><div>}</div><div><br></div><div>I&#39;m fairly ambivalent on this. It&#39;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&#39;t so widespread that our hands were tied for the final API.</div>

<div><br></div><div>There&#39;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.</div>

<div><br></div><div>Ojan<br><br><div class="gmail_quote">On Sat, Jul 9, 2011 at 12:56 PM, Adam Barth <span dir="ltr">&lt;<a href="mailto:abarth@webkit.org">abarth@webkit.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

The IE blog has had a couple posts recently about new JavaScript APIs<br>
that are vendor prefixed:<br>
<br>
<a href="http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-1.aspx" target="_blank">http://blogs.msdn.com/b/ie/archive/2011/07/05/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-1.aspx</a><br>


<a href="http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-2.aspx" target="_blank">http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-2.aspx</a><br>


<br>
Here&#39;s one of their code examples:<br>
<br>
----8&lt;----<br>
// Future-proof: when feature is fully standardized<br>
if (window.requestAnimationFrame) window.requestAnimationFrame(draw);<br>
// IE implementation<br>
else if (window.msRequestAnimationFrame) window.msRequestAnimationFrame(draw);<br>
// Firefox implementation<br>
else if (window.mozRequestAnimationFrame) window.mozRequestAnimationFrame(draw);<br>
// Chrome implementation<br>
else if (window.webkitRequestAnimationFrame)<br>
window.webkitRequestAnimationFrame(draw);<br>
// Other browsers that do not yet support feature<br>
else setTimeout(draw, PERIOD);<br>
----&gt;8----<br>
<br>
There are a couple things to notice:<br>
<br>
1) The requestAnimationFrame API has a vendor prefix in all of these<br>
implementations, making this code ugly.<br>
2) The vendor prefix isn&#39;t buying us anything because this code<br>
assumes that the final, non-prefixed version of the API will work the<br>
same way that the vendor prefixed version works!<br>
<br>
If web developers are going to assume that future, non-prefixed<br>
versions of the APIs work the same way as current prefixed versions of<br>
the APIs anyway, we shouldn&#39;t bother with prefixed versions because<br>
we&#39;re already locked in to the current behavior, even without the<br>
prefix.<br>
<br>
Adam<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
</blockquote></div><br></div>