3 ms·

"letting styles leak all over the entire document" CSS selectors allow for a pretty wide breadth of targets -- they can be as narrowly specific or as broadly g

"letting styles leak all over the entire document" CSS selectors allow for a pretty wide breadth of targets -- they can be as narrowly specific or as broadly general ("leaky") as the author likes. What's the exact problem that another layer/mechanism of scoping solves that being thoughtful about your selectors doesn't?

cdata 11y ago
ShadowDOM removes the need for a component user and a component author to collaborate in order for styles to be encapsulated. This, in turn, enables easier distribution and usage of generalized components.
- pixie_ 11y ago
  Exactly, how many times do you want to use a component but find it near impossible because it's written with a framework, or uses CSS styles that conflict with your own, or is written for use with a different version of the very framework you're using... this is why we keep re-inventing the same dumb web components over and over again.
spankalee 11y ago
It's basically impossible to implement lower bounds for descendent selectors without scoping. You can kind of fake it with build steps and some luck, but it will always have holes and problems with dynamically updated DOM. Faking lower bounds also keeps the browser from knowing that it doesn't have to invalidate the isolated scopes when properties above them changes.
solidr53 11y ago
One-hundred Shadow DOM Elements, each with 10 DOM elements and 10 CSS selectors. vs One-thousand `regular` DOM Elements with 1000 CSS selectors. It's a simple math. 10 times faster.
- BinaryIdiot 11y ago
  I don't think that's a fair comparison. Why would you need so many selectors in the 'regular' case and what are they doing? I've worked on some pretty complex apps and have never even come close to 200 selectors in total; probably not even 100 but I'm not 100% sure. Shadowdom allows for specific targeting within a component; is that necessary faster than a query using another element / class name for targeting a component in "regular" usage? I'm curious on the numbers here as I don't know that you're necessary right or wrong here.

cdata 11y ago

ShadowDOM removes the need for a component user and a component author to collaborate in order for styles to be encapsulated. This, in turn, enables easier distribution and usage of generalized components.

pixie_ 11y ago
Exactly, how many times do you want to use a component but find it near impossible because it's written with a framework, or uses CSS styles that conflict with your own, or is written for use with a different version of the very framework you're using... this is why we keep re-inventing the same dumb web components over and over again.

spankalee 11y ago

It's basically impossible to implement lower bounds for descendent selectors without scoping. You can kind of fake it with build steps and some luck, but it will always have holes and problems with dynamically updated DOM. Faking lower bounds also keeps the browser from knowing that it doesn't have to invalidate the isolated scopes when properties above them changes.

solidr53 11y ago

One-hundred Shadow DOM Elements, each with 10 DOM elements and 10 CSS selectors. vs One-thousand `regular` DOM Elements with 1000 CSS selectors. It's a simple math. 10 times faster.

BinaryIdiot 11y ago
I don't think that's a fair comparison. Why would you need so many selectors in the 'regular' case and what are they doing? I've worked on some pretty complex apps and have never even come close to 200 selectors in total; probably not even 100 but I'm not 100% sure. Shadowdom allows for specific targeting within a component; is that necessary faster than a query using another element / class name for targeting a component in "regular" usage? I'm curious on the numbers here as I don't know that you're necessary right or wrong here.