5 ms·

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 f

by 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.
- om2 10y ago
  You've solved one set of problems (and fixed the major problem that the original had no separation between library and user land code) and created some new problems: (1) A timer will fire forever, even if no progress bars are currently updating. Bye bye, battery life! (2) A progress bar can't update at 60fps, even if changes to the underlying value happen that quickly. IF you continue playing whack-a-mole with these types of problems, you might see why Custom Elements + Shadow DOM are an elegant way to avoid these issues while providing good encapsulation. (As someone else mentioned, Shadow DOM provides style scoping so it doesn't have the CSS issue you raised, even if the contents are normal built-in elements, while your example does.) I hope this helps to clarify what Web Components technologies are good for.
  - gambler 10y ago
    >You've solved one set of problems (and fixed the major problem that the original had no separation between library and user land code) My original followed the structure outlined in the article's example. It runs the exact same library code as the second link. I did not "fix" anything, since nothing was broken in the first place. I simply split it for clarity. > A timer will fire forever, even if no progress bars are currently updating. Bye bye, battery life! You claim regarding battery life is unsubstantiated. Simple timers like that take up very little processor time as long as you don't do superfluous DOM updates in every invocation. > A progress bar can't update at 60fps, even if changes to the underlying value happen that quickly. Firstly, it can. If you set the timer to 16ms and there is nothing else loading up the browser engine. Secondly, if you think that your typical events always updates the page graphics at 60FPS, you are mistaken. But most importantly, you really don't want to update a control like this 60 times per second, because you would be wasting CPU cycles on re-calculating values that no human will ever notice.
    - om2 10y ago
spankalee 10y ago
So you have to run a querySelectorAll() across the whole document every time you want to update/upgrade your elements? That's not going to scale at all.
- gambler 10y ago
  You should actually try it before making such statements. It scales well enough. Also, we could use getElementsByTagName instead of querySelectorAll. But that's not important. The point is that there are approaches to handling "components" with current APIs. They are simple, they work across all browsers right now and they are good enough for 99% of websites out there.

by om2 10y ago

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.
om2 10y ago
You've solved one set of problems (and fixed the major problem that the original had no separation between library and user land code) and created some new problems: (1) A timer will fire forever, even if no progress bars are currently updating. Bye bye, battery life! (2) A progress bar can't update at 60fps, even if changes to the underlying value happen that quickly. IF you continue playing whack-a-mole with these types of problems, you might see why Custom Elements + Shadow DOM are an elegant way to avoid these issues while providing good encapsulation. (As someone else mentioned, Shadow DOM provides style scoping so it doesn't have the CSS issue you raised, even if the contents are normal built-in elements, while your example does.) I hope this helps to clarify what Web Components technologies are good for.
- gambler 10y ago
  >You've solved one set of problems (and fixed the major problem that the original had no separation between library and user land code) My original followed the structure outlined in the article's example. It runs the exact same library code as the second link. I did not "fix" anything, since nothing was broken in the first place. I simply split it for clarity. > A timer will fire forever, even if no progress bars are currently updating. Bye bye, battery life! You claim regarding battery life is unsubstantiated. Simple timers like that take up very little processor time as long as you don't do superfluous DOM updates in every invocation. > A progress bar can't update at 60fps, even if changes to the underlying value happen that quickly. Firstly, it can. If you set the timer to 16ms and there is nothing else loading up the browser engine. Secondly, if you think that your typical events always updates the page graphics at 60FPS, you are mistaken. But most importantly, you really don't want to update a control like this 60 times per second, because you would be wasting CPU cycles on re-calculating values that no human will ever notice.
  - om2 10y ago

spankalee 10y ago

So you have to run a querySelectorAll() across the whole document every time you want to update/upgrade your elements? That's not going to scale at all.

gambler 10y ago
You should actually try it before making such statements. It scales well enough. Also, we could use getElementsByTagName instead of querySelectorAll. But that's not important. The point is that there are approaches to handling "components" with current APIs. They are simple, they work across all browsers right now and they are good enough for 99% of websites out there.