[psygn89]

One of the key goals in components is the ability to use it anywhere. Shadow DOM helps with that but also feels like a big thorn in the side for a lot of designers and developers to operate within. It makes more sense to design components this way when you're starting fresh and creating a library to be used anywhere. Controversially, I'd say it's often easier to just write CSS rules that fixes these conflicts and that the Shadow DOM is not really worth bending over for if you're designing within a controlled environment like your own product.

[TeMPOraL]

From the POV of a user, I consider Shadow DOM a menace, as it creates areas of the DOM that cannot be reached by CSS from outside - defeating my ability to fix UI blunders and bad design with a tailored userstyle.

[spiralx]

I hadn't considered that at all because they're so little used, but it would be an issue if they became so. I'm using Stylus for user styles nowadays which provides an option to allow you to target the CSS within an IFRAME using

    html[stylus-iframe$="twitter.com"] h1 { display:none }

and I guess they could provide a similar sort of hack to select the Shadow DOM of an element to apply CSS e.g.

    .comment:shadow .title { font-size: 1.1rem; }

Seems pretty likely to be be a performance hog to do that though.

[TeMPOraL]

Yeah, I don't see Shadow DOM often, but there are couple sites I use that employ it - most notably Gerrit. Since I use it almost every work day, I wanted to fix a bunch of UX annoyances it has. Those fixes would've normally been trivial, but Gerrit UI has everything wrapped in multiple levels of Shadow DOM, making those fixes near-impossible instead to do in Stylus alone.

[spiralx]

Some combination of Tampermonkey, MutationObserver and IntersectionObserver almost always gets there in the end, but despite having a default user script template with this exact skeleton it's a lot more of a pain in the arse to achieve what a simple CSS selector and some properties does in a few lines...

[TeMPOraL]

Exactly. And for me, that difference in PITA is the difference between fixing up websites in Stylus incrementally, spending a couple minutes for a CSS rule or three when something annoys me, vs. making a note on my TODO list to write the necessary code later, and never getting around to doing it.

[Existenceblinks]

Even as a 3rd party, somehow reusability here strangely is in form of unconflict instead of shared functionality. Reusable should include customizable style, headless is probably even better. I think Custom element's light DOM with Bring-Your-Own-Style is better for party interop.