- From: <bugzilla@jessica.w3.org>
- Date: Wed, 12 Nov 2014 02:24:59 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27261 --- Comment #2 from Boris Zbarsky <bzbarsky@mit.edu> --- Dimitri, thanks for writing that up. Some comments: 1) Per that proposal if a page sets SVGElement.prototype to null then even if a proto is handed in that inherits from the canonical SVGElement.prototype you won't get an SVG element out, right? More generally, do we want to base the check on the canonical SVGElement.prototype or on the value current at the call point? This is doing the latter, but it's not clear to me why this is preferable. 2) Please reference ES6, not ES5 for your JS bits. That matters, because in ES6 getting the prototype of an object is an operation that can have side-effects, unlike ES5. This also means that the "equivalent to running these steps" bit is a bit misleading: since the steps involved are effectful, can throw exceptions, etc, you have to actually run the exact steps involved. Might as well be up front about that. 3) If registering on a document in window A but passing a proto object that has the SVGElement.prototype from window B on its proto chain, what should happen? The proposal doesn't really define this, since it assumes that "<code>SVGElement</code>" defines an object. But it doesn't uniquely define one unless you say which global you're operating with. And even then you want to say something like "the interface object for the SVGElement interface for global X" or something along those lines. I don't have a strong view for which behavior we want here, for what it's worth, as long as it's defined. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 12 November 2014 02:25:00 UTC