This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See https://wiki.whatwg.org/wiki/Custom_Elements#Subclassing_existing_elements Subclassing existing elements is hard as implementation-wise identity is both object-based and name / namespace based. Therefore subclassing an existing element (currently) requires that the name / namespace does not change. See also DOM: element constructors. A hack was invented to make this work: <button is="my-button">. That hack is not well liked leaving us two options: We leave this for now and work on this in parallel while stabilizing a smaller subset of custom elements. We block on this and delay even more. (Assuming that not all implementers are suddenly going to be okay with this hack.) However, without this hack accessibility for trivial components is harder as more things have to be done by hand. Another use case had emerged for the "is" hack: piggy-backing on parser behaviors. For example, extending <template> for data binding or as a way to specify shadow trees in HTML.
Please don't kill this. The fact that it's important to provide accessibility features is one aspect of why this is important and useful. The other aspect (and that's something that has actually bitten me in a live scenario) is defensiveness and progressive enhancement. I'd like to give an example of what happened to me, hurt my users and left me feel like an idiot for not using "is" extension. I wrote a component that wrapped Ace-Editor to provide syntax-highlighted code editing textareas. However, being not fully aware of the power behind the extension features, I built my component from scratch, using the textarea prototype, so <code-editor></code-editor> instead of <textarea is="code-editor"></textarea> That worked nice, until I had a shaky mobile connection and the javascript didn't fully load. it left me with an unusable application. unfortunately it was not me finding this first, instead a bunch of people who use the internal tool were left with something that didn't work right when the connection was wonky or some other script had a parsing problem that prevented registration of the component. I quickly rectified the situation by correctly extending from a textarea, so the old fashioned Form submit action could be edited and POSTed, even when all the lovely enhancements that we are using (relying on Javascript) fail. Unless provided with a similar, internally less hacky, solution this should not be taken away from Web components. I think it's a fundamental trait of the web platform to be resilient and making Web components depend on javascript is harmful to this trait. Arguably we could leave it up to developers to provide those fullbacks outside of Web components, but that's making "doing the right thing" harder, which IMHO isn't a good idea either.
The right fallback mechanism for web components is to use compostion as done in video, embed, object, and numerous other HTML elements. e.g. <code-editor><textarea></textarea></code-editor>
(In reply to Ryosuke Niwa from comment #2) > The right fallback mechanism for web components is to use compostion as done > in video, embed, object, and numerous other HTML elements. > > e.g. > <code-editor><textarea></textarea></code-editor> Good point and definitely worth considering in this scenario, but it puts additional effort on the author using the component as they would have to always supply this nested element while the is-mechanism works without an additional level of content. At least that's what I feel when seeing this example. Video, Embed, Object and Canvas provide alternative content in case one type of content isn't available. The code-editor on the other hand enhances a feature that is a part of the platform, the textarea. I as an author prefer the extension mechanism over the composition. Plus I am not entirely sure how that works with the accessibility affordances I would have on a browser that does support the component. would I still have to deal with ARIA and all of the things I'm getting "for free" with the extension?
(In reply to Martin Naumann from comment #3) > > Plus I am not entirely sure how that works with the accessibility > affordances I would have on a browser that does support the component. would > I still have to deal with ARIA and all of the things I'm getting "for free" > with the extension? A lot of people are making this argument but that's simply not true. UAs can't make subclassed elements more accessible automatically.
Moved to https://github.com/w3c/webcomponents/issues/133