Whew, I found this piece to be quite confusing to read, requiring lots of knowledge of discussions and unrelated trivia that I hadn't come across before. Maybe the author should try to explain his examples a bit more in detail for the rest of us next time.

Yes, you need to know what is is. I didn't but found the second last explanation here helpful: https://stackoverflow.com/questions/27434431/what-is-html-is...

On the other hand, HN has become a little boring recently, with everything fed to the user via titles. There's a place for playfully obscure, and the author isn't writing for HN anyway. They can write whatever they want.

The pictures were fun, though.

As always, depending on what the definition of "is" is.

Title needs to be reworked please.

The title is offensive. Flagged.

Why? English is not my first language, I only got the Beatles reference.

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

[2] https://www.npmjs.com/package/sentinel-js

The title is nonsensical.

Well, yes, it is. https://en.wikipedia.org/wiki/I_Am_the_Walrus

I get the reference. It simply has no relevance to the topic, and gives people no reason to read the piece.

In fact, it actively detracts from the piece, by forcing people to focus on it instead of the supposed content.

It's like clickbait, only less successful.

No relevance to the topic? The title is: `<i is="the walrus">`, the topic is the usage and implementation of the `is=""` HTML attribute which is mentioned in the second sentence of the article. The lede isn't exactly buried

No, the title is 'I is="the walrus"', which lacks the angle brackets and, therefore, any hint it has anything to do with HTML.