That’s exactly what that was!
I’m working through code now that processes stylesheets and hope to apply selectors to style blocks. Once I can specify and carry a style block associated with specific controls, then work continues on applying those style blocks (or, rather, rulesets) to specific controls.
With added selectors, I might have to rethink/retract some of what I’ve been doing with “inheritance.” My assumption is that the control hierarchy flows all rules from parent to child, regardless of whether the rule applies to the parent or child. The thought is that any grandchild might use those rules, and ignore rules that don’t apply to it specifically. I also allow the specification of a property on a control that interprets a parent’s property. Does this work for “width?” That is, does width specified on a parent flow to the child when width is NOT specified for that child directly? To model block flow, I don’t think this works for X,Y position. But maybe position is the exception, so the general implementation still works?
If the inheritance assumption is false, then removing or tweaking it is not that burdensome. Relative value interpretation still needs the notion of style hierarchy, so much of that work will still be useful.
I know inheritance and selectors seem outside of the direct path from “get a property to show a thing” and “apply a property to multiple controls” but we already have a fairly decent workaround for that (@PatrickRyan’s collection of functions, and my prototype “ApplyStyleToFrom”). Working out inheritance and selectors will multiply the benefit of getting “a property to show a thing” by making it possible to create a stylesheet for an entire GUI with, hopefully, minimal repitition of style rules.