CSS AST

[wooorm]

Shawn did some early work mapping a CSS (sass, scss, less, ...) syntax tree to unist in sast. Maybe we can standardise it into it’s own re* ecosystem? It’s based on gonzales.

Now, making an organisation around this isn’t very hard, as @ChristianMurphy recently showed with redot. Creating an ecosystem with useful plugins is and that takes up a lot of time. A few years ago I created rehype because I wanted to lint HTML. Parsing HTML isn’t very hard, so creating the processor was relatively easy. Validating HTML is. And I still haven’t been able to finish the linting plugin.

So, although I think this is super interesting, and some of the ground work is done already, I’m wondering:

• What’s the benefit of creating a unist namespace for css, and a unified processor around it? There’s already postcss around and it’s pretty established.
• Should related languages like sass, scss, less be supported?
• Should gonzales be used as a base?

/CC @shawnbot @ChristianMurphy

[shawnbot]

Hello there! Thanks for the intro, Titus. I agree that the biggest hurdle in doing this would be justifying the introduction of a brand new toolchain in a world where postcss already has a huge ecosystem and community. I made sast because I was looking to use unist tools to query SCSS files, which culminated in stylegrep. I used that tool to perform some analysis on a large SCSS codebase, but quickly realized that a lot of the queries I ended up running were easier to do with grep or ack; so I'm not totally convinced that sast's existence is even justified.

I've got a bunch of other random thoughts, but just wanted to float that first for y'all to chew on. What do you think?

[wooorm]

My first thought is that I'm super interested in all those other random thoughts of you! 👍

And stylegrep is coool!

[ChristianMurphy]

Sounds good. :+1: Postcss is good, and it comes with less and sass support. :tada: There could be a challenge mapping linked elements to children. :thinking: That's something I ran into with Redot.

[ChristianMurphy]

There could be a challenge mapping linked elements to children

My main worry how

a i {
  color: blue;
}

Would parse, since it could have children of type selector or declaration. It looks like Postcss doesn't parse selectors into nodes, so this wouldn't be an issue.

{
  "type": "rule",
  "selector": "a i",
  "nodes": [{
    "type": "decl",
    "prop": "color",
    "value": "blue"
  }]
}

[wooorm]

https://github.com/csstree/csstree/blob/master/docs/ast.md

[shawnbot]

Sorry, I got distracted this week! I still owe you two some other thoughts.

Quickly, though: I actually like that csstree AST a lot more than the gonzales-pe one, which has some quirks. For instance, property declarations have the property, delimiter, any whitespace, and value as their direct descendants, which makes it hard/weird to find property/value pairs with CSS selectors because you have to use sibling selectors, e.g. property[name=background] ~ value:not(:has(variable)). Being able to do property[name=background]:not(:has(variable)) would be ideal, and I think a bit faster.

[ChristianMurphy]

Thanks for starting the discussion @wooorm ! We're in the process unifying ideas in with discussions https://github.com/unifiedjs/collective/issues/44 If you'd like to continue this thread, or start a new one https://github.com/unifiedjs/unified/discussions will be the home for ideas going forward.