CSS toggles are a mechanism for associating toggleable state with a DOM element. This state can be defined and connected to activations through CSS properties, and can be queried in CSS selectors. This provides a declarative mechanism for specifying state that describes behaviors like the existing HTML behaviors for checkboxes or radio buttons.
There are many cases where a user interaction (such as a click) toggles state that styles depend on. These cases include popups, tabs, carousels, accordions, and toggles controlling light/dark mode. Building these today requires Javascript. We would like to build a declarative way of doing this that, if we do it right, will be easier for developers to use, faster, and more accessible than the solutions that are used today.
I'd like to emphasize that this intent to prototype really is an intent to prototype. The goal here is to build an implementation that can be used to guide the design of this feature (by giving those involved an implementation to test), not to build something that we'd like to ship quickly.
Before we would consider shipping something in this space, we would (among other things) want to do further testing to validate that the result is more accessible than what people use today (or learn that we need to build in more distinctions that can be reflected into accessibility roles), and do additional development of the things that we hope can be built on top of toggles to validate that it works as a primitive.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No.
New CSS properties and CSS selectors should be debuggable in the same way that all existing properties and selectors are. If this turns into something that we want to ship, we will probably want to add additional devtools support for understanding the underlying toggle states, but we don't want to do so this early in the prototyping process.
No milestones specified
Contact emails
dba...@chromium.org, ns...@google.com
Explainer
https://css.oddbird.net/toggles/explainer/
Specification
https://tabatkins.github.io/css-toggle/
A question came up in Security & Privacy review today. Can
you clarify what "persistent state" means in
https://tabatkins.github.io/css-toggle/#toggles? I suspect we're
not re-inventing cookies in CSS here, but can you help me
understand what that means in the context of CSS toggles? Does it
just mean that once set, other CSS properties can't influence the
state? Or "persistent state (for the lifetime of the page)"?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3hE3gnQQNHTD7hT-jukBYFgwTXbYZQWSS1iJVXn9J7iyg%40mail.gmail.com.
Specification
https://tabatkins.github.io/css-toggle/A question came up in Security & Privacy review today. Can you clarify what "persistent state" means in https://tabatkins.github.io/css-toggle/#toggles? I suspect we're not re-inventing cookies in CSS here, but can you help me understand what that means in the context of CSS toggles? Does it just mean that once set, other CSS properties can't influence the state? Or "persistent state (for the lifetime of the page)"?
Thanks David - that's helpful.