Skip to content

Commit

Permalink
Large custom element spec rewrite to implement some F2F decisions
Browse files Browse the repository at this point in the history
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.
  • Loading branch information
domenic committed Mar 3, 2016
1 parent ac70a46 commit d95392f
Show file tree
Hide file tree
Showing 3 changed files with 303 additions and 614 deletions.
1 change: 0 additions & 1 deletion spec/custom/W3CTRMANIFEST
Original file line number Diff line number Diff line change
@@ -1,2 +1 @@
index.html?specStatus=WD;shortName=custom-elements;useExperimentalStyles=false respec
custom-elements-whole-world.svg
246 changes: 0 additions & 246 deletions spec/custom/custom-elements-whole-world.svg

This file was deleted.

Loading

5 comments on commit d95392f

@chaals
Copy link
Contributor

@chaals chaals commented on d95392f Apr 5, 2016

Choose a reason for hiding this comment

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

Domenic, in order to be an editor of a W3C spec it is a Process requirement that you are a member of the Working Group that produces it. Google is a member of Web Platform, but haven't yet nominated you - please fix that.

@domenic
Copy link
Collaborator Author

@domenic domenic commented on d95392f Apr 5, 2016

Choose a reason for hiding this comment

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

OK, I can remove myself as editor and revert the spec to its old state, since it seems like there is some disagreement about future direction per #377 (comment) anyway. We'll continue development in the HTML and DOM Standards instead.

I'll do that tomorrow. Heading home now.

@domenic
Copy link
Collaborator Author

@domenic domenic commented on d95392f Apr 6, 2016

Choose a reason for hiding this comment

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

Done; I am no longer editing the spec. It has been reverted to the last revision which meets the process requirements: https://w3c.github.io/webcomponents/spec/custom/. Will get the relevant parts integrated into HTML/DOM later today.

@rianby64
Copy link
Contributor

Choose a reason for hiding this comment

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

Can't believe that! @domenic's commits and contributions are outstanding. Can't understand this decision. Who cares if Google or Mozilla nominates a person for this job? That's a very poor argument!

@annevk
Copy link
Collaborator

@annevk annevk commented on d95392f Apr 22, 2016

Choose a reason for hiding this comment

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

It doesn't really matter at this point. It's all been upstreamed to where it needed to end up anyway.

Please sign in to comment.