tabatkins
commented
3 years ago As I read it (which might admittedly be wrong), the draft says that 0 (the first number in the range) will be the initial state, but from a UI standpoint you would need it to be...2. Right?
If you wanted it to start indeterminate, that's fine to do as well (use 2/2 instead), I just wrote the example to start it unchecked.
An indeterminite state exists only for when interaction is required - for when you cannot assume a default answer and you haven't collected one yet. I guess this was done to keep 0 and 1 as "off" and "on" or "active" and "inactive" but it also means that 'indeterminate' is now an expressively "active" state (which the spec also seems to suggest in that example), but indeterminiate seems to my own thinking, expressly not that. This also means (again, I think) that it would match the generic :checked(nameOfToggle) too. That seems unfortunate too.
Correct on the interactions. "active" vs "inactive" solely matters for whether :checked() matches or not when you don't specify an explicit state, and how toggle groups function together (all but one must be "inactive").
Whether you, in your own personal semantics, consider a state "active" or not isn't the most important; all the unchecked states slot into "active" just because they have to be in one of the categories, and per the toggle-group semantics, it makes the most sense for there to be only a single "inactive" state so I can force toggles into that state without ambiguity. If you have a 3-state (or more) toggle, the ":checked() without an explicit state value" isn't useful to you; you'll want to match against explicit states. (I just don't want to force the by-far-most-common case of a 2-state toggle to have to do extra work for their situation.)
The spec also implies that we could have named states but doesn't really explain to me how names map to the numbers, which is seems is necessary for them to retain this special 'meaning' that seems inherent in the numbers. That is, I can write 0/3 or 1/3 and those mean something different - but I guess you'd need to express the same, only with names somehow.
Yes, that's marked with an issue right now, because it's not yet defined. ^_^
It'll be a really trivial mapping - you supply 2+ names, and they map to the integers 0+ in order. You can then use those names in :checked() or toggle-set rather than referring to the states by integer, or even in toggle-create so you could say toggle-create: checked indeterminate / 2; to put it into the indeterminate state initially.
The other bit thing that ties in here a little is groups. I think of groups as being useful in managing a series of actually 2 value toggles in a mutually exclusive manner. I think that's really their main (only?) purpose (at least if we're only talking visually). There would seem to be a lot of overlap between a group and an 'N value' toggle. I can't help but think that maybe you could solve N value things with a group instead (which can have none active) and just keep toggles themselves to being simple 2 value things.
I don't understand how we could map the two concepts together. A n-state toggle (like a 3-state checkbox) is an entirely different thing, in both semantics and interaction, from a toggle group (of two toggles, I guess? Or three?). Trying to merge those would, as far as I can tell, result in a ton of complexity in both the author-exposed interface and the spec concepts, in return for the dubious benefit of the spec only ever using bools at the bottommost level.
Basically, I don't see anything wrong with having a group of 3-state toggles. Only one can be active at a time, and you can toggle the currently-active one between its two active states; if you toggle another one active, the first will switch back to "off" regardless of which active state it was in. This seems like a straightforward extension/combination of the existing checkbox and radio functionality in HTML.
A note for discussions trying to describe a thing that keeps tripping me: numbers, names, groups, values and what they mean.
By default a toggle is, as the name would imply "a setting that can be switched between two different options by performing a single action". I think about this like a light switch, or a bit. When it's created, authors give it a name, which I think about like putting a name on the light switch cover or a diagram of the bit, like "fan". The default state is 0, which the spec calls "inactive", and I would think of as "off". When you toggle, it goes active (1), when you toggle again, it is inactive (0). If it is 'active', it matches
:checked(nameOfToggle).Simple enough. However, this mental model starts falling apart for me pretty quickly as authors can create N value toggles. The spec uses this and 0/3 in example 8 to create something like an "indeterminate" state. Effectively they become on their own a whole state machine. However here, we wind up with 2 as being labelled as "the indeterminate value". I think that example 8 is broken here as said in #3 and intends to read like..
As I read it (which might admittedly be wrong), the draft says that 0 (the first number in the range) will be the initial state, but from a UI standpoint you would need it to be...2. Right? An indeterminite state exists only for when interaction is required - for when you cannot assume a default answer and you haven't collected one yet. I guess this was done to keep 0 and 1 as "off" and "on" or "active" and "inactive" but it also means that 'indeterminate' is now an expressively "active" state (which the spec also seems to suggest in that example), but indeterminiate seems to my own thinking, expressly not that. This also means (again, I think) that it would match the generic
:checked(nameOfToggle)too. That seems unfortunate too.The spec also implies that we could have named states but doesn't really explain to me how names map to the numbers, which is seems is necessary for them to retain this special 'meaning' that seems inherent in the numbers. That is, I can write 0/3 or 1/3 and those mean something different - but I guess you'd need to express the same, only with names somehow.
I feel like somehow we might need a concept like 'indeterminate' expressed specifically.
The other bit thing that ties in here a little is groups. I think of groups as being useful in managing a series of actually 2 value toggles in a mutually exclusive manner. I think that's really their main (only?) purpose (at least if we're only talking visually). There would seem to be a lot of overlap between a group and an 'N value' toggle. I can't help but think that maybe you could solve N value things with a group instead (which can have none active) and just keep toggles themselves to being simple 2 value things.