Yeah, worth noting that there IS an escape hatch for monkey-patching (at your own risk). So you're not totally out of luck. It is just HTMLElement all the way down
In my 13 years there are a lot of technologies I've never used. Maybe there was opportunities where you could have, or maybe things are working just fine for the problems you're solving and you don't need it, which is fine too.
By default the drawer component has an "X" button in the header to close it. If you want to override that, instead of trying to style the nested "X" button you can pass in your own header actions with slot="header-actions"
> think there is a clear tension between the component desire for encapsulation vs the web designer wanting to impose their styling on the nested components
This is the inherent tension. It requires good web component authoring to expose:
1. `part`s that can be accessed by application-level CSS
2. slots for the application developer to inject html
3. CSS custom properties (--variable) -- these pierce the shadow DOM
The web component authors have to be very intentional about these things. There are good examples and bad examples and I think people are still learning how to do this well.
I see. Particularly with CSS there's more of an enforced contract around how the element internals get exposed for styling. If the element hasn't exposed `parts` or slots it's hard to hack around it.
More broadly speaking I have found myself getting thrashed by the ever evolving "best practices" in the React ecosystem. First: write everything using class components, and then a couple years later everything should be written with hooks.
I think the benefit of web components (for certain things) is that the APIs and the standards move slowly. Something you write today isn't going to feel obsolete in only a couple years.
(author from Mux here) -- that is correct. For the stuff we build for in-house use on mux.com and dashboard.mux.com we have a components library written in React.
You nailed it that we are shipping SDKs with visual components (like a video player) that need to be compatible across all kinds of frontends.
Instead of N number of SDKs to maintain where N is every front end framework, we have 2: a web component, and a React wrapper around the web component. Maybe in the (near) future we only have to maintain 1.
(author here) I think the problem might be more around bureaucracy mixed with bad & buggy code than it is a specific problem with web components. Can you expand on that?
Even though I’m not deaf or hard of hearing, I find myself using captions more and more when I consume video content. I don’t think I’m alone in that. I saw something a while ago that tracked this as a broad trend. Today’s accessibility is tomorrow’s usability.
I also work on player stuff with OP and learned a lot in this process.