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
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:
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
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
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
5 matches
Mail list logo
