I criticized the reversal on "is" just yesterday, so that was awkward [1]. Since this is on the internet, I must defend my position. I believe it is a major blo

I criticized the reversal on "is" just yesterday, so that was awkward [1]. Since this is on the internet, I must defend my position. I believe it is a major blow to the usefulness of Custom Elements simply because developers will not follow the advice and do this: <x-radio> <input type="radio"/> </x-radio> They will instead dump that nested HTML structure into the Shadow DOM and present a single element, because that is how they always imagined it and that is how it works in other "taglib" implementations. <x-radio/> This is bad for usability and accessibility and interoperability and so on, but it is really their problem. The "is" attribute would come in handy, of course, if it was still on the drawing board. <input type="radio" is="x-radio"> Well, it is of course also the users problem, since they are the first to notice usability problems. Our developers have for example still not fixed our links: <span ng-click="loadindex()">Go to the front page<span> But anyways: The real problem comes when they realize that this approach is problematic and go down the "composition" road as suggested in the article, because it is not possible to reason about DOM structure in modern day frameworks where the Custom Element is eventually bound to be used; and that is both the premise and the promise of Web Components, that they "compose" well with other frameworks. In order for the `x-radio` implementation to get an angle on the `input` element, either to style it or validate it, it must make use of overengineering to navigate the quantum soup of DOM updates that "incremental rendering" and suspect techniques have stirred up. 1. Find it via `querySelector` when the Custom Element is attached, to see if the framework has rendered it already, and 2. Setup a MutationObserver to anticipate that it might be added later and/or replaced spontanously at any point in time One should of course never assign a reference `this._input` to the input, since there is no guarantee that it still exists (on the page) when you need it. Of course, the component author doesn't know about this, since it doesn't pose the same problem when you "use the platform" and don't rely on frameworks. But eventually he will learn that the only way to keep your component safe is to render it in the Shadow DOM, and that is indeed why it exist, but now we are back where we started. Form elements really don't work in the Shadow DOM (`document.activeElement` is always null, for example, so someone is bound to steal your focus) and you will eventually begin to remember that this was never a problem React components or Angular directives, which even support the same syntax: <x-radio> <input type="radio"/> </x-radio> They even support the "is" syntax! <input type="radio" x-radio/> In fact, with only one single, top level MutationObserver plus one initial TreeWalker I can implement ad-hoc support for the "is" syntax to style and validate the input as soon as it is found on the page, either declaratively in the markup or when React decides to inject it. I would not be using Custom Elements, but it will work nonetheless without any of these theoretical problems or paradoxes, or I can use something like Sentinel.js to implement it [2]. And that is really a shame, because I would like to use Custom Elements and I am otherwise usually found in the supporting role for this specification. [1] https://news.ycombinator.com/item?id=15797228#15798459 https://news.ycombinator.com/item?id=15797228#15798459 [2] https://www.npmjs.com/package/sentinel-js https://www.npmjs.com/package/sentinel-js