Add custom elements to HTML by domenic · Pull Request #1012 · whatwg/html

domenic · 2016-04-07T23:23:52Z

This upstreams custom elements into the HTML Standard, instead of having
them be in a separate spec that monkeypatches HTML extensively. This
builds on previous work in whatwg/dom#204.

See https://rawgit.com/w3c/webcomponents/15a203c8393aef0df7223ab1d43406aa11a7e71e/spec/custom/index.html
for the source material, in particular the sections labeled "HTML+". All
changes while upstreaming were editorial in nature.

Review appreciated, especially in the form of pushing fixups to the branch.

annevk · 2016-04-08T03:04:41Z

images/content-venn.svg

     <li><code>var</code></li>
     <li><code>video</code></li>
     <li><code>wbr</code></li>
+     <li><span>custom tags</span></li>


The plan is to rename this in a follow up commit?

Yeah, I guess, if we ever figure something out.

Well I think we need to. "tags" is just super wrong.

annevk · 2016-04-08T03:08:51Z

I should have asked this earlier, where exactly does NewTarget come from? Is that worthy of a note or a cross-reference?

domenic · 2016-04-08T04:49:57Z

I should have asked this earlier, where exactly does NewTarget come from? Is that worthy of a note or a cross-reference?

I think it would be ideal to cross-reference, but ES does not have a definition for it; instead as far as I can tell it's just an ambient floating thing all ES algorithms get. I'll file an ES bug.

domenic · 2016-04-08T04:54:59Z

source

+   <li><p>If <var>name</var> is <code>blink</code>, <code>bgsound</code>, <code>isindex</code>,
+   <code>multicol</code>, <code>nextid</code>, or <code>spacer</code>, return
+   <code>HTMLUnknownElement</code>.</p></li>
+   <!-- These have to be explicitly listed because technically we define these elements in HTML,


This helps with https://www.w3.org/Bugs/Public/show_bug.cgi?id=27877, but probably doesn't completely take care of it, as basefont might still be confusing.

domenic · 2016-04-08T18:08:38Z

I pushed fixes addressing the issues I noted on @annevk's commit. One interesting issue it raised is defining element interface for obsolete elements better. I will open a new issue on that.

domenic · 2016-04-08T20:14:39Z

Should "Core concepts" be named "Processing model"? Maybe not, since so much of the processing model is defined elsewhere...

annevk · 2016-04-09T10:16:57Z

source

   <code>multicol</code>, <code>nextid</code>, or <code>spacer</code>, return
   <code>HTMLUnknownElement</code>.</p></li>
   <!-- These have to be explicitly listed because technically we define these elements in HTML,
        albeit as obsolete. -->


This comment is obsolete with this commit, no?

Yeah good catch

annevk · 2016-04-09T10:21:25Z

Would you mind if I added ", then" to conditionals?

annevk · 2016-04-09T10:21:58Z

Although with all the don't squash that might get a little labor intensive...

domenic · 2016-04-09T15:35:59Z

You can add it, it's fine. Maybe don't add it to the sections touched in "don't squash" and I can do those myself when I rebase and rearrange commits.

annevk · 2016-04-13T04:43:55Z

I think it's all good now. I have fixed up the commits to add "then" and removed "don't squash" from the titles. Admittedly I have relied in part on my earlier review of the algorithms. Since I assume you just moved them around.

zcorpan · 2016-04-13T11:15:53Z

source

+   data-x="concept-custom-element-definition-name">name</span> <var>name</var>, then return that
+   entry's <span data-x="concept-custom-element-definition-constructor">constructor</span>.</p></li>
+
+   <li><p>Otherwise, return undefined.</p></li>


I think it's more common to return null from a method. Why undefined?

I noticed that. I suspect @domenic wants to mimic Map semantics.

Yes, exactly, map-like get() methods need to return undefined.

zcorpan · 2016-04-13T11:41:49Z

There needs to be a normative statement saying that <html is> is invalid, e.g. "The is attribute must not be specified."

zcorpan · 2016-04-13T12:13:29Z

Do we want to allow any attribute on customized built-in elements? In particular those in the obsolete section? Note that embed allows any attribute except those that are obsolete (e.g. name).

zcorpan · 2016-04-13T12:29:22Z

+   <dt><var>window</var> . <code data-x="dom-window-customElements">customElements</code> . <code
+   data-x="dom-CustomElementsRegistry-define">define</code>(<var>name</var>,
+   <var>constructor</var>)</dt>

These typically have a subdfn attribute (which I think is for developers.whatwg.org?).

zcorpan · 2016-04-13T12:53:49Z

(Reached the end of the diff; no more comments.)

domenic · 2016-04-13T13:30:21Z

There needs to be a normative statement saying that <html is> is invalid, e.g. "The is attribute must not be specified."

Why?

Autonomous custom elements should also not allow the is attribute, right?

Good catch, thanks.

Shouldn't this use removeAttribute?

Either would work, I imagine. -1 is more explicit IMO?

Do we want to allow any attribute on customized built-in elements? In particular those in the obsolete section? Note that embed allows any attribute except those that are obsolete (e.g. name).

