Early design review: CSS Toggles

[dbaron]

Braw mornin' TAG!

I'm requesting a TAG review of CSS Toggles.

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.

• Explainer¹ (minimally containing user needs and example code): https://css.oddbird.net/toggles/explainer/
• Specification draft (early draft): https://tabatkins.github.io/css-toggle/
• User research: none yet, but we hope to do some once we have a prototype
• Security and Privacy self-review²: https://gist.github.com/dbaron/6dc75361b4dfad8333ad637b70d9be98
• GitHub repo (if you prefer feedback filed there): https://github.com/tabatkins/css-toggle/
• Primary contacts (and their relationship to the specification):
  • David Baron @dbaron, Google, implementor of prototype in Chromium
  • Miriam Suzanne @mirisuzanne, explainer author, specification co-author, and author of demos and polyfill
  • Tab Atkins @tabatkins, Google, specification co-author
  • Nicole Sullivan @stubbornella, Google, project manager, advocate, and organizer of user studies
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): Chrome Status

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done: Open UI (W3C info)
• The group where standardization of this work is intended to be done: CSS Working Group (W3C info), at least assuming it continues to be a CSS feature
• Existing major pieces of multi-stakeholder review or discussion of this design:
  • There's been some discussion of this in meetings of the Open UI CG.
• Major unresolved issues with or opposition to this design:
  • There has been some discussion about to what extent this makes sense to be in CSS. To some degree this breaks down into two separate questions: (1) whether the intended uses are things that should be done in CSS and (2) whether it enables doing other things in CSS that should not be done in CSS.
• This work is being funded by: Google

You should also know that...

This is actually an early-stage review. The goal of what I'm doing in Chromium 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.

We'd prefer the TAG provide feedback as:
💬 leave review feedback as a comment in this issue and @-notify users listed above

[LeaVerou]

Hi there,

