alignment with state machines

[argyleink]

would love if i could make/share charts for the ~state machines i'll be building with toggle, be great for tooling and greater community adoption if verbiage and functionality were more aligned.

[tabatkins]

I'm not sure what you mean here. Could you elaborate?

[davidkpiano]

I'm not sure what you mean here. Could you elaborate?

Example: #6 (comment)

[argyleink]

imagine devtools had this built in and could map out the toggle logic https://xstate.js.org/viz/ and could be shared with design teams and PMs:

the verbiage doesnt necessarily need to match 1:1, but if it could be functionally mapped to the core ideas in state machines, it opens up a lot of already existing methodologies, folks and tooling to converge with CSS's new feature.

[tabatkins]

I'm sorry, I still don't understand. I suppose you could treat a toggle as an extremely simple sort of state machine, one that simply cycles thru N states before returning to the beginning, but I'm not sure what value you would get out of that, or what alignment in verbiage you'd be looking for.

[matthewp]

A toggle is a simple state machine. So let's just implement state machines instead of a boolean toggle 😀. It could be scoped to be small, not full state machines at first, probably not even events, but N states that you can transition between rather than a boolean toggle doesn't sound very much of a feature-creep over this spec. A toggle-group is already like a machine. Complete pseudo-code:

panel-set {
  machine: tab;
}

panel-tab:machine-state(tab initial) {
  machine-transition: enabled;
}

panel-tab:machine-state(tab enabled) {
  machine-transition: disabled;
}

If you wanted to get crazy and add events to a transition:

panel-tab:machine-state(tab initial) {
  machine-transition: :active enabled;
}

[tabatkins]

So let's just implement state machines instead of a boolean toggle

Again, I'm not sure what value we'd get out of this. I asked this same question in #6 (comment).

[tabatkins]

I still haven't gotten any reasonable elaboration on what, precisely, is meant by "state machines" and what sort of page design would be helped by this, which can't be reasonably done with the current design.

(Note: I am 100% aware of what state machines, DFAs, etc are. I'm just asking for examples of what is actually meant by using them.)

[mirisuzanne]

Thinking through this as I work on an explainer, we currently support:

• incrementing the state by 1
• setting the state to a specific value

When we move past the maximum state, we allow:

• default behavior returns to 0 (inactive)
• sticky behavior returns to 1 (first active)

I can see two extensions here that have fairly clear use-cases:

• decrease the state by 1 (eg carousel prev/next, or font-size increase/decrease)
• a linear option that only moves forward, and does not continue cycling active states (eg a carousel that doesn't wrap)

When it comes to more complicated logic around the order of states, that should generally be possible by changing the toggle-trigger value based on a current :toggle() state selector. That might not feel like the simplest syntax to manage - but it could be pre-processed, and it doesn't seem like a core use-case to me.

[matthewp]

@tabatkins It would be easier to give better feedback here once the explainer is ready. Personally I don't understand what this spec is doing yet; I see several properties, I see 0/2 and my brain doesn't understand how this corresponds to true/false, but I believe that it does and once I see an explainer I can hopefully give better feedback.

I can answer the question that you asked in that other issue though:

What other sorts of controls are we trying to model that aren't satisfied by these transition sets?

Almost all of them. I can't think of too many controls that don't have > 2 states. If you want a concrete example, the title of a GitHub issue has at least 6 states (names made up by me):

• preview: The default view when on an issue page.
• edit: When in edit mode.
• save: When saving to a remote API.
• error: When the API server errors for some reason.
• cancel: When rolling back changes from edit mode.
• validate: When confirming the new input title is an acceptable string.

[mirisuzanne]

@matthewp I think the explainer is far enough along to answer most of your questions here - for example, the proposal does support >2 states, and the explainer covers that, and how to trigger movement between them. The n/x syntax is also explained there (which is how you set the number of states and also the initial state).

[matthewp]

@mirisuzanne Is it correct to say that what represents activation is unclear at this point? Will that be user-defined some how? Happy to give general explainer feedback somewhere else if preferred.

[mirisuzanne]

Is it correct to say that what represents activation is unclear at this point? Will that be user-defined some how?

It is a bit unclear. Currently the idea is something like existing link/button activation (which are themselves slightly different). There are plans to try and extend that to other interactions, such as scroll/snapping. If there are multiple types of interaction, I would expect those are defined in the spec, and authors have access to hook into the interaction-type desired.

Happy to give general explainer feedback somewhere else if preferred.

• For that sort of question about the spec, feel free to open new issues in this repo.
• It might make sense for me to move the explainer into this repo as well, but for now feedback on the explainer itself belongs in https://github.com/oddbird/css-sandbox/issues

[matthewp]

Ok, after having read it, I can see that this supports more than 2 states. What is missing that FSM gives you is the ability to define valid state transitions.

The explainer shows using toggle-trigger shorthand to cycle through states; but you would almost never use this when you have > 2 active states; you don't cycle through 6 states sequentially, you have a specific path that they can go.

The inactive state idea solves this for the checkbox example but has the following downsides:

• Checkboxes have 3 states - the idea of "inactive" and "active" is confusing; they are all just states. This really feels like this a special casing for checkboxes only. The result of special casing is, in my opinion, a more difficult to understand feature.
• The problem still exists for controls with states > 3, for example the GitHub title bar explained here. You should not be able to go from preview -> save or cancel -> save.

[flackr]

So I think @mirisuzanne covered your > 3 states concern in #7 (comment), if you want to only have specific state transitions, you could accomplish that by not using the automatically cycling toggle-trigger but instead using the one that has a particular next value, e.g. for your github example:

/* states: 0 = preview, 1 = edit, 2 = save, 3 = cancel */
button.preview:toggle(state 1) {
  toggle-trigger: state 0; /* preview */
}
button.preview:toggle(state 0) {
  toggle-trigger: state 1; /* edit */
}
button.save:toggle(state 1) {
  display: block; /* only visible from edit state */
  toggle-trigger: state 2;
}
button.cancel:toggle(state 1) {
  display: block; /* only visible from edit state */
  toggle-trigger: state 3;
}
/* no user activatable trigger from state 2 or 3 */

Once you reach state 2 (save) or state 3 (cancel) you would then use the not-yet-defined scripting API to update the state once the action had been taken.

Note: There are probably shorter ways to write this, i.e. if .save and .cancel are only visible in edit mode there's no reason they couldn't always have the toggle-trigger style.

[tabatkins]

sticky behavior returns to 1 (first active)

I'm... not sure why I specified it that way. It should clearly just stay in that last state. I'll fix that.