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:justinfagn...@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.leith...@microsoft.com<mailto:travis.leith...@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 
> <ann...@annevk.nl<mailto:ann...@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



Reply via email to