- From: Caridy Patiño <notifications@github.com>
- Date: Tue, 09 Oct 2018 15:24:39 +0000 (UTC)
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 9 October 2018 15:25:13 UTC
> it's not clear to me why that means it should be bound to insertion. @annevk agreed. Maybe something more analog to `attachShadow()` without the public getter is more suitable then. Something that you can optionally invoke during construction, e.g.: ```js class Foo extends HTMLElement { constructor() { super(); this._internals = this.createInternals(); } } ``` With the same semantics as `attachShadow()`, which means it can only be called once, and in the future we can add arguments to that API. It just feel to me that the createCallback() is a misstep, from many angles, including the pedagogical one, how to teach people that this callback is kinda special? > If we kick the callback inside create an element steps, we should prevent the callback from DOM mutation in order to avoid breaking createElement() semantics. @tkent-google yes, that will be weird, that callback is not really a callback from the point of view of the author, and it doesn't follow the other callbacks semantics either. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/758#issuecomment-428236374
Received on Tuesday, 9 October 2018 15:25:13 UTC