Hmm. We probably should? I have no real idea how to phrase this though, or which sections to edit. Suggestions?

These typically have a subdfn attribute (which I think is for developers.whatwg.org?).

Thanks, will add.

zcorpan · 2016-04-13T14:06:11Z

Either would work, I imagine. -1 is more explicit IMO?

-1 means it's still focusable if you click it. Also the code above uses removeAttribute and the prose talks about removing the attribute.

zcorpan · 2016-04-13T14:08:00Z

Why?

The content model is normative, but nothing says the attributes list is. The rest of the spec addresses each attribute individually in prose I believe. So right now it's a statement of fact that's not backed up by anything normative. :-)

annevk · 2016-04-13T14:21:19Z

Why can't is be specified on html anyway? It works, right?

domenic · 2016-04-13T14:27:14Z

Yeah, that was my question.

I agree with you now about removeAttribute; thanks for that.

zcorpan · 2016-04-13T15:04:23Z

Oh, I don't mind allowing is on html. Then remove , except the <code data-x="attr-is">is</code> attribute.

zcorpan · 2016-04-13T15:04:43Z

Hmm. We probably should? I have no real idea how to phrase this though, or which sections to edit. Suggestions?

How about...

diff --git a/source b/source
index 0967e3a..a627fa4 100644
--- a/source
+++ b/source
@@ -28002,8 +28002,8 @@ attribute, set the <span>browsing context name</span> of the element's <span>nes
   <p class="note">All attributes in <span>HTML documents</span> get lowercased automatically, so the
   restriction on uppercase letters doesn't affect such documents.</p>

-  <p class="note">The four exceptions are to exclude legacy attributes that have side-effects beyond
-  just sending parameters to the <span>plugin</span>.</p>
+  <p class="note">The four exceptions are to exclude <span>obsolete attributes</span> that have
+  side-effects beyond just sending parameters to the <span>plugin</span>.</p>

   <div w-nodev>

@@ -67011,9 +67011,13 @@ console.log(plasticButton2.getAttribute("is")); // will output "plastic-button"<

   <p>An <span>autonomous custom element</span> does not have any special meaning: it
   <span>represents</span> its children. A <span>customized built-in element</span> inherits the
-  semantics of the element that it extends. Both types of <span>custom element</span> may have any
-  non-namespaced attributes that are relevant to the element's functioning, as determined by the
-  element's author.</p>
+  semantics of the element that it extends.</p>
+
+  <p>Any namespace-less attribute, that are relevant to the element's functioning, as determined by
+  the element's author, may be specified on both types of <span data-x="custom element">custom
+  elements</span>, except those that are defined as being <span data-x="obsolete
+  attributes">obsolete</span> for that element, so long as its name is <span>XML-compatible</span>
+  and contains no <span>uppercase ASCII letters</span>.</p>

   <p>A <dfn data-export="">valid custom element name</dfn> is a sequence of characters
   <var>name</var> that meets all of the following requirements:</p>
