"Selector Interpolation with Extend" possibly contains outdated info (doc states not supported, but works)

[krsdcbl]

https://lesscss.org/features/#extend-feature-selector-interpolation-with-extend The section opens with the example:

Selector with variable will not be matched:

@variable: .bucket;
@{variable} { // interpolated selector
color: blue;
}
.some-class:extend(.bucket) {} // does nothing, no match is found

However, this does seem to work (at least since LESS v4.1.0):

@selector: e('.example');
@{selector} {  content: 'testing :extend ONTO interpolated selector';  }

.test-1:extend( @{selector} ) {  content: 'doesnt work, as expected';  }
.test-2:extend( .example ) {  content: 'does work, contrary to doc';  }

[iChenLei]

Hi, guys. I transfer this issue from less/less-docs to less/less.js just now.

[matthew-dean]

@iChenLei ~Note, if this does work, it should still have a Less/CSS test demonstrating the functionality so we can test for regression.~

On second thought, I'm wondering if this should be an officially supported feature or not. 🤔

[krsdcbl]

@matthew-dean good point, maybe i did actually stumple upon a bug here 🤔

After some quick testing with https://www.lesstester.com/ - my code sample above:

• doesn't work in LESS 3.0 & older
• does work in LESS 3.5 & newer

Don't really know if its intentional or if it may have possible adverse effects. All I can say is I've been using recently and It's proven very useful in some specific cases, and didn't seem to create any issues (as far as i can currently judge)

[matthew-dean]

@krsdcbl The reason why this works is because I introduced the idea in Less 3.5 of importing the parser and re-parsing an evaluated value within the selector. So the evaluated value gets re-parsed into a selector. Hence, it's found.

However, I no longer think this is a great idea. Ideally, the parser and evaluation engines are not going back and forth and re-doing work, and they would be distinct stages (other than some very light regex parsing). It just makes the flow a little bit more complicated.

But... it's possible this might be possible without re-parsing (although not with the string example); but it's hard to say, so I'd rather not add this as a documented (supported) feature, as documentation implies future support. So I would call this relying on unsupported behavior which may break in the future.

[krsdcbl]

@matthew-dean thanks for the explanation! That's a pity, unintenional as it may be its serving me quite well right now :D

But i totally see why this could become a problem when used on a larger scale than my 2-3 components that leverage this to enable extending variants onto the config-defined selectors of their respective base variants.

I guess my specific use is a rather niche application anyway and shouldn't be supported if it goes against the languages conventions & performance standards, or creates unnecessary overhead. I'll annotate the few cases where I used it & expect it to break sometime in the future, thx very much for the insight!

Out of curiosity, and sorry if I'm going off topic: but is this by any chance related to the reason :extend doesn't take interpolated selectors as a parameter?