Boris Zbarsky wrote:
On 8/15/12 5:08 PM, Brendan Eich wrote:
Usually window.[standardized property name] is last -- this matters
below.
I don't see how it matters at all, actually.
It could matter if there's a stray indexedDB global lurking (set by
script previously) but the var indexedDB = ... code in question wants
the msIndexedDB on IE.
It could matter if a browser is like recent Firefoxes, and it defines
both prefixed and unprefixed, but it also has the ES5.1 erratum fix so
the var indexedDB by itself overrides an inherited
Window.prototype.indexedDB. Then you want the prefixed one first.
Firefox is affected by this problem (e.g., the result of the var
declaration is undefined)
Chrome is not affected by this problem because their var creation
algorithm checks the prototype chain for an existing property name
No, Chrome is not affected because their IDL bindings put inherited
attributes on the global object as "own" accessors.
It's not affected for both reasons, at least in the last version of
Chrome I tested.
Chrome -- really V8 -- doesn't have the ES5.1 erratum fix?
That's true, but see above point about order of || terms.
Again, the order of the || terms doesn't matter. "X || undefined" and
"undefined || X" both evaluate to X as long as X is not falsy.
Not always -- see above.
No. Rather, the erratum at
https://bugs.ecmascript.org/show_bug.cgi?id=78 was already fixed by
Mozilla, Google, Opera, and I believe IE and Apple.
It's not fixed by Apple as of the 2012-08-06 WebKit nightly.
It does seem to be fixed in Chrome dev (22.0.1229.6). It's not fixed
in Chrome beta (21.0.1180.79).
Ah, thanks.
We'll see if and when the fix makes it to a final release, but in
the meantime what's out there in users' hands right now does not have
the fix.
Rats. This makes Firefox have *two* "kick me" signs taped to its back.
Also, WebIDL-reliant spec authors must be careful not to define get-only
accessors (readonly attributes) on the global object or interfaces from
which it inherits. This leads to the idea that the global object
defaults to [Replaceable] (which may be removed from WebIDL as explicit
qualifier syntax) and [Unforgeable] must be used selectively for some
few historic exceptions.
Note that there is a middle ground between [Replaceable] and
[Unforgeable], which is where most props on the global live right
now.... I suspect for web compat we may want to default all future
stuff to being [Replaceable] but grandfather in the existing
non-replaceable things.
Whatever compat gods require. Hard to know whom they'll zap if a change
is tried, or when data collection is "done". This often leads to taking
the safe route and complicating the spec (in this case grandfathering as
you suggest).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
