-
-
Notifications
You must be signed in to change notification settings - Fork 475
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(css_parser): fix the CSS parser doesn't support nested selectors with pseudo-classes #3287 #3318
Conversation
CodSpeed Performance ReportMerging #3318 will degrade performances by 8.45%Comparing Summary
Benchmarks breakdown
|
It seems your last commit fixes the perf regression: https://codspeed.io/biomejs/biome/branches/fix/css-pseudo-classes |
@ematipico Hm, I need to check the snapshots, though. I might break something😥 I'd like to try one more approach by checking the identifier after |
What are you trying to solve? What are you trying to distinguish? It isn't clear from the issue or the PR description |
Sorry for the misleading description. I'm trying to distinguish this example:
A nested selector with a pseudo-class has the same structure as a declaration: [indent][colon] I've tried to parse a nested selector and, if we encountered an error, to reparse it as a declaration. It worked but had a negative performance impact. Now, I am trying to parse a declaration and reparse it as a selector if it fails. One more idea is to check all possible pseudo-class selectors. |
Can't we break down the parsing of the selector to a minimum? For example, we know that if we find a So we could do the parsing until biome/crates/biome_js_parser/src/syntax/function.rs Lines 618 to 620 in a512d81
|
You're right. I've tried both approaches; however, when I tried to parse as a nested selector, we experienced a performance degradation. But vice versa, we don't face the performance issue because we don't have test cases with nested selectors. |
Yeah, I understand now. I wonder if we should check how other parsers solved this issue |
I thought about it more, and I think we should attempt the parsing of declarations first, then fallback to selectors. Nested selectors are a newer syntax, less spread across the current CSS files. Plus, ignoring how old their grammar is, I believe it's more probable to find declarations inside a selector, not other nested selectors. |
Yeah, I agree. Let’s try to keep this approach. Anyway, I’d like to try comparing the next token after a colon. Actually, it can just be a range comparison and shouldn’t introduce a huge impact in theory. |
…with pseudo-classes #3287
e7dc56f
to
19cc053
Compare
I've checked the Lightlight CSS library, and they have a logic where they first parse as a declaration and, if it fails, they parse as a rule. I'd suggest choosing this approach. |
Looks good to me! |
Summary
Fix #3287
Details see #3287
Test Plan
cargo test