Thanks for the detailed explainer and for working on solving this very common problem!
Some thoughts and questions as I look through this (just from me, we haven't discussed this in a call yet):

• I see that toggle triggers become focusable (which is great). How does that interact with other ways to control focusability?
• toggle-visibility seems like a pretty thin abstraction to be worth the extra API surface. Isn't it possible to do with the rest of the syntax with only a couple lines of code?

Avoiding recursive behavior with toggle selectors

Not sure if I misunderstood something, can't you create a cycle like this:

div:toggle(foo 1) {
	toggle-root: foo 2 at 2;
}

div:toggle(foo 2) {
	toggle-root: foo 2 at 1;
}

• I found it pretty hard to understand some of the more advanced examples, e.g. toggle-root: slides 4 at 1 sticky, toggle-trigger: page set saving;, possibly because syntax and values (at, set keywords and author-defined identifiers) are mixed and on the same level.

[tabatkins]

toggle-visibility seems like a pretty thin abstraction to be worth the extra API surface. Isn't it possible to do with the rest of the syntax with only a couple lines of code?

Having the connection between toggle and content-visibility be expressed explicitly like this should aid in reliably inferring accessibility semantics and relationships; this exact behavior is a vital part of several common and important aria patterns.

But also, achieving the full functionality here is not actually trivial. It's not hard, but it requires some scripting to, for example, activate the toggle when the element becomes automatically shown (due to becoming relevant to the user). Making the whole suite work together in some simple package is quite valuable for what we expect to be a super common use-case.

Not sure if I misunderstood something, can't you create a cycle like this:

Nope, the at <state> part of toggle-root is only used to establish the initial state of the toggle when the property causes one to be freshly created. It has zero effect on a toggle after creation; there is no way, in CSS, to set the current active value of a toggle. (It can only be set by user activation, or direct scripting, neither of which can loop in a relevant way.)

possibly because syntax and values (at, set keywords and author-defined identifiers) are mixed and on the same level.

Yeah, this has been a minor concern of mine as well. It might be worth making both counter names and state names use dashed-ident; it's a little more typing (and some checking in the scripting API), but it makes it immediately obvious what is author-defined vs CSS-defined, and avoids potential future issues with syntax ambiguity.

How does that interact with other ways to control focusability?

Great question, and still somewhat open. We need to give more thought to how, in particular, it interacts with the proposed focusgroup attribute.

[torgo]

Hi @tabatkins you've said the work is happening in the Open UI CG. Is it an official work item in that CG? Should it maybe be in the openui repo https://github.com/openui to be able to track provenance of contributions prior to moving the work to the CSS wg as indicated?

[plinss]

We've had other discussions about application state that isn't stored in way that can be encoded in HTML (see e.g. w3ctag/design-principles#289) and we do see a need for what we've been describing a presentational state vs document state (e.g. state encoded as elements and attributes and can be encoded in HTML).

This feature clearly falls into the presentational state category. We have two architectural concerns:

1. There needs to be a mechanism for preserving, recovering, and encoding presentational state. e.g. If I'm looking at something in an app that's only exposed three layers of state down and send the current URL to someone else, how do they recreate the state so they can see what I'm linking to? We're thinking something like having a holistic presentational state model, which CSS toggles can expose and interact with, but so can other features, such as presentational properties on DOM nodes. This feature could then be built so that the underlying state is explained by that model, which can then perhaps have it's own JS API (rather than something specific to toggles) and mechanisms for storing/loading and encoding the state in a manner suitable for URLs.
2. We're also concerned that authors will use presentational state where they really should be using document state (and vice-versa), has there been any thought on ways of nudging authors to choose the correct one? (Spec text and examples are an obvious mechanism, but we're wondering if something can be done to add or reduce friction to certain uses to help nudge authors...)

[plinss]

@dbaron, @tabatkins, @mirisuzanne are you available to join us for a call to discuss this further? We're thinking 8/22 @16:30 UTC but we're flexible.

[bkardell]

Sorry, I'm going to add some noise... I don't want to hijack or confuse this issue but I'm very interested in this one actually and also it's potential connections to several other developing ideas. One thing that I've started thinking about in the past year or two, especially due to involvement in OpenUI research is where delineations are between things that are unchanging controls vs something that is really in pursuit mainly of adapting presentation (an affordance). An example of this, perhaps, is that many/most native toolkits start with something simple - a ScrollPane. That is a component with its own API - but the web didn't choose to make a <scrollpane> element, but rather chose to say that overflow is a matter of style and whether it is functionally acting like a scrolling pane or not is thus clearly in the domain of CSS. When something becomes a scrollable area it becomes a sort of pseudo-interactive element. It is, unfortunately, I think still a little under-defined as to what exactly that means but it affects focus in some browsers and some kind of keyboard handling. We probably need some more focus here on even providing keyboard parity (see w3c/html-aam#358, for example).

You can contrast this with perhaps the only other non-form participating element we've done before dialog, <details>. Here we said <details> has a component nature - but that means that it is not possible to say "On a big screen I'd like it to be open because there's plenty of room" or "when it is printed, it's just content". We raised new questions about searching and linking and so on there too.

Along the way in our discussions we came to some ideas (some of which Toggles may potentially provide an explanation of the magic behind) about being able to provide some simple UI patterns that could offer affordances for some simple common patterns. I'm bringing this up because we've not submitted that for even an early review - there are too many questions still. Among them perhaps were some questions raised related to whether things with affordances really were 'the same' as their actual counterpart components which exist in 'applications'. To this end, we've split off some work with some discussion in an issue filed by me and Sarah Higley: openui/open-ui#559 .. It might be interesting or helpful to have a look if you can find the time.

[mirisuzanne]

@plinss I'm available at that time.

[dbaron]

That time works for me as well.

[tabatkins]

Yup, that's fine for me.

[plinss]

Cool, invites sent

[yisibl]

Yeah, this has been a minor concern of mine as well. It might be worth making both counter names and state names use dashed-ident

@tabatkins Yes, changing the syntax to dashed-ident would be clearer.

[torgo]

So on the basis of our discussion on 8-22 we're happy to close this. Thanks for flying TAG.