@@ -111655,7 +111659,8 @@ if (s = prompt('What is your name?')) {

   <h3>Non-conforming features</h3>

-  <p>Elements in the following list are entirely obsolete, and must not be used by authors:</p>
+  <p>Elements in the following list are entirely <dfn data-x="obsolete elements">obsolete</dfn>, and
+  must not be used by authors:</p>

   <dl><!-- alphabetical by first element in the group, except CSS goes last -->

@@ -111736,8 +111741,8 @@ if (s = prompt('What is your name?')) {

   <hr>

-  <p>The following attributes are obsolete (though the elements are still part of the language), and
-  must not be used by authors:</p>
+  <p>The following attributes are <dfn data-x="obsolete attributes">obsolete</dfn> (though the
+  elements are still part of the language), and must not be used by authors:</p>

   <dl><!-- alphabetical by element then attribute of first item in group, except CSS goes last -->

Note: I copied the requirements from embed that the attribute name be lowercase and XML-compatible.

Additional thoughts:

The requirements on element names are similar but are defined differently. Editorial but is a bit inconsistent right now.
Why are any attributes allowed on customized built-in elements? Are they not as problematic for future extensions to the language as any attribute on standard elements?

domenic · 2016-04-13T15:38:24Z

Then remove , except the <code data-x="attr-is">is</code> attribute.

Huh, I didn't notice that. I think it must have been intended to go on autonomous built-in elements; I have no idea how it made it to <html>.

Why are any attributes allowed on customized built-in elements? Are they not as problematic for future extensions to the language as any attribute on standard elements?

That's a good point. Let's leave them invalid for now, and address this in a follow-up issue.

domenic · 2016-04-13T15:56:00Z

@zcorpan please take a look, made a fixup commit for easier reviewing.

zcorpan · 2016-04-13T21:10:02Z

LGTM

This upstreams custom elements into the HTML Standard, instead of having them be in a separate spec that monkeypatches HTML extensively. This builds on previous work in whatwg/dom#204. See https://rawgit.com/w3c/webcomponents/15a203c8393aef0df7223ab1d43406aa11a7e71e/spec/custom/index.html for the source material, in particular the sections labeled "HTML+". Most changes while upstreaming were editorial in nature, with the following exceptions: - Changes were made to the "element interface" section to nail down underspecified edge cases, and fix https://www.w3.org/Bugs/Public/show_bug.cgi?id=27877. - Changes were made to the authoring conformance criteria for attributes on custom elements. A notable change included in this upstreaming is that the order of attributes created by the parser is now well-defined. See WICG/webcomponents#474 for discussion, as well as https://www.w3.org/Bugs/Public/show_bug.cgi?id=17871.

"custom tag" becomes "autonomous custom element", and "type extension" becomes "customized built-in element". Fixes WICG/webcomponents#434.

Fixes WICG/webcomponents#445.

annevk · 2016-04-14T06:16:44Z

\o/

(Do we want to keep this branch alive as we did in DOM?)

domenic · 2016-04-14T13:00:40Z

Yeah, we probably should, and I can also help maintain a similar wiki page.

annevk · 2016-04-14T13:03:48Z

Protected.

Fixes #1015, and matches all non-Gecko engines. Before #1012 the spec was unclear on this; in #1012 the spec sided with Gecko, but per #1015 it is better to side with the majority.

Fixes #1015, and matches all non-Gecko engines. Before #1012 the standard was unclear on this; in #1012 the standard sided with Gecko, but per #1015 it is better to side with the majority.

domenic assigned annevk Apr 7, 2016

domenic added the addition/proposal New features or enhancements label Apr 7, 2016

annevk reviewed Apr 8, 2016
View reviewed changes

domenic reviewed Apr 8, 2016
View reviewed changes

domenic mentioned this pull request Apr 8, 2016

Where is the spec? WICG/webcomponents#481

Closed

domenic force-pushed the customelements branch from 679d17e to d645d1d Compare April 8, 2016 18:07

domenic mentioned this pull request Apr 8, 2016

Element interfaces across browsers #1015

Closed

domenic mentioned this pull request Apr 8, 2016

Rename custom tag WICG/webcomponents#434

Closed

domenic force-pushed the customelements branch from ef3a7c2 to 07b0b3c Compare April 8, 2016 21:25

domenic mentioned this pull request Apr 8, 2016

Permit retrieval of registered classes from window.customElements WICG/webcomponents#445

Closed

annevk reviewed Apr 9, 2016
View reviewed changes

This was referenced Apr 10, 2016

Define "user agent" #1021

Closed

Specify order of attributes for parser-created elements #1035

Closed

annevk force-pushed the customelements branch from 8898ec9 to 1804c62 Compare April 13, 2016 04:42

annevk assigned domenic and unassigned annevk Apr 13, 2016

zcorpan reviewed Apr 13, 2016
View reviewed changes

domenic force-pushed the customelements branch from 1804c62 to 3161de2 Compare April 13, 2016 15:55

domenic assigned zcorpan and unassigned domenic Apr 13, 2016

domenic added 3 commits April 13, 2016 17:27

Rename the types of custom elements

7858636

"custom tag" becomes "autonomous custom element", and "type extension" becomes "customized built-in element". Fixes WICG/webcomponents#434.

Add customElements.get() to retrieve a custom element constructor

1d596a5

Fixes WICG/webcomponents#445.

domenic force-pushed the customelements branch from 3161de2 to 1d596a5 Compare April 13, 2016 21:39

domenic merged commit 1d596a5 into master Apr 13, 2016

domenic mentioned this pull request Apr 20, 2016

Use HTMLPreElement for xmp and listing #1083

Merged

domenic added the topic: custom elements Relates to custom elements (as defined in DOM and HTML) label May 17, 2016

annevk deleted the customelements branch August 18, 2016 10:22

TimvdLippe mentioned this pull request Sep 16, 2018

Clarify status of Web Components standard vuejs/v2.vuejs.org#1795

Merged

Conversation

domenic commented Apr 7, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

annevk commented Apr 8, 2016

Uh oh!

domenic commented Apr 8, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

domenic commented Apr 8, 2016

Uh oh!

domenic commented Apr 8, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

annevk commented Apr 9, 2016

Uh oh!

annevk commented Apr 9, 2016

Uh oh!

domenic commented Apr 9, 2016

Uh oh!

annevk commented Apr 13, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zcorpan commented Apr 13, 2016

Uh oh!

zcorpan commented Apr 13, 2016

Uh oh!

zcorpan commented Apr 13, 2016

Uh oh!

zcorpan commented Apr 13, 2016

Uh oh!

domenic commented Apr 13, 2016

Uh oh!

zcorpan commented Apr 13, 2016

Uh oh!

zcorpan commented Apr 13, 2016

Uh oh!

annevk commented Apr 13, 2016

Uh oh!

domenic commented Apr 13, 2016

Uh oh!

zcorpan commented Apr 13, 2016

Uh oh!

zcorpan commented Apr 13, 2016

Uh oh!

domenic commented Apr 13, 2016

Uh oh!

domenic commented Apr 13, 2016

Uh oh!

zcorpan commented Apr 13, 2016

Uh oh!

annevk commented Apr 14, 2016

Uh oh!

domenic commented Apr 14, 2016

Uh oh!

annevk commented Apr 14, 2016

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants