Right now, the intention of the spec is that a toggle carries information about the number of states, state names, group, etc that it was created with, but a 'toggle-root' property can override all of that information. (Literally, can override everything about a given toggle except for its current state.) This is meant to enable some dynamic cases where a toggle acts differently based on some other state, without requiring poking around in JS to fiddle with the CSSToggle object's own attributes.
Right now, tho, I have to plumb that information around manually, which means it's easy to miss cases. Probably I should make this more automatic, with an algo that takes a toggle and, if it's on an element, returns a modified toggle according to the matching 'toggle-root' entry (if such exists), so I can just call that at the beginning of every algo.
(For example, I just rewrote the "match values" algorithm, but realized that I need to also redefine the active/inactive values in terms of that.)
Right now, the intention of the spec is that a toggle carries information about the number of states, state names, group, etc that it was created with, but a 'toggle-root' property can override all of that information. (Literally, can override everything about a given toggle except for its current state.) This is meant to enable some dynamic cases where a toggle acts differently based on some other state, without requiring poking around in JS to fiddle with the CSSToggle object's own attributes.
Right now, tho, I have to plumb that information around manually, which means it's easy to miss cases. Probably I should make this more automatic, with an algo that takes a toggle and, if it's on an element, returns a modified toggle according to the matching 'toggle-root' entry (if such exists), so I can just call that at the beginning of every algo.
(For example, I just rewrote the "match values" algorithm, but realized that I need to also redefine the active/inactive values in terms of that.)