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

[Robin Berjon]

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