[no_wizard]

This is amazing! Seen a lot of work around Rust and JS / JSX / TS / TSX (notably SWC[0] is moving to be a Rust based version of Babel) not so much around CSS.

My genunine hope is this will replace PostCSS sooner rather than later. PostCSS isn't the most performant thing I've worked with, and a lot of plugins for PostCSS rely on doing multiple passes at the AST, they can slow down significantly as a result

For that however, we will need some kind of plugin system. I know the SWC[0] project has had some struggles with this as their current JS API relies on serializing the AST back and forth. I wonder if this forgoes a JS API entirely or if that is something planned for say 1.5?

[0]: https://swc.rs/

[devongovett]

Hi, author of Parcel CSS here.

I have been thinking about implementing the CSS OM spec as the JS API. This is the same API that browsers expose for manipulating stylesheets. The advantage of this is that we don't need to invent something custom. Still thinking through options. https://github.com/parcel-bundler/parcel-css/issues/5

That said, I think I'd want to keep the use cases for JS plugins limited, because it will affect performance significantly. So, if it's something that exists in an official CSS spec somewhere (even if draft), or a really common transformation, it should be implemented in Rust. An example of this is the support for the CSS nesting spec. Ideally, we'd try to keep the amount of custom syntax being invented around CSS to a minimum and stick to standard CSS syntax wherever possible though.

[no_wizard]

Separate question, that may be seemingly unrelated however I'm curious.

How did you kinda "learn" how to read these specs effectively? I can read them, and I think I can reasonably understand them, however I feel like I have little confidence in saying yes I get this.

Is there anything you point to that helps? Tips or recommendations?

I'm trying to learn how to parse these standards docs better myself.

[dfabulich]

For a spec about a browser feature, "getting it" can mean a few different things.

1. Understanding the purpose of the feature ("why/when would I use this?")

2. Understanding how to implement the feature

3. Understanding how to use the feature

4. Understanding the feature's "corner cases" (surprising implications, cases where it doesn't do what you'd expect, etc.)

5. Understanding why the feature works the way it does (instead of some other way)

Most of the web specs really only explain how to implement a feature, and even then, they're not great at that, because they do such a poor job at explaining the purpose of the feature.

Assuming that you, like most of us, aren't working on implementing a browser, that means that web specs are mostly unhelpful to you. It's almost completely beyond the purpose of a spec to teach you how to use a feature, what its corner cases would be (which are often unknown at the time a spec was written), and why the specification says what it says.

This is an area where the web spec community has made some improvements in recent years. Nowadays, it's understood that new proposed specifications shouldn't just provide a specification, but also a separate "explainer" document to explain the purpose of the feature, and also persuade the other browser vendors to implement the feature. ("This will be really cool, and here's why…")

At a minimum, specs nowadays often include a non-normative "Motivation" section, as the CSS Nesting spec does. https://www.w3.org/TR/css-nesting-1/ I you'll find that you can "get" that spec much better than you can the CSS OM spec https://www.w3.org/TR/cssom-1/ which is old enough to buy alcohol and doesn't include a "Motivation" section.

You can often find explainer docs linked off of https://chromestatus.com/ e.g. https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/... I think you'll find that explainers are 10000% better for learning features than specs are. (They typically even discuss #3, #4, and #5, as they typically discuss alternative rejected approaches.)

[lucideer]

In addition to dfabulich's excellent comment, I'd also suggest: read specs of tech you're most familiar with first, rather than specs of new cutting edge stuff you're curious about. Doing that will give you huge amounts of extra context because you're just reading something you already know expressed in a different format.

[jafitc]

Is this something that can run in browser Workers via wasm or other means?

Most of CSS OM is already implemented in Javascript which can come in handy for this project:

https://github.com/NV/CSSOM

https://github.com/jsdom/cssstyle

(both of which jsdom use internally. cssstyle is a kind of updated version for some parts of CSSOM)

[devongovett]

Yes, there is a WASM build used by the demo: https://parcel-css.vercel.app

Not sure if we could reuse these packages though, since we'd need to expose an API from Rust to JS anyway.

[andrei_says_]

Does this include dart scss processing?