4 ms·

You don't explain how you think Shadow DOM is too complex. They're simple to me: basically just isolated tree of DOM attached to the document. The only slight

You don't explain how you think Shadow DOM is too complex. They're simple to me: basically just isolated tree of DOM attached to the document. The only slight complexity comes from projection, which really is just a way to plug in a child element into the shadow. Projection is absolutely necessary for composable widgets, you couldn't create containers without them.

kuschku 11y ago
One issue I have with this is that I won’t be able to apply a userstyle to restyle a page anymore, and I won’t be able to use websites without JS anymore. Just earlier today I had an issue where I was trying to read this article [1] and the page, after loading for around 3 minutes (I was on mobile and on the free plan of my ISP, which gives only 64kbps, but unlimited), had all the content, but neither JS nor CSS. There are already many websites which I can’t use at all anymore because they make everything invisible until JS and CSS are loaded. Flash of unstyled content is not an issue for me, it’s the whole reason I am able to read pages. [1] http://www.npr.org/2015/10/22/450583840/in-d-c-and-china-two-approaches-to-a-streetcar-unconstrained-by-wires http://www.npr.org/2015/10/22/450583840/in-d-c-and-china-two...
- aaronharnly 11y ago
  > One issue I have with this is that I won’t be able to apply a userstyle to restyle a page anymore With the caveat that I only sorta understand this stuff -- if it emerges this way after the politics & process, you should be able to use the 'deep combinator' >>> to apply styles even across shadow DOM boundaries. https://drafts.csswg.org/css-scoping-1/#deep-combinator https://drafts.csswg.org/css-scoping-1/#deep-combinator
  - kuschku 11y ago
    > It’s currently disputed whether this combinator should exist. Also, it breaks about every existing userstyle, ever. And there should be a more general solution that also handles the shadow DOM of browser-internal elements like the <input type="file">
  - colordrops 11y ago
    I think the deep combinator is already deprecated in Chrome and unlikely to make it into the spec.
- Touche 11y ago
  This is not an issue you have with WebComponents specifically but the direction the web has been taking for the last 10 years.
  - deleted 11y ago
    [deleted]
EdSharkey 11y ago
Solving the problem of composability of visual components on top of the existing DOM leads to chicken-or-egg problems like getComputedStyle/offsetTop mentioned in that Mozilla blog link someone else referenced. DOM is a crufty stateful beast, and enhancing it is hard which scares me away. Beyond that, the Web Components spec seems geared for coarse-grained components - like a widget or a panel. I could be wrong about this, I admit, my experiments a year ago with Web Components were short lived when I saw how much got polyfilled on Firefox. Anyhow, React is a javascript library exercise rather than a retool-the-DOM exercise to me, and that's a big reason I appreciate it. It offers data binding, rendering, templating, and true-componentization all in one package - and it supports legacy systems. I think there's an answer in Web Components for all of those things, including legacy support up to a point with polyfills, but it wasn't cohesive nor easy to roll things. I think with lots of tool support, perhaps a compiled language targeting the Web Components spec, it could be just as easy to roll Web Components as React Components.

kuschku 11y ago

One issue I have with this is that I won’t be able to apply a userstyle to restyle a page anymore, and I won’t be able to use websites without JS anymore. Just earlier today I had an issue where I was trying to read this article [1] and the page, after loading for around 3 minutes (I was on mobile and on the free plan of my ISP, which gives only 64kbps, but unlimited), had all the content, but neither JS nor CSS. There are already many websites which I can’t use at all anymore because they make everything invisible until JS and CSS are loaded. Flash of unstyled content is not an issue for me, it’s the whole reason I am able to read pages. [1] http://www.npr.org/2015/10/22/450583840/in-d-c-and-china-two-approaches-to-a-streetcar-unconstrained-by-wires http://www.npr.org/2015/10/22/450583840/in-d-c-and-china-two...

aaronharnly 11y ago
> One issue I have with this is that I won’t be able to apply a userstyle to restyle a page anymore With the caveat that I only sorta understand this stuff -- if it emerges this way after the politics & process, you should be able to use the 'deep combinator' >>> to apply styles even across shadow DOM boundaries. https://drafts.csswg.org/css-scoping-1/#deep-combinator https://drafts.csswg.org/css-scoping-1/#deep-combinator
- kuschku 11y ago
  > It’s currently disputed whether this combinator should exist. Also, it breaks about every existing userstyle, ever. And there should be a more general solution that also handles the shadow DOM of browser-internal elements like the <input type="file">
- colordrops 11y ago
  I think the deep combinator is already deprecated in Chrome and unlikely to make it into the spec.
Touche 11y ago
This is not an issue you have with WebComponents specifically but the direction the web has been taking for the last 10 years.
- deleted 11y ago
  [deleted]

EdSharkey 11y ago

Solving the problem of composability of visual components on top of the existing DOM leads to chicken-or-egg problems like getComputedStyle/offsetTop mentioned in that Mozilla blog link someone else referenced. DOM is a crufty stateful beast, and enhancing it is hard which scares me away. Beyond that, the Web Components spec seems geared for coarse-grained components - like a widget or a panel. I could be wrong about this, I admit, my experiments a year ago with Web Components were short lived when I saw how much got polyfilled on Firefox. Anyhow, React is a javascript library exercise rather than a retool-the-DOM exercise to me, and that's a big reason I appreciate it. It offers data binding, rendering, templating, and true-componentization all in one package - and it supports legacy systems. I think there's an answer in Web Components for all of those things, including legacy support up to a point with polyfills, but it wasn't cohesive nor easy to roll things. I think with lots of tool support, perhaps a compiled language targeting the Web Components spec, it could be just as easy to roll Web Components as React Components.