[custom-elements]

We're building commercial apps with the emerging custom elements standard.
We love the approach, and think that custom elements are a wonderful
productivity tool, and reduce the "div soup" we are tired of!

I noticed in Custom Elements W3C Working Draft 13 October 2016, Section 2.4
The CustomElementRegistry interface, paragraph #14 under Element definition
a detail that caught me by surprise:

Let upgrade candidates be all elements that are shadow-including descendants
<https://dom.spec.whatwg.org/#concept-shadow-including-descendant> of
document, whose namespace is the HTML namespace
<https://html.spec.whatwg.org/multipage/infrastructure.html#html-namespace-2>
and
whose local name is localName, in shadow-including tree order
<https://dom.spec.whatwg.org/#concept-shadow-including-tree-order>.
Additionally, if extends is non-null, only include elements whose is value
<https://www.w3.org/TR/custom-elements/#concept-element-is-value> is equal
to name.

What surprised me is that I would have thought a custom element with only
"light DOM" children would also qualify as an "upgrade candidate".  Does
this paragraph imply that the *only* custom elements that will be upgraded
are those that have a shadow root?   I'm thinking that is, perhaps, overly
specified?

(We need such custom elements here and now because polyfills and our
hospital customers running IE11.)

If it indeed expresses a hard requirement, then it would appear to
contradict section 2.2 Requirements for custom element constructors:

In general, the constructor should be used to set up initial state and
default values, and to set up event listeners and possibly a shadow root
<https://dom.spec.whatwg.org/#concept-shadow-root>.

If the constructor only "possibly" sets up a shadow root, then there's a
custom element lacking a shadow root, and thus isn't an upgrade candidate?!?

Any clarification would be much appreciated!  Thank you again for the great
work making the browser dev environment much better!

Best,
Jeff Robbins
jeffr@livedata.com
www.livedata.com

Received on Monday, 11 September 2017 14:03:47 UTC