Kenneth: Lots of comments there...

Peter: Ok, this was because existing APIs only let you specify boolean states. Got a lot of feedback...

... I'd like to see this as a general-purpose mechanism, not restricted to boolean states.

... Most existing pseudo-classes are boolean, but things like dir and lang aren't.

... state (?) has a token list, so more like the has() API

... Just adds one attribute to the ElementInternals, which is a tokenlist "state".

... Alternatives considered mentions an alternative syntax, using dash dash prefix

Kenneth: I don't know that I particularly like either syntax alternative, in a sense it makes sense...

... what other examples are there that aren't boolean?

Peter: Just :dir() and :lang() - both strings.

... token list is the set of custom states you're exposing, where each is just present or not. Would have to add something like a map.

... If we're going to use a map why not just use a map?

... Maybe we should set this as pending external feedback?

Kenneth: When might you use a non-boolean state?

Hadley: Would be nice if the explainer had some user-focused use cases...

Peter: checked state for a tri-state checkbox, you'd have to have a checked boolean and an indeterminate boolean...

... right now pretty much all you can do is set an attribute on the host attribute. So we could use attributes on custom elements which are used for styling as data to feed into this design.

Peter: Bump it, I haven't filed my feedback yet.

Rossen: we discussed with CSS wg. There were some people working on it. More disucssion encouraged.

... some challenges by Peter to current design ...

... accepted by the group ...

... related to design of the JS API

Peter: Happy that my feedback received. I feel the TAG side of this is in good shape. Maybe mark as "pending external review" - and loop back on it .. Not for the f2f