I can see value in being able to create and represent your stylesheets as JSON objects, but syntactically this seems like a mess to me. For example, here are tw

I can see value in being able to create and represent your stylesheets as JSON objects, but syntactically this seems like a mess to me. For example, here are two things I noticed from a cursory glance at the example code that have their roots in CS's syntax: * The distinction between representing a selector as a JS object and representing it as an immediately-invoked anonymous JS function that evaluates to a JS object is whether or not it declares any local variables. * If your selector has a colon in it (in other words, :hover/:active/:before/:active or any other pseudo-selectors), it needs to be wrapped in quotes. Otherwise, it doesn't need the quotes. Both of these make complete sense when viewed in context of "you're actually writing CoffeeScript", and are sensible solutions to problems you will encounter when writing day-to-day CS. But writing code that compiles down to a static stylesheet is a very different problem than writing business logic: it seems weird to present a DSL where writing two blocks of 'CCSS' code that compile down to nearly-identical blocks of CSS could easily require the two CCSS blocks to superficially look very different due to the accumulation of edge-case language quirks like these. That is to say: CSS has a lot of quirks. CoffeeScript also has some quirks. It seems to me that this doesn't necessarily do a better job of masking CSS's issues than Less/SASS/Stylus, while adding in the mental overhead of dealing with some of CS's syntactic quirks.