Re: [w3ctag/design-reviews] [WebComponents] Custom state pseudo class (#428)

Personally I'm very happy to see this moving forward, custom states visible as pseudo classes is something that I've wanted for a long time.

I'm concerned however that this design seems to only allow boolean states. While boolean states should be simple for authors to use, I can see many use cases for other types, at the least strings and numbers.

I accept that other values opens up a number of issues that may not want to be addressed in version 1 of this proposal (e.g. do we allow for more than simple value matching, substrings, numeric comparisons?), but at the least it would be good if the api surface allowed for other types in the future. Perhaps the states attribute should be a map rather than a token list?

I'm also somewhat in favor of the `:--state` syntax (or `:--state(value)` for non-boolean states), but I'd also want to see it kept in alignment with `::part()`, so if this uses `:--state` then custom parts should use `::--part`. (fwiw, differentiating pseudo elements from pseudo classes via `::` vs `:` was intended for this extensibility point.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/428#issuecomment-540154281