Allow variables to be set within conditional sections

[csytsma]

It appears that variables can only be set in a stand-alone line. For example:
@color: red;

It would be great if the variable assignment could happen within a conditional, so the value could be set based upon the element being rendered. For example, with [name] being set in the layer data:

[name='trek'] { @color: red; }
[name='bike'] { @color: blue; }
[name='canoe'] { @color: green; }
line-color: @color;

[nebulon42]

What would be the improvement in contrast to writing:

[name='trek'] {
  line-color: red;
}
[name='bike'] {
  line-color: blue;
}
[name='canoe'] {
  line-color: green;
}

Variables are meant to ease the re-use of a definition, but in your example I don't see the added value of using variables. Could you come up with an example that better illustrates your point?

[csytsma]

The situation that lead me to want this, was that I was styling a line, with a marker. I ended up having to specify the color 4 times: line-color, text-fill, marker-line-color and marker-fill.

[name='trek'] {
line-color: red;
text-fill: red;
marker-line-color: red;
marker-fill: red;
}
[name='bike'] {
line-color: blue;
text-fill: blue;
marker-line-color: blue;
marker-fill: blue;
}
[name='canoe'] {
line-color: green;
text-fill: green;
marker-line-color: green;
marker-fill: green;
}

Compared to:
[name='trek'] { @color: red; }
[name='bike'] { @color: blue; }
[name='canoe'] { @color: green; }
line-color: @color;
text-fill: @color;
marker-line-color: @color;
marker-fill: @color;

Makes for changing a color easier in the future. The variable can be at the top of the section, easy to find, and only change in one place.

Thanks

[nebulon42]

Ok, makes more sense now. :)

[nebulon42]

Related to #338.

[nebulon42]

This is nearly working, but there is a tricky thing left that may lead to (a lot more) architectural changes.

Some architectural changes were already needed, I'm documenting them here for reference. I had to

• establish parent - child relationships between rulesets and between ruleset and rules
• establish a relationship between a rule and its building blocks (expressions, vars, dimensions, ...)
• extend specificity with zoom level (this gets tricky when a zoom level filter itself contains a variable, then we could easily go into an infinite evaluation loop, therefore I disabled zoom level within specificity for those cases)
• compute specificity for variable definitions, compute specificity for the rule that is evaluating the variable and use that to decide which variable definition to select

What is working:

@var: 'foo';

#world {
  @var: 'oof';
  [zoom >= 5] {
      @var: 'roof';
      text-name: @var + 'bar';
  }
  text-face-name: 'Arial';
  text-name: @var + 'bar';
}

Note the duplicated text-name rule.

What is (not yet) working:

@var: 'foo';

#world {
  @var: 'oof';
  [zoom >= 5] {
      @var: 'roof';
  }
  text-face-name: 'Arial';
  text-name: @var + 'bar';
}

The reason for that is the following: When the evaluating rule is not part of the filter in question it also does not inherit its specificity options. At render time this is transformed to two separate rules with the right zoom levels set. But at parse time where the variables are evaluated this is not yet done. There are no two separate text-name rules but only one. This one rule has to resolve to one variable value the first time and to another one the second time.

I don't know yet how to solve this. One idea would be to move the duplication from render to parse time and generate two rules. One for zoom >= 5 and one for the rest. Then the variables could be evaluated to the right values. But maybe this requires too many core changes.

This problem does not apply to Less because they only have selectors and no filters.

Branch: vars-everywhere