The madness of prefixes and WebIDL (was Re: [blink-dev] Intent to Implement and Ship: Element.matches(selectors))

[Erik Arvidsson]

On Sat, Dec 14, 2013 at 3:47 PM, Philip Jägenstedt <phi...@opera.com> wrote:

It's curious that both including and not including support for the
unprefixed API before it has shipped can have a negative impact. I'm
very happy that the Blink project has a policy to stop this prefix
madness going forward!

Too bad the madness didn't end before it tainted WebIDL.

var requestAnimationFrame = window.webkitRequestAnimationFrame || 

    window.opRequestAnimationFrame ||

    window.mozRequestAnimationFrame ||

    window.msRequestAnimationFrame ||

    window.requestAnimationFrame;

The first one to remove the prefixed API loses :-( The reason is that the var shadows the method living on Window.prototype with an own property on window which is set to undefined. Now WebIDL is specing that all methods of the Window interface must go on the window instance object.

I would prefer that we decide to not follow the spec in this case and if we break something then we will tell people that we told them not to depend on prefixes and that they have to fix their buggy web sites.

-- 

erik

[Darin Fisher]

Fascinating, but wouldn't we only remove prefixed APIs when we observe that they aren't in use? If there are a lot of web sites coded like this, then we'd see a lot of usage of webkitRequestAnimationFrame, and we'd be reluctant to remove the prefixed flavor.

-Darin

[Elliott Sprehn]

On Sun, Dec 15, 2013 at 2:16 PM, Erik Arvidsson <a...@chromium.org> wrote:

On Sat, Dec 14, 2013 at 3:47 PM, Philip Jägenstedt <phi...@opera.com> wrote:

It's curious that both including and not including support for the
unprefixed API before it has shipped can have a negative impact. I'm
very happy that the Blink project has a policy to stop this prefix
madness going forward!

Too bad the madness didn't end before it tainted WebIDL.

var requestAnimationFrame = window.webkitRequestAnimationFrame || 

    window.opRequestAnimationFrame ||

    window.mozRequestAnimationFrame ||

    window.msRequestAnimationFrame ||

    window.requestAnimationFrame;

I'm not sure I understand, how does this assign undefined? All the values evaluate to undefined except the last one so this becomes:

var requestAnimationFrame = window.requestAnimationFrame;

so the function is still there.

[Alan Cutter]

I was skeptical of what Erik was saying as well until I tried it out. It appears that root level vars get stored on the window object and through the magic of hoisting gets implicitly assigned as undefined before the right hand side evaluates.

Running "var requestAnimationFrame = window.requestAnimationFrame;" in the console yields undefined.

[florian...@quantumedia.de]

Won't this be solved by testing the unprefixed version first (how it should be done anyway)?

[Adam Barth]

Unfortunately not.  The solution is to write:

window.requestAnimationFrame = ...

That way you're not introducing a new variable, which gets pre-initialized to undefined and shadows the real function of that name.

Adam

[Erik Arvidsson]

Remember that VariableDeclarations hoist and are initialized to
undefined, as well as all global bindings become own properties on the
global object (which is the window in a web browser).

There are a few solutions (Adam mentioned one).

1. Do not use global variables. The original code is fine inside a
function scope.
2. Use `window.requestAnimationFrame = ...`
3. You can also skip the var if you are in non-strict mode.

--
erik

[Mounir Lamouri]

Didn't that happen when vendors unprefixed IndexedDB too? We should add
this to the long list of reasons why we should not add stuff to the
window object...

-- Mounir

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[PhistucK]

I cannot agree more.

I always thought browser provided stuff should be under some single namespace.

☆PhistucK