[webkit-dev] Is vendor-prefixing JavaScript APIs a waste of time?

[Darin Fisher]

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 at 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-efficiently-in-html5-new-web-performance-apis-part-1.aspx
>
> http://blogs.msdn.com/b/ie/archive/2011/07/08/using-pc-hardware-more-efficiently-in-html5-new-web-performance-apis-part-2.aspx
>
> 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110709/cefb36a8/attachment.html>