opened
cusspvz
username_0
I'm working with less for a while. I've used selector interpolation about 4 or 5 times, but I did not had the need to include nested classes over it until now.

So I've came across on what I think it could be a potential issue.
Here's a test case:

## Input
```
@theGoodThings: ~".food, .beer, .sleep, .javascript";

@{theGoodThings} {
  &:after {
  font-weight: bold;
  }
}
```

## Output
```
.food, .beer, .sleep, .javascript:after {
  font-weight: bold;
}
```

## Output I was expecting:
```
.food:after, .beer:after, .sleep:after, .javascript:after {
  font-weight: bold;
}
```
Selector interpolation: Shouldn't variables be evaluated before the code parse?
issue
created
cusspvz
username_0
ping @cloudhead @lukeapage @username_2 @username_1 @Synchro @SomMeri
comment
created
seven-phases-max
username_1
See #1546 (also related to #1328).
(It's not really about *evaluating variables* its more about recognizing a list of selectors in a variable value. For sure, the feature (if implemented) should not involve any escaping as it's has the [directly opposite purpose](http://lesscss.org/features/#features-overview-feature-escaping)).
comment
closed
seven-phases-max
username_1
issue
created
seven-phases-max
username_1
Closing as duplicate of #1546.
comment
created
matthew-dean
username_2
Right. In this case, you're dumping in a string value as is. Less doesn't know what's in the string.
comment
created
cusspvz
username_0
@username_1 @username_2 thank you for your answers. Is there anything I could do to help less to recognize selectors as a variable value?
comment
created
seven-phases-max
username_1
It's a sort of complicated thing unfortunately. As the feature may require some less or more major things here and there to be reworked/refactored and potentially may require (at least the way I see it) a complete change of how selectors are stored in the tree internally. There were some discussions spread all over a few threads (so I can't redirect you to any particular one for a detailed info), but the main question to decide was about if we'll need a special `selector` function or not (this then affect what of two routes the code will go and how drastical it could be since internally the selector-tree-storage actually affects quite a lot of the core features (e.g. mixin/extend look-up) and will affect a lot of other proposed features (e.g. mixin/extend look-up of the interpolated selector etc.). Initially none such feature as selector interpolation was exist at all so the selector-tree-storage was designed w/o anything like that in mind, so many new related features later come as quite dirty hacks on top of each other (and will become more and more dirty and difficult to improve w/o refactoring).

In other words, to do something one will need to learn how all this works now and then find/estimate what can be done to improve it (or a sort of).
comment
created
matthew-dean
username_2
This is fixed in #1421.
comment