Repository navigation
"Selector Interpolation with Extend" possibly contains outdated info (doc states not supported, but works) #4228
Description
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'; }
Activity
iChenLei commentedon Sep 4, 2023
Hi, guys. I transfer this issue from
less/less-docstoless/less.jsjust now.matthew-dean commentedon Sep 6, 2023
@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 commentedon Sep 7, 2023
@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:
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 commentedon Sep 12, 2023
@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 commentedon Sep 12, 2023
@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
:extenddoesn't take interpolated selectors as a parameter?[-]"Selector Interpolation with Extend" possibly contains outdated info[/-][+]"Selector Interpolation with Extend" possibly contains outdated info (doc states not supported, but works)[/+]