☂️ CSS Parser

[ematipico]

Description

This is an umbrella issue to track the works of the CSS parser.

The lexer of the CSS parser should be ready, so now it's time to start working on the parser itself.

We should already have a basic syntax, although it's possible that some grammar or cases are not covered, so it's highly* suggested to always make sure we have to nodes to represent a specific grammar.

Resources:

• The original spec https://drafts.csswg.org/css-syntax/#parser-entry-points, it should give us all the information to parse CSS stylesheets correctly
• Use CSS tree https://csstree.github.io/docs/syntax/, which gives visual tools for better understanding parsing rules. e.g. parsing a declaration

Let's remember that Biome parser needs to be recoverable, so we have to consider invalid cases and ensure that the parser can recover itself and resume parsing in a fancy matter.

How to contribute

Before starting, please wait for us to implement the testing infrastructure. In the meantime, you can take a look at the JS parser and JSON parser to understand how the parsing works, the internal APIs, the recovery system, etc.

In this very issue, add a comment saying you want to work on a specific task(s). We will create the issue for you and eventually assign it to:

Note

In order to have the issue assigned to you, you must comment on the issue.,

Prior work

You can the previous Rome's (TS) implementation of the parser: https://github.com/rome/tools/blob/archived-js/internal/css-parser/parser/rules.ts

Before starting

• Create a new test infrastructure for the CSS parser
• Write instructions to run the CSS test infra

CSS parser tasks

• parse class selector https://csstree.github.io/docs/syntax/#Type:class-selector
• parse id selector https://csstree.github.io/docs/syntax/#Type:id-selector
• parse attribute selector https://csstree.github.io/docs/syntax/#Type:attribute-selector
• parse pseudo element selector
• parse pseudo classes selector
• parse simple block https://drafts.csswg.org/css-syntax/#consume-simple-block
• parse declaration https://csstree.github.io/docs/syntax/#Type:declaration
• parse declaration list https://csstree.github.io/docs/syntax/#Type:declaration-list
• parse function https://drafts.csswg.org/css-syntax/#consume-function
• CSS Parser nesting  #1664

Parsing at-rules

At-rules are very strict, and they have a determined syntax. Let us adhere to that.

• parse charset https://developer.mozilla.org/en-US/docs/Web/CSS/@charset
• parse color-profile https://developer.mozilla.org/en-US/docs/Web/CSS/@color-profile
• CSS parse: parse container at rule #995
• parse counter-style https://developer.mozilla.org/en-US/docs/Web/CSS/@counter-style
• CSS Parser: parse document at rule #1303
• CSS Parser font face at rule #1030
• CSS Parser: parse font feature values  #1282
• CSS Parser: parse font palette values at rule #1262
• CSS Parser: parse import  #1408
• CSS Parser: parse keyframes  #1268
• CSS Parser: parse layer  #1320
• CSS Parse media at rule #1049
• parse namespace https://developer.mozilla.org/en-US/docs/Web/CSS/@namespace
• CSS Parser: parse page at rule #1310
• CSS Parser: parse property at rule #1333
• CSS Parser: parse scope at rule  #1334
• CSS Parser: parse starting-style at rule #1478
• CSS Parser: parse supports  #1330
• 📎 CSS parser parses sequence of custom idents for @font-feature-values #1743

Ideas

... more to come

[kubijo]

Forgive me if this is a dumb question, but isn't there a chance for you to reuse a lot of what lightningcss does? As far as I know they use some rust crates written by Mozilla for Firefox, so it should be a very solid base...

[ematipico]

Forgive me if this is a dumb question, but isn't there a chance for you to reuse a lot of what lightningcss does? As far as I know they use some rust crates written by Mozilla for Firefox, so it should be a very solid base...

We did consider it. While doing some research we reached out to Devon, and he suggested to not use that crate (the Mozilla one) because it wouldn't fit our CST.

I also created a PoC some time ago, and I can confirm that unfortunately that crate has some limitations for us.

[kubijo]

Oh… ok, that's a shame. So there is no prior art for you then, given your architecture?

[denbezrukov]

I'm going to return to this task the next monday🙃

[denbezrukov]

I've updated the issue to start parsing properties.
source: https://github.com/parcel-bundler/lightningcss/tree/master/src/properties

[faultyserver]

I created #1359 to track implementing the CSS-wide keywords as tokens and making them invalid as custom identifiers.

[faultyserver]

I've gotten part way through implementing some infrastructure to enable exact parsing of individual properties, but I'm realizing that it will require some changes to the parser itself to support checkpoint rewinding (similar to how the JS parser already works), since there's ambiguity about whether a parsed value is valid until reaching the end of the value definition (i.e., the ; at the end of the line). I'll probably try to build out that checkpointing in a separate PR first and then utilize it in this work, and then from there we should be able to start parsing a lot of properties directly!

I'll open an issue for tracking that work either later tonight or tomorrow.

[denbezrukov]

#1472 (comment)

[Gami13]

Could I start working on implementing the other properties in a matter similar to the border one or are you working on a better solution?

[ematipico]

@Gami13 do you mean this issue? #1454

If so, yes, feel free to comment the issue and I will assign it to you

[denbezrukov]

I think that we want to keep property parsing as it is now. We want to have properties at a semantic level.

cc @faultyserver

[denbezrukov]

@Gami13
You can try to implement #1333 if you want.

[Gami13]

@ematipico yeah, exactly but for the other properties like align, background etc. assuming the way its done in the border one is close to final, I could work on implementing it for the rest

[faultyserver]

assuming the way its done in the border one is close to final, I could work on implementing it for the rest

@Gami13 as Denis mentioned, after investigating with #1453 and discussing afterward, we are most likely going to keep the parser generic, just parsing component value lists for each property, and then have the analyzers do the actual semantic parsing to get the real values for each rule. There's just too much context and evaluation needed for this to be feasible in a parser, and it will be much easier with an evaluation engine in the analyzer as well.

So, unfortunately, please ignore how the border property is being parsed, it will be removed eventually and returned to being generic. The best place to add new features in the parser would be the remaining @-rules like #1333 that Denis mentioned

[bjoroen]

Hello,
I would love to get more involved with this project, is there any of the properties issues that would be good for me to start with? Or is there anything else that needs to be done?

[denbezrukov]

@bjoroen
I believe it's better to look at #1285
However, you could take #1743

[bjoroen]

@denbezrukov I could take #1743 if it's possible.

[bjoroen]

You can assign #1743 to me, and I'll take a look at it tomorrow.

[ematipico]

@bjoroen you have to comment on the issue, so we can assign that to you. That's how GitHub works