Hacker News Reader

Comment by callahad | Hacker News Reader

The combination of Custom Elements and Shadow DOM allow you to create a separate, semantic representation of your markup that you can script against, while encapsulating the actual markup required for presentation.

E.g., imagine you wanted to select all the images in a carousel. Without Shadow DOM, something like document.querySelectorAll('.carousel img') might pick up images being used as implementation details, like left/right button images, in addition to the carousel images themselves. With Custom Elements and Shadow DOM, your markup could contain only the content you intend to represent, and document.querySelectorAll('.carousel img') would return just the images being shown in the carousel.

Of course, like image carousels, whether or not this is a good idea is subjective. But it does give you additional functionality. Hopefully we'll learn how to use it responsibly.

View on HN

Wait, what? You just described the benefits of Shadow DOM. Shadow DOM has benefits, but you could get those benefits without Custom Elements, right?

What can I do with Custom Elements + Shadow DOM that I can't do with Shadow DOM alone?

Distribute a widget that others can use, or that you can use more easily in other contexts.

What? You can distribute widgets with JavaScript (and Custom Elements require JS). So what was the benefit, again?

This one is easier and more universal than the other approaches. There's not setup involved like:

   $("#foo").myWidget();

You just put the markup on the page and include the JavaScript:

  <my-widget></my-widget>

And of course, you could do querySelector before that existed but that doesn't mean there wasn't benefit to it being native.

You can create reusable UI widgets that are usable without the user knowing how they were written. e.g. with today's frameworks you need to know how to create widget, and that may involve rolling up your sleeves and diving into a bunch of framework-specific concepts. With custom elements you could just have your server emit an <image-carousel> element, or do document.createElement('image-carousel').

This is good for ease of use, but it's also great for interop. Custom elements work with every way of writing a web site because every way of writing a web site can deal with elements.

But in reality, the server would have to emit

  <image-carousel delay="10" images="['...', '...']" end-behavior="cycle">

Thus making us no more free from the details of the component than we were before.

> no more free from the details

i suppose it depends on what you mean by "the details."

details can be just the inputs required by "the interface" or it can be specifics of "the implementation". the purpose of an interface is often to distance (perhaps even "free", depending) the user from the implementation.

Parameters aren't implementation details.

Implementation details are stuff like "It's written in framework X so you need to call that framework's init method after document load, then do frameworkX.initCarousel(document.querySelectorAll('.image-carousel')).onEnd((carousel) => carousel.cycle())".

I suppose the ship has sailed a while ago on this, considering various projects I've had over the last couple years but:

You can create reusable UI widgets that are usable without the user knowing how they were written with an element like <div class="FrameworkName_imageCarousel" ...> also, and your client library handles FrameworkName_imageCarousel without you needing to know how that is done.

I guess where document.createElement is concerned you might need to do framework.create('image-carousel'); or something similar, but I suspect if you are programmatically creating your custom elements you are probably also going to have to do more with them than just create them, and at that point you are going to need to know what code you are expected to call to do whatever things you want to do.

When you say it's also great for interop I worry we have a different definition of interop - I don't call it interop when my way of writing a web site can deal with elements, I call it interop when other people's ways of consuming websites can deal with elements and I have a hard time to understand how interop is going to be great for consumption of non-standardized elements (robots etc. included under other people's ways of consuming websites)

My feeling is really that a benefit to this that does not seem to get discussed is the ability to limit 'interop' that the solution builder does not explicitly control with its implementation (except where the big players are concerned, who have the resources to overcome piddling limits like these). So no more easy crawler solutions, you want to deal with crawling our site and you're not google? Well you will have to reverse engineer our <asio-link> element and figure out how it works to crawl it.

Even if you automate a browser you still have to have code to click on asio-links to get the script implementing that element to run!

But like I say that ship has pretty much sailed anyway, this kind of thing just officially validates the direction the ship is headed. (and I'm not happy about the direction)

> You can create reusable UI widgets that are usable without the user knowing how they were written with an element like > <div class="FrameworkName_imageCarousel" ...> also, and your > client library handles FrameworkName_imageCarousel without you needing to know how that is done.

With all frameworks I know of, this won't work for elements dynamically added to the DOM after the start of your application. Not only document.createElement, but even if you insert chunks of markup using innerHTML or the like.

Sometimes there is a framework-specific call to do the right thing, but then you're back to needing to know how an element is implemented.

For Custom Elements, it really is as simple as just inserting them. You don't have to run any script code to make them do what they do.

Ok thanks, now I see a benefit - not sure if I consider it enough of a benefit for creating what I would consider to be awful interop problems but I can see a benefit.

I get that use case, but is a slightly shorter query selector a good trade-off in exchange for introducing syntax that crawlers, screen readers, and other non-browser HTTP clients can't deal with?

Also, I don't know about the semantic markup bit. "Semantic" markup (whatever that is) was the idea already when CSS was introduced. Now we need Shadow DOM, ie. additional markup, to make CSS manageable, which seems odd to me.

The "semantics" of HTML is really just that it's a structured document format with paragraphs, headers, lists, links, and a couple other idioms with a more or less tightly controlled inner structure. Next to these, custom elements seem out of place, and more like a general mechanism for page composition.

As such, they're bound to evolve over time. For example, for web components it's not difficult to imagine that a "container" component (for aggregation of other components, say a tab control as a trivial example) would be a useful thing to have. But then this calls for a way to place web components into the child content of other content, something which I understand isn't possible right now. Basically, we're looking into a long journey to morph HTML into something else here.

This is possible today using slots.

Reply on news.ycombinator.com