Great! I don’t want to put you to any bother, but could you please in the next step replace webpack and npm?

Parsing CSS is really annoying because test suits assume that you want have the same experience as you do with browsers which is that you can throw a lot of crap at it and it still works

But if you want to have a fairly standard compliant parser then I have one. It’s based of the CSS spec, it’s I believe only failing because I have to match test suits:

It doesn’t not yet support the nesting tricks that postcss and sass use.

My intent was and is still to have something akin on styled components available for Elixir. It’s just sometimes hard to find time

I actually wrote my own html DSL: html_writer

but for CSS if there are more people interested we could do something more advanced, think something like Ecto.

Yeap, closed with “wont-fix”. Which is funny given it’s a draft for a spec extension.
I sometimes don’t understand how this works. It’s not like there’s no prior art. Sass is from 2006, less is from 2009, they’re the most widely used pre-processors and introduced this idea.

Along comes the opportunity a new spec and instead of using the ideas that prompted the spec, they change them to the point they’re incompatible with what people already showed they preferred, while still introducing complexity (or more) and worse readability.

Great idea. If you are introducing elixir grammar into CSS, I’d like to see something that is completely elixir; ie a full set of elixir macros and functions to write CSS in 100% elixir grammar, sort of like what ecto does for SQL.

The current landscape of various CSS techs is sad. The only thing that has momentum is tailwind, and it is incredibly slow to compile. Also the new version has the brilliant idea of changing whitespace-no-wrap to whitespace-nowrap for no apparent reason.