Open setyb opened 3 years ago
The bug includes comments or variables inside of the :is() selectors
Example with the Missing closing ')'
error
each(@color, {
:is(.color-@{key},
.focus-color-@{key}:focus,
.hover-color-@{key}:hover) {
color: @value !important;
}
});
Less not support write expression(and comment which contain &()@ character ) in pseudo-class function currently.
🧪 means experimental feature
skuIIs
and setyb
's issue.@selector: p;
:is(@selector) {
color: red;
}
- Missing closing ')'
@color: red;
:is(/* :is */ .color-lei, .color) {
color: @color;
}
compile to
:is(/* :is */ .color-lei, .color) {
color: red;
}
Let's try to debug it ->
:is(/* :is */ .color-lei, .color)
entity was treated like selectors
, :is
and (/* :is */ .color-lei, .color)
are two elements of selectors
.
From a source code(master branch) perspective, we can look the detail of less parse process.
parserInput.$re(/^\([^&()@]+\)/)
match (balabala....)
as a element, but it can't contain &
(
)
and @
otherwise parse fail.
That's why when you add a comment node which contain (
will cause parse fail.
// error
:is([foo], [bar] /* :is(a, b) */, [baz]) {
color: red;
}
// ok
:is([foo], [bar] /* :is */, [baz]) {
color: red;
}
// error
@selector: p;
:is(@selector) {
color: red;
}
// ok
:is(p) {
color: red;
}
I think this is a feature request
and not bug fix
, terminal error message ouput misleading us. The question is Less not support write expression(and comment which contain &()@ character ) in pseudo-class function currently
.
/cc @matthew-dean Sir, How do you thought about this ?
The analysis here is great.
As these new selectors have matured, we've started to investigate moving over to them incrementally, but got bit by this bug. I'm curious if there are any plans to rework the affected parts of the parser that are getting tripped up here.
If not, is there at least a favored approach to resolving it in case we decide to attempt a fix? A cursory, naive read through the parser code suggests that these newer selectors probably would need to be explicitly handled, and that logic could be less strict than the general selector logic here.
I wouldn't mind playing around with a potential fix if the team here is open to it, but I don't want to go down the wrong path in a fix, or duplicate existing work.
@iChenLei @chipx86 So, I've been working off and on for the past 2-3 years (just that long because it's when I have time) on a ground-up re-write of Less parsing and evaluation. (It's actually a parsing and AST library that can support multiple CSS pre-processing languages). I haven't written much about it here because I've considered it sort of experimental and I don't know all the trade-offs, but that is to say that I think that approach probably has more merit than getting too far into the weeds on the current Less parser.
The reason why I feel that's a better approach is because it's divided into separate installable packages:
This is still experimental and pre-alpha, so there's a couple possibilities:
Specifically for this (and some other issues), it also solves a few other problems, in that:
:is()
and :where()
(and others) have proper parsing according to their respective specs.So yeah, just wanted to add that, FWIW. @chipx86 that isn't to say you aren't welcome to improve the current Less parser as-is and submit a PR, since it would still be some time before these particular issues are addressed. Just wanted to offer that as context.
Here are 2 examples of valid code using the
:is
pseudo-class that are not handled by LESS correctly. Can you please allow valid code like this to work with LESS?Tested on: https://lesscss.org/less-preview/ which erroneously issues the error message:
Missing closing ')'
for both examples.See also: https://github.com/openstyles/stylus/issues/1253