Large custom element spec rewrite to implement some F2F decisions #405
Conversation
|
This is a great change. I'd love to see the few example scenarios moved up in the doc (so that the reader encounters them for context earlier on before getting totally lost in the algorithms). +1 to merging in and then continuing to work out editorial issues. |
| <li><a>lifecycle callbacks</a>.</li> | ||
| <li>a <dfn id="dfn-element-definition-type" for="custom element definition">type</dfn>, which is a <a>custom element type</a>,</li> | ||
| <li>a <dfn id="dfn-element-definition-local-name" for="custom element definition">local name</dfn>, which is a <a href="https://dom.spec.whatwg.org/#concept-element-local-name">local name</a>,</li> | ||
| <li>a <dfn id="dfn-element-definition-constructor" for="custom element definition">konstructor</dfn>, which is a <a>custom element constructor</a>,</li> <!-- https://github.com/w3c/respec/issues/582 for why it's k --> |
There was a problem hiding this comment.
Haha! I thought that was deliberate!
There was a problem hiding this comment.
It is deliberate; see the HTML comment at the end of the line :( https://github.com/w3c/respec/issues/582
There was a problem hiding this comment.
Seems easy to fix when upstreaming.
|
Great change overall! Hopefully someone from Mozilla can glance over this and merge it tonight or tomorrow. |
| @@ -112,7 +112,7 @@ | |||
| <section> | |||
| <h2>Concepts</h2> | |||
|
|
|||
| <p><dfn id="dfn-custom-element">Custom element</dfn> is <a href="https://heycam.github.io/webidl/#dfn-platform-object">platform object</a> whose <a href="https://heycam.github.io/webidl/#dfn-interface">interface</a> [[!WebIDL]] is defined by the author. The <a href="https://heycam.github.io/webidl/#interface-prototype-object">interface prototype object</a> of a <a>custom element</a>'s <a href="https://heycam.github.io/webidl/#dfn-interface">interface</a> is called the <dfn id="dfn-custom-element-prototype">custom element prototype</dfn>.</p> | |||
| <p>A <dfn id="dfn-custom-element">custom element</dfn> is <a href="https://heycam.github.io/webidl/#dfn-platform-object">platform object</a> whose constructor and prototype is defined by the author. The constructor function supplied by the author is called the <dfn id="dfn-custom-element-constructor">custom element constructor</dfn>.</p> | |||
|
OK, addressed everything except @annevk's idea of switching the typeExtension parameter to an options object. I will file a separate issue for that. Maybe @hayatoito can give his signoff? Then I can squash into one commit and merge. |
|
I think we should just merge what we have now and address additional editorial issues in separate PRs. |
Notable changes: - Implemented HTMLElement constructor using @rniwa's algorithm from #403. - Rewrote element upgrading to use @rniwa's algorithm from #403, and incorporated it into the rest of the upgrading considerations. - Got rid of the ability to extend SVGElement, thus allowing us to remove most mentions of namespaces from the spec. - Removed createdCallback. - Rewrote "registering elements": - Uses defineElement instead of registerElement - Preserves the constructor instead of grabbing the .prototype property and synthesizing a new constructor - No longer spread out over four separate algorithms plus registerElement; everything is now inline under defineElement - More precise about exactly how to get the custom element prototype and callbacks - Rewrote createElement and createElementNS to be replacements instead of patches, and to call the author-supplied constructor. - Removed the "All Algorithms in One Diagram" section since so many algorithms changed or were inlined into their callers. - Removed the "Custom Elements and ECMAScript 6" section since it is very obsolete and does not reflect our current thinking. - New and rewritten algorithms do not use the unorthodox INPUTS/OUTPUTS blocks, or capitalized variable names. This is kind of a nice marker of new vs. old content. - I have taken over as spec editor for custom elements Notable things *not* substantially changed: - Parser changes are not specced still, besides to say that they should construct the element using its constructor. - Lifecycle callbacks were not changed, except for removing createdCallback. - Type extensions were not removed (yet?); it seems better to have a modernized version of them that we atomically remove. - Registries were not made available everywhere. Closes #403. Closes #365. Closes #283. Closes #185. Closes #170. Closes #169. Closes #167. Closes #163. Closes #162. Closes #161. Closes #158. Closes #137 (modulo the fact that #165 is still open). Closes #134. Closes #133.
|
Nice work @domenic! |
|
Apologies if this is not the best way to ask but I couldn't find the "end result" but a 404 here: As maintainer of the only Thanks for any clarification and update. |
|
It's deprecated and non-standard. |
|
You can find the specification here by the way: https://w3c.github.io/webcomponents/spec/custom/. It's been hosted there for a long time, not sure where you found the old URL. |
So, I accidentally rewrote a lot of the spec. All I wanted to do was land @rniwa's algorithm from #403 in, but it turns out everything is connected to everything else, and some sections were just so tempting, and... well, a lot of changes happened ^_^.
View the end result at https://rawgit.com/w3c/webcomponents/construction/spec/custom/index.html
Not sure how much editorial review we want to do. This is a big improvement in terms of aligning with the F2F's results and moving toward clean patches onto DOM and HTML that we can move into those specs. It might be better to land it soon instead of making sure all the editorial stuff is perfect.
It would be good to get the concepts reviewed of course. @rniwa, @annevk, @travisleithead?
Notable changes:
Notable things not substantially changed:
Closes #403. Closes #365. Closes #283. Closes #185. Closes #170. Closes #169. Closes #167. Closes #163. Closes #162. Closes #161. Closes #158. Closes #137 (modulo the fact that #165 is still open). Closes #134. Closes #133.