This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Step 6 is: 6. If PROTOTYPE's interface inherits from SVGElement, set NAMESPACE to SVG Namespace But PROTOTYPE is, afaict, just some random object, so it doesn't make sense to talk about its "interface". The spec needs to define what the actual check to be performed here is.
Boris, can you take a look? https://github.com/w3c/webcomponents/pull/21
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.
(In reply to Boris Zbarsky from comment #2) > 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. https://github.com/w3c/webcomponents/pull/24 Still feels unfinished in regard to the "canonical SVGElement prototype." What would be a better way to express that?
> What would be a better way to express that? The way ES6 does this is via a table like http://people.mozilla.org/~jorendorff/es6-draft.html#sec-well-known-intrinsic-objects We could probably define something like that in Web IDL, where %SVGElementPrototype% would be the default prototype object of the SVGElement interface for the current Realm or something. Except you don't want the current Realm, you want the Realm of the document involved. In any case, I think what you have is pretty unambiguous. Looking at the PR, the definition of SVG-PROTOTYPE is wrong: you want it to be the interface prototype object, not the interface object. Other than that, this looks good.
(In reply to Boris Zbarsky from comment #4) > Looking at the PR, the definition of SVG-PROTOTYPE is wrong: you want it to > be the interface prototype object, not the interface object. Other than > that, this looks good. Fixed and landed in https://github.com/w3c/webcomponents/commit/189b608a196f5464d8623817ed78e721de0e257b.