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 <aba...@webkit.org
<mailto:aba...@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@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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
