[Bug 27261] [Custom]: definition construction algorithm step 6 makes no sense

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27261

--- Comment #3 from Dimitri Glazkov <dglazkov@chromium.org> ---
(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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 21 November 2014 22:57:05 UTC