Maybe this isn't strictly a bug report. I found the similar issue report (https://github.com/less/less.js/issues/2709) but this might be more of a feature request? that how I wish Less compiler works.
Assuming you have a mixin and a class, both named .overlay,
you know, applying .overlay to an element gives different outcomes depending on how you reference said mixin or class. Now please take a look at the following use cases.
.case-A referenced .overlay without parens, so it matched with both the mixin and the class.
.case-C referenced .overlay with an argument, so it matched only with the mixin.
And the both behaviors make sense to me (yes, I know calling a mixin without parens is deprecated).
But in .case-B, .overlay with empty parens also matched with both the mixin and the class, leading the exact same result as .case-A.
And this behavior was unexpected to me, because I intuitively expected that referencing a mixin with parens always match with the mixin only, even if there is a class with the same name as the mixin, so the result for .case-B would be this:
/* My expectation for .case-B */
.case-B {
z-index: 0;
width: 100%;
height: 100%;
}
If the current behavior is not a bug, my expectation for the behavior would be more intuitive and consistent, and also more beneficial to most users, if the behavior was exactly like this:
Referencing with parens => matches with mixins only
Referencing without parens => matches with classes only (This also means completely deprecating referencing mixins without parens)
Environment information:
less version: 4.2.0 (I used lessc command to compile)
nodejs version: 18.17.1
operating system: macos
Again, this might not be a bug report strictly, but more kind of a feature request.
The issue may not be critical and there are some easy workarounds for it for sure. I just love Less as a CSS pre-processor.
Thank you for reading. Thank you always for your hard work :) @developer
Maybe this isn't strictly a bug report. I found the similar issue report (https://github.com/less/less.js/issues/2709) but this might be more of a feature request? that how I wish Less compiler works.
To reproduce:
Example Code:
Assuming you have a mixin and a class, both named
.overlay
, you know, applying.overlay
to an element gives different outcomes depending on how you reference said mixin or class. Now please take a look at the following use cases.Example use cases:
This code compiles into this (current behavior):
.case-A
referenced.overlay
without parens, so it matched with both the mixin and the class..case-C
referenced.overlay
with an argument, so it matched only with the mixin. And the both behaviors make sense to me (yes, I know calling a mixin without parens is deprecated).But in
.case-B
,.overlay
with empty parens also matched with both the mixin and the class, leading the exact same result as.case-A
. And this behavior was unexpected to me, because I intuitively expected that referencing a mixin with parens always match with the mixin only, even if there is a class with the same name as the mixin, so the result for.case-B
would be this:If the current behavior is not a bug, my expectation for the behavior would be more intuitive and consistent, and also more beneficial to most users, if the behavior was exactly like this:
Environment information:
less
version: 4.2.0 (I usedlessc
command to compile)nodejs
version: 18.17.1operating system
: macosAgain, this might not be a bug report strictly, but more kind of a feature request. The issue may not be critical and there are some easy workarounds for it for sure. I just love Less as a CSS pre-processor. Thank you for reading. Thank you always for your hard work :) @developer