Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large custom element spec rewrite to implement some F2F decisions #405

Merged
merged 1 commit into from
Mar 3, 2016

Conversation

domenic
Copy link
Collaborator

@domenic domenic commented Mar 1, 2016

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:

  • Implemented HTMLElement constructor using @rniwa's algorithm from Rewrite Custom Element Construction Algorithm #403.
  • Rewrote element upgrading to use @rniwa's algorithm from Rewrite Custom Element Construction Algorithm #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.

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.

@travisleithead
Copy link
Member

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 -->
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: konstructor.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha! I thought that was deliberate!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is deliberate; see the HTML comment at the end of the line :( https://github.com/w3c/respec/issues/582

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems easy to fix when upstreaming.

@rniwa
Copy link
Collaborator

rniwa commented Mar 2, 2016

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>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a platform object*

@domenic
Copy link
Collaborator Author

domenic commented Mar 2, 2016

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.

@rniwa
Copy link
Collaborator

rniwa commented Mar 2, 2016

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.
@domenic domenic merged commit d95392f into gh-pages Mar 3, 2016
@domenic domenic deleted the construction branch March 3, 2016 03:01
@annevk
Copy link
Collaborator

annevk commented Mar 3, 2016

Nice work @domenic!

@WebReflection
Copy link

Apologies if this is not the best way to ask but I couldn't find the "end result" but a 404 here:
https://rawgit.com/w3c/webcomponents/construction/spec/custom/index.html

As maintainer of the only document.registerElement stand-alone polyfill, I'd like to know if the previous Custom Elements API has been already deprecated or if the new defineElement will simply coexist beside the good old API that both Polymer, X-Tags, and vanilla JS projects through my poly has been using for years now.

Thanks for any clarification and update.

@annevk
Copy link
Collaborator

annevk commented Mar 3, 2016

It's deprecated and non-standard. defineElement() is what all browsers will ship.

@annevk
Copy link
Collaborator

annevk commented Mar 3, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment