Nice, thanks for sharing. I had thought about using nimble_parsec but I would need to learn it properly so just started doing by hand with what I know. Your parsec version does look more organised and less code 
Should I change the title? The project itself is cssex but for putting it here on the forum I chose to write it as ExCSS and just saw that you named yours that.
CSSEx is almost fully featured, I’m writing now the custom functions part and some helpers for using them. It’s missing comments which is basic.
At this point specific validations can be added to every part if it was needed or wanted (I might work on adding further validations incrementally, like asserting that if you’re in a [prop=“val”], you’re using valid =, =~, ^=, equality variant, etc). Outside of proper css spec, adding further things like tree-shaking would be almost “trivial” to if there was already something to extract a hierarchy of css from an html page.
I did read parts of the specification for css2 but the difference when parsing CSS from something as cssex or sass , is that the rules are stricter on CSS and in this you depend on further things inside the blocks to output and validate - once you introduce the concatenation & and you’re inside a block everything goes because almost any character can concatenate to the top level chain to produce a valid selector.
So if you want to verify it you need to evaluate it after the fact (and it also depends if any more concatenation elements are inside this selector as well as they would tag into its trail, because it can be arbitrarily nested).
Then outputting that into css, the same with simple nesting like having media queries inside selectors, you can’t generate the css rule in place, as you have to put the previous selector chain inside the media block and the contents of the media block inside this selector. Then if you do @includes, that brings another file in place that can also be inside arbitrary blocks… Then it needs variables and interpolation and these have to be tossed around too, plus keeping the lines & columns information and parsing step.
At that point you need to carry a bag of things as you parse and store them in other format than plain binary, but it would be interesting to see a fuller implementation just with parsec to see how it ends up looking.
I looked at the tests but I didn’t understand how those are supposed to be run. I’m just writing small chunks of relevant cssex and assert on the output, and some errors/warnings. Once I have the functions finished I’ll translate a fairly complex sass stylesheet (a small css framework I usually use) into cssex to do a final bigger test of correctness and others of speed (as it is I’m seeing significant different between dart-sass 0.15s to cssex 0.01s but these weren’t scientific). Maybe I could use those tests to assert on the generated CSS.
