Re: [csswg-drafts] CSS Toggles Proposal (#6991)

> In other words, a more abstracted "state" model for HTML which can be read / changed by a CSS definition, but is also not so tied to CSS. Something that's more future-proof, I guess?

The underlying mechanism here is to give elements a (deliberately very simple!) notion of "state", which can be created, manipulated, or reacted to by JS, and then have (a) a way for user interaction to change that state without script (the `toggle-trigger` property), (b) a way for CSS to respond to that state (the `:toggle()` pseudo) so authors can do presentational (and lightly semantic, when possible, like showing/hiding) things with it, and (c) a way to *initialize* the state without JS, so (a) and (b) can usefully function in no-JS situations (the `toggle-root` property).

This state is intentionally kept to just a non-negative integer or an ident; CSS can't reasonably handle much more than that with its syntax, on either the setting *or* reading side. To the extent that other systems can work under that limitation, they're free to use a toggle to store stuff on an element. If they're not using at least one of (a) or (b) above, tho, there's not really any benefit to it; just storing info in a JS property on the element is equivalent, more powerful, and more convenient. This is very intentionally *not* a generic whole-app state management system, as that is a far more complex problem and ties into far more things than CSS can interact with. It's just one corner that is useful on its own, and can form a useful appendage of larger state management systems.

> The other mild concern I have is that what causes a state change is implicit and not explicit.

Spec will get cleaned up as we progress, and I expect it will grow more ways for users to interact with a toggle (like tying it to scroll snaps!), but the default is going to be "interaction" as defined by the host language. HTML already has activating an element as a well-defined concept.

> By the way, what happens when a state root "definition" gets redefined by a class that's added after that state value has been "triggered"?

Nothing. At style resolution time we check that every element with a `toggle-root` has the named toggles defined on it; if not, we create them with the specified details. If they already exist, we just skip over them. This is a necessary part of the way we avoid styling cycles.



-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6991#issuecomment-1108926538 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 25 April 2022 18:57:48 UTC