9 ms·

What's the point in introducing another syntactical feature to HTML (the markup language) when you need Javascript for it anyway? When you're already using Java

What's the point in introducing another syntactical feature to HTML (the markup language) when you need Javascript for it anyway? When you're already using Javascript, custom elements don't add any essential functionality. Their inclusion as a feature into HTML feels like a not-so-well thought-out decision from a language design PoV.

callahad 10y ago
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.
gambler 10y ago
My sentiment exactly. The thing they show in "live demo" can be done using existing DOM APIs, with less code. Shadow DOM seems useful as far as isolation of styling is concerned, but it's really weird that it's not part of normal CSS spec. CSS in general needs some form of isolation. People resort to stuff like BEM to work around its absence.
cdata 10y ago
Custom Elements (also Shadow DOM) is a low level API that helps explain how an author can define elements that have aesthetic and functional parity with built-in HTML elements. Custom Elements provides a lot of useful features, including: compatibility with "native" DOM APIs (e.g., appendChild); lifecycle callbacks (e.g., notification of being attached or detached); consistent timing for content distribution; the ability to "lazily" upgrade in place. These features are generally useful regardless of the type of framework or style you may wish to use to write a component. They form a common baseline that moves the web towards a place where components (simply HTML custom elements) authored by different people do not need to be aware of each other's finer implementation details in order to be interoperable.
- gambler 10y ago
  Could you provide some specific example of something that can be easily done with custom elements that cannot be easily done with other existing APIs? (I'm speaking about user-facing stuff, not some implementation detail.) Edit: Here is my quick re-implementation of their example using today's APIs: https://jsfiddle.net/pd0na425/3/ https://jsfiddle.net/pd0na425/3/ The HTML instantiation uses a single tag, just like theirs. Fully reusable. Works in all modern browsers. I believe is uses less code too.
  - elcritch 10y ago
    I'm using it to build wrappers around d3-based graphs to make it easy for non-software engineers (mechanical, electrical), to create and modify simple PID controls. There's PLC programs and interfaces but by and large they're klunky, aren't customizable, or require learning something g like LabView. The custom elements help specifically by encapsulating the (somewhat tedious) d3 graphing and controls connections into simple HTML objects with a simple spec the engineers can lookup. HTML is then declarative and easy for non-programmers to try, test and see immediate feedback. This works out well for creating functional controls systems which can then be cleaned up by experienced developers who can tune the underlying web components. JavaScript libraries all require much more knowledge and generally don't "scale" when you want to add several graphs quickly. Frameworks like Angular2, Vie, or React all require significant learning curve and understanding of the framework generally to get working. Though Vue seems to be the simplest, but web components provide an API which Vue et al can build on by encapsulating more complex HTML/CSS/JS into semi-hidden sub-trees.
tomatsu 10y ago
I'd say the big idea is to make using and reusing of those elements more declarative. With the Shadow DOM, you can also hide all the internal clutter, which is extremely convenient if you use some widget in many different places. It's true that you can achieve something similar with templates (or partials), but those are tied to a specific platform or stack. The <template> tag is also quite neat since the (inert) subtree is created immediately and then cloned when instantiated. This is quite a bit faster than creating HTML strings which are then parsed and finally turned into elements.

callahad 10y ago

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.

gambler 10y ago

My sentiment exactly. The thing they show in "live demo" can be done using existing DOM APIs, with less code. Shadow DOM seems useful as far as isolation of styling is concerned, but it's really weird that it's not part of normal CSS spec. CSS in general needs some form of isolation. People resort to stuff like BEM to work around its absence.

cdata 10y ago

Custom Elements (also Shadow DOM) is a low level API that helps explain how an author can define elements that have aesthetic and functional parity with built-in HTML elements. Custom Elements provides a lot of useful features, including: compatibility with "native" DOM APIs (e.g., appendChild); lifecycle callbacks (e.g., notification of being attached or detached); consistent timing for content distribution; the ability to "lazily" upgrade in place. These features are generally useful regardless of the type of framework or style you may wish to use to write a component. They form a common baseline that moves the web towards a place where components (simply HTML custom elements) authored by different people do not need to be aware of each other's finer implementation details in order to be interoperable.

gambler 10y ago
Could you provide some specific example of something that can be easily done with custom elements that cannot be easily done with other existing APIs? (I'm speaking about user-facing stuff, not some implementation detail.) Edit: Here is my quick re-implementation of their example using today's APIs: https://jsfiddle.net/pd0na425/3/ https://jsfiddle.net/pd0na425/3/ The HTML instantiation uses a single tag, just like theirs. Fully reusable. Works in all modern browsers. I believe is uses less code too.
- elcritch 10y ago
  I'm using it to build wrappers around d3-based graphs to make it easy for non-software engineers (mechanical, electrical), to create and modify simple PID controls. There's PLC programs and interfaces but by and large they're klunky, aren't customizable, or require learning something g like LabView. The custom elements help specifically by encapsulating the (somewhat tedious) d3 graphing and controls connections into simple HTML objects with a simple spec the engineers can lookup. HTML is then declarative and easy for non-programmers to try, test and see immediate feedback. This works out well for creating functional controls systems which can then be cleaned up by experienced developers who can tune the underlying web components. JavaScript libraries all require much more knowledge and generally don't "scale" when you want to add several graphs quickly. Frameworks like Angular2, Vie, or React all require significant learning curve and understanding of the framework generally to get working. Though Vue seems to be the simplest, but web components provide an API which Vue et al can build on by encapsulating more complex HTML/CSS/JS into semi-hidden sub-trees.

tomatsu 10y ago

I'd say the big idea is to make using and reusing of those elements more declarative. With the Shadow DOM, you can also hide all the internal clutter, which is extremely convenient if you use some widget in many different places. It's true that you can achieve something similar with templates (or partials), but those are tied to a specific platform or stack. The <template> tag is also quite neat since the (inert) subtree is created immediately and then cloned when instantiated. This is quite a bit faster than creating HTML strings which are then parsed and finally turned into elements.