6 ms·

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-i

by 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.
- om2 10y ago
  Your example has many serious limitations: (1) It doesn't let you have multiple progress bars that all advance at their own rate. (2) It doesn't work at all for custom-progress-bar elements added dynamically to the document after the timers for the first progress bar finish. (3) It makes the children of <custom-progress-bar> actually appear in the DOM, which means that code generically walking the DOM will see them and might mess them up. The basic thing that the combo of Shadow DOM + Custom Elements provides is encapsulation. You can make standalone elements that operate themselves, work just like normal elements, handle attributes and children, and start by themselves. Anything done using encapsulation can be done without encapsulation, in a sense. What encapsulation provides is better organization for your program, and more elegant and understandable code at the point of use.
  - gambler 10y ago
    > (1) It doesn't let you have multiple progress bars that all advance at their own rate. It does. > (2) It doesn't work at all for custom-progress-bar elements added dynamically to the document after the timers for the first progress bar finish. It does. I think you're confusing the "library" code with the "user-land" code that drives it (the latter was copied from the example in the original article). Here is a version with two progress bars where I separated the "library" into a separate box: https://jsfiddle.net/pd0na425/4/ https://jsfiddle.net/pd0na425/4/ (3) It makes the children of <custom-progress-bar> actually appear in the DOM, which means that code generically walking the DOM will see them and might mess them up. This part is true. However, if you have code that generically walks the DOM and screws stuff up, how do you expect your website to operate anyway? The real issue is overly broad CSS selectors, and it's not really something specific to custom elements. Everyone has to deal with it for all CSS and all elements. In this case, it's actually easy to mitigate. Since all the inner elements are custom, I can easily add a prefix that will effectively prevent them from being styled by other libraries. That said, I wish W3C actually solved CSS scoping properly. That would be way, way more useful than any component API and it would be useful for every website in that uses styling.
    - ricardobeat 10y ago
      The CSS in a web component is scoped.
erikpukinskis 10y ago
Seems very Java-y to me. Like a Everything Inherits From Element kind of philosophy. Historically, one of the core values of browser design is to just provide the minimum possible hooks to access functionality, and to let library authors experiment widely with different APIs and interfaces on top of that. That's why there is so much innovation in things like application lifecycle, layout engines, look-and-feel, etc, on the web. I mean, I get the idea: you can define these custom elements, and then have a bunch of "raw" HTML files that don't use JavaScript and have access to this advanced widgetry. But boy, that's adding a weird layer of confusion. Now those files are "HTML"ish, but can't actually render without this other JavaScript going on. You sacrifice a clear definition of what HTML is. It reminds me of ES6 actually... everyone rushed to add all of this syntactic sugar and comfort features to the language, but now there is no definition of JavaScript anymore. It's just some vague container for some set of possible language properties that may or may not be available on various platforms. I think people underestimate how powerful the web philosophy of "just add the basics, and let people build powerful inferfaces in the application layer" is. We have Rubyists and other folks from pro-oriented languages coming in and trying to turn HTML+JavaScript into a professional programming environment, with all of the chaos and insanity that comes along with that: versioning, build systems, package management, etc. They really don't understand the power of having a single runtime that works everywhere and doesn't do much. Separation of concerns is powerful, and the simplicity of the browser runtime I think provides a helpful constraint which is worth the frustration. The Ember people are near the heart of it. They recently dropped support for Node, making a hard fork where they're only supporting IO.js developers now (franchise naming rights aside). But that attitude is everywhere now. The React crowd is all-in on transpilation. The Webpack people have ditched the idea that there should be some observable relationship between what's in the browser and what's on the filesystem. I don't know. I guess I'm just sad that the JavaScript+HTML community have been taken over by people who don't really seem to like JavaScript+HTML much. And not enough time has passed for those of us who actually like the web to start our equivalent of record stores and classic car clubs. Old man rant over I suppose.
- rtpg 10y ago
  The logical extreme of your argument is to make everything a `div` with classes. While possible, the main issue with that model is that it provides no encapsulation strategy. Encapsulation is one of the core tools for programmers for building complex programs, so having first class support for that in the templating language suddenly makes a lot of things easier. Without encapsulation, a lot of things become more frustrating. Event bubbling has to be micro-managed. Dev tools are less useful. It becomes even more frustrating to deal with conflicting CSS IDs. Steele's Growing A Language[0] talk specifically points to encapsulation as the core building blog for programs. Given how HTML is used nowadays (React + Angular are both "HTML as program layouts" models), not having encapsulation is a crutch [0]: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0

