RE: Custom Elements: is=""

Yes, I think you are understanding correctly, and it appears this would be a side-effect ☺. You have the same problem with two implementations of x-button though the pool of custom element names is going to be larger.

Do you think this will be a problem in practice?

From: Justin Fagnani [mailto:justinfagnani@google.com]
Sent: Friday, May 8, 2015 1:06 PM
To: Travis Leithead
Cc: Ryosuke Niwa; Anne van Kesteren; WebApps WG
Subject: Re: Custom Elements: is=""

If I'm understanding your proposal correctly, wouldn't this limit any document to have a single subclass per native element?

How would you express:

<button is="my-fancy-button">Me</button>
<button is="your-fancy-button">You</button>

-Justin

On Fri, May 8, 2015 at 12:56 PM, Travis Leithead <travis.leithead@microsoft.com<mailto:travis.leithead@microsoft.com>> wrote:
The 'is' attribute is only a declarative marker; it's the indicator that the native element has a [potential] custom prototype and hierarchy, right?

I don't mean to drudge up past history and decisions already laid to rest, but if subclassing native elements is a good compromise until we get to the underlying behaviors that make up native HTML elements, why should we limit registerElement to hyphenated custom element names?

In other words, why not simplify by:
1. Allow any localName to be used by registerElement. (This would imply the HTML namespace by default; we can later add registerElementNS if needed :)
2.  Drop the 'extends' member from the ElementRegistrationOptions dictionary.

With this simplification, serializing elements wouldn't include any sign that they are 'customized' in any way (as is done with 'is' today). I don't see this as a problem, since web devs today can already do this, but without the help of the parser.

It always seemed weird to me that 'prototype' of ElementRegistrationOptions can inherit from anything (including null), and be completely disassociated from the localName provided in 'extends'.

If we drop support for 'is' in v1, then we can consider later bringing back subclassing in v2 without introducing 'extends' in the ElementRegistrationOptions or the 'is' attribute.

If we opt to keep the feature, I'd like to see it simplified as described above.

(In general: I'd also like to see a 'constructor' property added automatically to the prototype so that you can always get to the native constructor function from script even if you don't save the return value of registerElement.)


> On May 6, 2015, at 6:25 AM, Anne van Kesteren <annevk@annevk.nl<mailto:annevk@annevk.nl>> wrote:
>
> Open issues are kept track of here:
>
>  https://wiki.whatwg.org/wiki/Custom_Elements

>
> I think we reached rough consensus at the Extensible Web Summit that
> is="" does not do much, even for accessibility. Accessibility is
> something we need to tackle low-level by figuring out how builtin
> elements work:
>
>  https://github.com/domenic/html-as-custom-elements

>
> And we need to tackle it high-level by making it easier to style
> builtin elements:
>
>  http://dev.w3.org/csswg/css-forms/

>
> And if the parser functionality provided by is="" is of great value,
> we should consider parsing elements with a hyphen in them differently.
> Similar to how <script> and <template> are allowed pretty much
> everywhere.
>
> Therefore, I propose that we move subclassing of builtin elements to
> v2, remove is="" from the specification, and potentially open an issue
> on HTML parser changes.

We (Apple) support this proposal.

- R. Niwa