Re: [WICG/webcomponents] Web components should be able to easily adapt to the host page while maintaining enapsulation (Issue #986)

I haven't been able to understand all the proposals or ideas in this thread, but I will briefly say that this is part of something I've been thinking about writing up recently. Which is that, basically, web components were designed from the beginning to give the same styling capabilities as native controls like `<input type=date>`, `<details>`, `<video controls>`, etc., but that's not enough power for how people want to use them.

I think @caridy summarizes this well, but I'll give my own take on what "the same styling capabilities as native controls" means:

- All interesting content (e.g., something a search engine might care about) should be in the light DOM; shadow DOM should only contain encapsulated "decorations". (Decoration examples: month/day/year separators, date-pickers, ">" markers for `<details>`, `<video>`'s controls, etc.)
- Those encapsulated decorations can be styled in limited ways, using `::part()` and CSS variables.
- Default styles on the light DOM content are not very significant, often nonexistent. (E.g. look at [the default styles for `<input>`](https://html.spec.whatwg.org/#form-controls) or [`<fieldset>`/`<legend>`](https://html.spec.whatwg.org/#the-fieldset-and-legend-elements).)

This is what led me to invest a lot of time in web component improvements like default accessibility semantics, form-associated custom elements, CSS shadow parts and custom state, etc. (We still haven't figured out [default focus](https://github.com/WICG/webcomponents/blob/gh-pages/proposals/custom-element-default-focus.md) though...)

**In practice**, I think this is rarely how we've seen people using web components. (Despite, maybe, @caridy and his team coming around to this point of view? :slightly_smiling_face:) People want to use them as a full "component model" in the same style as React and friends. This leads to a bunch of new proposals like declarative shadow DOM, open-stylable shadow roots, scoped custom element registries, deferred upgrades, etc. In my view all such proposals are part of making them better as a React-competitor component model.

Where does that leave us? Well, I've come to peace with the idea of building things developers want (a full component model), instead of saying that you're only able to use web components fruitfully if you are building native-HTML-like elements. I still think it's an [elegant vision](https://extensiblewebmanifesto.org/) to build out a suite of technologies such that you build new HTML-ish generic elements, with their interesting content in light DOM and their decorations selectively exposed as `::part()`s etc. But that's not really what developers want to do. They instead want to build `<mycorp-button>` or `<mysite-sidebar>` or `<myapp-widget>`. (E.g. look at [the React components MDN recommends creating for a todo-list app](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_components).) And so maybe it's fine to build tech to help with that, even if it's retrofitting on top of a base web components architecture that wasn't really designed for it.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/986#issuecomment-1449385348
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/986/1449385348@github.com>