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