
I is=“the walrus” - robin_reala
https://bkardell.com/blog/TheWalrus.html
======
phreack
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.

~~~
scoot
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...](https://stackoverflow.com/questions/27434431/what-is-html-is-
attribute)

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

------
jameskegel
Title needs to be reworked please.

------
msla
The title is offensive. Flagged.

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

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

------
msla
The title is nonsensical.

~~~
d0lph
Well, yes, it is.
[https://en.wikipedia.org/wiki/I_Am_the_Walrus](https://en.wikipedia.org/wiki/I_Am_the_Walrus)

~~~
msla
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.

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

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

