Support arbitrary `@`-blocks about css

[lydell]

Lots of the parsing code and most of the AST documentation is about the myriad of different at-rules. I’d suggest we’d parse them like this instead:

• type: 'at-rule'
• name: String. The part directly after the @, such as “media”, “viewport”, “charset”, “whatever”.
• value: String. The part that comes after the name, and before the ; or {. This string may be empty.
• declarations: Array of nodes with the types declaration and comment, or null. If the at-rule has a block, and that block can be parsed as declarations this property represents those declarations. Otherwise it is null. @page is an example.
• rules: Array of nodes with the types rule, at-rule and comment, or null. If the at-rule has a block, and that block can be parsed as rules this property represents those rules. Otherwise it is null. @media is an example.

All at-rules have .value. Some have .declarations. Some have .rules. Some have neither (such as @charset), but none have both.

Pros:

• Future at-rules automatically supported.
• Simpler code.
• Less properties to know about in the AST: no more .media, .document, .charset, etc.—just .value!
• Less documentation to read.
• Consistent with the rest of the parsing: Only parse syntax, not semantics.

This would be for css 3.0.

[necolas]

Yeah that sounds good.

[DracoBlue]

👍

[mtlehtin]

+1

We have the same issue when parsin third party css (AlloyUI)

@-ms-viewport {
  .wrapper {
    width: device-width; } }

@-ms-keyframes progress-bar-stripes {
  .aui from {
    background-position: 40px 0; }
  .aui to {
    background-position: 0 0; } }

Is causing error: missing '}'