Interactive SVG Backgrounds / Improvement ideas

[krocans]

The current implementation of Interactive SVG Backgrounds limits its use to binary (OnOff, OpenClosed) values. While the new State On substitute feature offers a custom ON value, it is still reduces it to only one value and only that value triggers an element's color/class change.

In practice, there are often items with multiple possible values ​​that are in principle impossible to work with in the current solution - assigning different colors/classes depending on different values.

To solve this problem, I think it would be worthwhile to abandon the ON/OFF approach altogether and use a solution in which the class or color is determined using a formula for ANY item value.
This is nothing new, a similar approach is already being used in OpenHAB, for example, for the color parameter in the Widgets configuration, Floor Plan Marker, etc.
True, technically this would be breaking change by fully abandoning the existing parameters stateOnColor, stateOffColor, stateOnAsStyleClass, stateOffAsStyleClass and introducing universal parameters stateColor, stateAsStyleClass whose values ​​would be formulas which will be calculated on any state change.
This might make the configuration a little more complicated in simple cases like OnOff, but it would still guarantee complete flexibility, for example:

# Item:
Number:Temperature Temperature "Temperature [%.1f %unit%]" <temperature> {channel="..."}
# Layout config:
stateColor: "=(Number.parseFloat(items.Temperature.state)>30)?'red':((Number.parseFloat(items.Temperature.state)>18.0)?'orange':'blue')"

# Item:
Number HVAC_Mode "HVAC [%s]" <heating> {channel="...", stateDescription="" [options="0=Auto,1=Cool,2=Dry,3=Heat,4=Fan,5=Off"]}
# Layout config:
stateColor: "=('white:blue:gray:red:lightblue:black').split(':')[items.HVAC_Mode.state]"

# And simple case
# Item:
Switch SomeItem
# Layout config:
stateColor: "=(item.SomeItem.state === 'ON') ? 'green' : 'red'"

The situation with classes is a bit more complicated, because the current solution allows changing the class of another element in the configuration of one SVG element. Returning such complex information from the formula and interpreting the results could be very complicated.
Honestly, I'm not sure that such an option (changing another element) is necessary, because it is not very convenient to configure keeping in mind that some element1 class is actually changed in the configuration of a completely different element.
If we discard the possibility of changing the class of an element in another element, then stateAsStyleClass can use the same method described for color. Again, this may require more configuration, configuring each element individually, but will provide complete flexibility.