Re: [w3c/webcomponents] Custom pseudo-classes for host elements via shadow roots (:state) (#738)

I think that if we had designed `ElementInternals` first, we would have put `attachShadow()` there and not made it available on 18 built-in elements as well.

I also don't see the consistency argument with `::part()` so much. There's no API on `ShadowRoot` for that. And `::part()` makes certain encapsulated bits of the host accessible, whereas `:state()` reflects the state of the host and has no real relation with the encapsulated bits.

If there are use cases for using `:state()` on those 18 built-in elements, we should really figure out to what extent that goes for the other APIs we are putting on `ElementInternals`. For ARIA we identified conflicts (e.g., `h1` has implied `role=heading`). For `:state()` v2 from @tkent-google above it seems likely we might get conflicts as well (e.g., with the proposed `:heading(n)`).

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