As you may have heard, Tab Atkins has been proposing things here and there on the www-style mailing list for the past few months now, including css variables, mixins, and nested rules (in that order). I decided to write my own CSS preprocessor which would only implement things that could potentially become a standard. (As it stands now, the preprocessors that do implement these things add a lot of other features as well).

When I was writing the lexer, I noticed something very strange about nested rules. They're slightly awkward to tokenize. As you're walking through a rule's properties, suddenly you hit a curly brace. What happened? Oh, it must be a nested rule...so that means the thing you started tokenizing as a property isn't a property at all. Instead, it's a selector. Now you need to do a lookbehind or grab whatever you have buffered to get what you now know as a selector and exclude it from the properties.

Obviously, once you have everything tokenized, the rest is easy, but the syntax of nested rules just felt wrong to me originally.

Later on, I realized at-rules and rules are essentially the same thing syntactically now. At-rules can contain properties (@viewport, @trait) or rules/at-rules (@media, @keyframes). Similarly, rules can obviously contain properties, but they can also contain nested rules, as well as at-rules (@mixin). Rules are almost exactly the same now. So I guess it simplifies it to a degree: when you're lexing the inner part of a rule or at-rule, you still don't know whether you're in a selector or property name until you hit a curly brace, but there's a certain amount of luxury here: you can tokenize rules and at-rules exactly the same.

Maybe it's just CSS syntax that is odd. It is pretty inconsistent when you think about it. For example, as I somewhat mentioned above, there are 3 different classifications at-rules can fit into. There's the single-line at-rules which are terminated by a semicolon (@charset, @var, etc). There's the at-rules with depth and curly braces that contain rules as well as other at-rules.Finally, there's the at-rules that only contain properties.

None of these at-rules are explicitly defined as such. Only once you're half-way through parsing them can you determine what kind of at-rule they are.

CSS is probably the strangest, most misunderstood thing there is in web development, ...which isn't a criticism. Although I can, and sometimes do, criticize CSS for a lot of things, I do like it, and I like using it.

As for these new potential features of CSS, I was originally of the opinion that things should be kept simple, and at the most, CSS variables should be implemented, but mixins and nested rules are starting to grow on me.