by cdata 10y ago

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.
om2 10y ago
Your example has many serious limitations: (1) It doesn't let you have multiple progress bars that all advance at their own rate. (2) It doesn't work at all for custom-progress-bar elements added dynamically to the document after the timers for the first progress bar finish. (3) It makes the children of <custom-progress-bar> actually appear in the DOM, which means that code generically walking the DOM will see them and might mess them up. The basic thing that the combo of Shadow DOM + Custom Elements provides is encapsulation. You can make standalone elements that operate themselves, work just like normal elements, handle attributes and children, and start by themselves. Anything done using encapsulation can be done without encapsulation, in a sense. What encapsulation provides is better organization for your program, and more elegant and understandable code at the point of use.
- gambler 10y ago
  > (1) It doesn't let you have multiple progress bars that all advance at their own rate. It does. > (2) It doesn't work at all for custom-progress-bar elements added dynamically to the document after the timers for the first progress bar finish. It does. I think you're confusing the "library" code with the "user-land" code that drives it (the latter was copied from the example in the original article). Here is a version with two progress bars where I separated the "library" into a separate box: https://jsfiddle.net/pd0na425/4/ https://jsfiddle.net/pd0na425/4/ (3) It makes the children of <custom-progress-bar> actually appear in the DOM, which means that code generically walking the DOM will see them and might mess them up. This part is true. However, if you have code that generically walks the DOM and screws stuff up, how do you expect your website to operate anyway? The real issue is overly broad CSS selectors, and it's not really something specific to custom elements. Everyone has to deal with it for all CSS and all elements. In this case, it's actually easy to mitigate. Since all the inner elements are custom, I can easily add a prefix that will effectively prevent them from being styled by other libraries. That said, I wish W3C actually solved CSS scoping properly. That would be way, way more useful than any component API and it would be useful for every website in that uses styling.
  - ricardobeat 10y ago
    The CSS in a web component is scoped.

erikpukinskis 10y ago

Seems very Java-y to me. Like a Everything Inherits From Element kind of philosophy. Historically, one of the core values of browser design is to just provide the minimum possible hooks to access functionality, and to let library authors experiment widely with different APIs and interfaces on top of that. That's why there is so much innovation in things like application lifecycle, layout engines, look-and-feel, etc, on the web. I mean, I get the idea: you can define these custom elements, and then have a bunch of "raw" HTML files that don't use JavaScript and have access to this advanced widgetry. But boy, that's adding a weird layer of confusion. Now those files are "HTML"ish, but can't actually render without this other JavaScript going on. You sacrifice a clear definition of what HTML is. It reminds me of ES6 actually... everyone rushed to add all of this syntactic sugar and comfort features to the language, but now there is no definition of JavaScript anymore. It's just some vague container for some set of possible language properties that may or may not be available on various platforms. I think people underestimate how powerful the web philosophy of "just add the basics, and let people build powerful inferfaces in the application layer" is. We have Rubyists and other folks from pro-oriented languages coming in and trying to turn HTML+JavaScript into a professional programming environment, with all of the chaos and insanity that comes along with that: versioning, build systems, package management, etc. They really don't understand the power of having a single runtime that works everywhere and doesn't do much. Separation of concerns is powerful, and the simplicity of the browser runtime I think provides a helpful constraint which is worth the frustration. The Ember people are near the heart of it. They recently dropped support for Node, making a hard fork where they're only supporting IO.js developers now (franchise naming rights aside). But that attitude is everywhere now. The React crowd is all-in on transpilation. The Webpack people have ditched the idea that there should be some observable relationship between what's in the browser and what's on the filesystem. I don't know. I guess I'm just sad that the JavaScript+HTML community have been taken over by people who don't really seem to like JavaScript+HTML much. And not enough time has passed for those of us who actually like the web to start our equivalent of record stores and classic car clubs. Old man rant over I suppose.

rtpg 10y ago
The logical extreme of your argument is to make everything a `div` with classes. While possible, the main issue with that model is that it provides no encapsulation strategy. Encapsulation is one of the core tools for programmers for building complex programs, so having first class support for that in the templating language suddenly makes a lot of things easier. Without encapsulation, a lot of things become more frustrating. Event bubbling has to be micro-managed. Dev tools are less useful. It becomes even more frustrating to deal with conflicting CSS IDs. Steele's Growing A Language[0] talk specifically points to encapsulation as the core building blog for programs. Given how HTML is used nowadays (React + Angular are both "HTML as program layouts" models), not having encapsulation is a crutch [0]: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0