Re: Custom Elements: is=""

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

This doesn't work, the parser needs to allocate the right C++ object
associated with the tag name. There's no way to do upgrades if we allow you
register any tag name you want. It was also disliked by Hixie because it
encourages using up the namespace so then the spec would need to invent
weirder names to work around ones that were already in wide spread use.


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

I think this should probably throw if you inherit from the wrong thing.

- E