- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Sun, 03 Feb 2019 03:41:06 +0000
- To: public-css-archive@w3.org
> Note that we DO need JS-based solution regardless I was assuming that fully custom states would be set the old-fashioned way, by setting a class or data attribute from JS. But yes, that would clearly be less efficient than just adding a token to a `state` DOM property directly. And you clearly know more than I do about implementation headaches, @rniwa. I was thinking of this purely from the perspective of passing values up the tree of shadow trees, but selectors are maybe a little too generic for that. I'd forgotten that things like `:host-context` exist and could send interactions back down the tree. *(So much for early morning brain storms.)* ________________ The first half of my comment still stands: There's a logical need for custom state properties, both for the component as a whole, and for `::part()` within it. And it should be possible for either type of state to be generated by forwarding a state from a nested component. So if there isn't a declarative way to do that, there needs to be a `StateObserver` or similar to allow the JS of the outer component to react to a change in the inner component, and update the state that it (or its parts) exposes. But `StateObserver` sounds like a good idea anyway, so that's not a criticism. I also still like the idea of letting the custom state mechanism override standard pseudoclasses (`:state(checked) === :checked`). I think that still works as a good fallback mechanism, no matter how the custom state is generated. -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3431#issuecomment-460020303 using your GitHub account
Received on Sunday, 3 February 2019 03:41:08 UTC