20 ms·

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 enca

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.

deleted 10y ago
[deleted]
dfabulich 10y ago
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?
- Touche 10y ago
  Distribute a widget that others can use, or that you can use more easily in other contexts.
  - dfabulich 10y ago
    What? You can distribute widgets with JavaScript (and Custom Elements require JS). So what was the benefit, again?
    - Touche 10y ago
      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.
- rictic 10y ago
  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.
  - jessedhillon 10y ago
    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.
    - abiox 10y ago
      > 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.
    - rictic 10y ago
      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())".
  - bryanrasmussen 10y ago
    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)
tannhaeuser 10y ago
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.
- bradleyayers 10y ago
  This is possible today using slots.

deleted 10y ago

[deleted]

dfabulich 10y ago

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?

Touche 10y ago
Distribute a widget that others can use, or that you can use more easily in other contexts.
- dfabulich 10y ago
  What? You can distribute widgets with JavaScript (and Custom Elements require JS). So what was the benefit, again?
  - Touche 10y ago
    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.
rictic 10y ago
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.
- jessedhillon 10y ago
  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.
  - abiox 10y ago
    > 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.
  - rictic 10y ago
    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())".
- bryanrasmussen 10y ago
  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)

tannhaeuser 10y ago

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.

bradleyayers 10y ago
This is possible today using slots.