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> 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> 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
>
>
>
>