This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A custom element can extend another custom element (section 5.2). For each extendee, there must be an opportunity to create a shadow root. This requirement seems omitted from the custom element instantiation algorithm in section 4.
Recursive shadow-dom creation requires information about the extendee. The section 4 algorithm takes only 'prototype' and 'template' inputs and it's difficult to infer the extendee name from that input (it would require searching the custom element registry for matching prototypes). For our polyfill implementation we attached 'extendsName' to 'prototype' to get around this problem.
(In reply to comment #1) > Recursive shadow-dom creation requires information about the extendee. > > The section 4 algorithm takes only 'prototype' and 'template' inputs and it's > difficult to infer the extendee name from that input (it would require > searching the custom element registry for matching prototypes). > > For our polyfill implementation we attached 'extendsName' to 'prototype' to get > around this problem. Why not just use prototype.constructor?
(In reply to comment #2) > (In reply to comment #1) > > Recursive shadow-dom creation requires information about the extendee. > > > > The section 4 algorithm takes only 'prototype' and 'template' inputs and it's > > difficult to infer the extendee name from that input (it would require > > searching the custom element registry for matching prototypes). > > > > For our polyfill implementation we attached 'extendsName' to 'prototype' to get > > around this problem. > > Why not just use prototype.constructor? I need to know if my prototype is derived from another custom element. I don't see how prototype.constructor helps me find that information? I suppose 'prototype.__proto__.constructor' might be the constructor I'm looking for, but even then I need the Definition which contains the template and I have no map of constructors to Definitions. Yes, we could make a map of constructors to Definitions, but it would require Map support. The simple registry maps tag-names to Definitions.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Recursive shadow-dom creation requires information about the extendee. > > > > > > The section 4 algorithm takes only 'prototype' and 'template' inputs and it's > > > difficult to infer the extendee name from that input (it would require > > > searching the custom element registry for matching prototypes). > > > > > > For our polyfill implementation we attached 'extendsName' to 'prototype' to get > > > around this problem. > > > > Why not just use prototype.constructor? > > I need to know if my prototype is derived from another custom element. I don't > see how prototype.constructor helps me find that information? > > I suppose 'prototype.__proto__.constructor' might be the constructor I'm > looking for, but even then I need the Definition which contains the template > and I have no map of constructors to Definitions. Doesn't the generated constructor already have this information? All we need to do is call it, right?
(In reply to comment #4) > Doesn't the generated constructor already have this information? All we need to > do is call it, right? I am dumb. Ignore me. Let me ponder this.
(In reply to comment #5) > (In reply to comment #4) > > > Doesn't the generated constructor already have this information? All we need to > > do is call it, right? > > I am dumb. Ignore me. Let me ponder this. Here's what I came up with: we should be able to look up a definition from prototype. Once we do, we can adjust the constructor generation algorithm to recursively look up the prototype and repeat the shadow root instantiation steps. Naturally, actual implementations may choose to use other, more performant ways to achieve the same thing. WDYT?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > > > Doesn't the generated constructor already have this information? All we need to > > > do is call it, right? > > > > I am dumb. Ignore me. Let me ponder this. > > Here's what I came up with: we should be able to look up a definition from > prototype. > Once we do, we can adjust the constructor generation algorithm to recursively > look up the prototype and repeat the shadow root instantiation steps. > > Naturally, actual implementations may choose to use other, more performant ways > to achieve the same thing. WDYT? "look up a definition from prototype": is non-trivial as I mentioned above, but we may not have to. Your previous comment about constructors gave us an idea that we implemented in polyfill (that will be public as soon as I can make it so), which is to adjust the instantiate algorithm. There is a line there that says "Create a new object that implements PROTOTYPE". There is some wiggle room there. What we did was: 1. if PROTOTYPE extends a custom component, call extendee's constructor to create the new object, otherwise create a new DOM element as the new object 2. set PROTOTYPE as the new object's __proto__ This way, the information stored in the generated constructors is used (that was your hint). The only difficulty is determining "if PROTOTYPE extends a custom component" which could also be framed as "if PROTOTYPE's constructor is a generated constructor". We tagged generated constructor's with a flag to solve this problem.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > (In reply to comment #4) > > > > > > > Doesn't the generated constructor already have this information? All we need to > > > > do is call it, right? > > > > > > I am dumb. Ignore me. Let me ponder this. > > > > Here's what I came up with: we should be able to look up a definition from > > prototype. > > Once we do, we can adjust the constructor generation algorithm to recursively > > look up the prototype and repeat the shadow root instantiation steps. > > > > Naturally, actual implementations may choose to use other, more performant ways > > to achieve the same thing. WDYT? > > "look up a definition from prototype": is non-trivial as I mentioned above, but > we may not have to. > > Your previous comment about constructors gave us an idea that we implemented in > polyfill (that will be public as soon as I can make it so), which is to adjust > the instantiate algorithm. > > There is a line there that says "Create a new object that implements > PROTOTYPE". There is some wiggle room there. > > What we did was: > > 1. if PROTOTYPE extends a custom component, call extendee's constructor to > create the new object, otherwise create a new DOM element as the new object > 2. set PROTOTYPE as the new object's __proto__ > > This way, the information stored in the generated constructors is used (that > was your hint). > > The only difficulty is determining "if PROTOTYPE extends a custom component" > which could also be framed as "if PROTOTYPE's constructor is a generated > constructor". > > We tagged generated constructor's with a flag to solve this problem. To follow up, my head may be too much into polyfills, re: There is some wiggle room there: there is not really. re: looking up Definition from prototype is non-trivial: only in polyfill. I still like the idea of using constructors recursively instead of some in-place loop, but I'm not sure if that translates to spec.
WDYT: http://dvcs.w3.org/hg/webcomponents/rev/06623f2c090d I reworked the algorithm, and I think overall the spec text got a lot more clearer. Please reopen if I goofed.