Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support arbitrary @-blocks #16

Closed
necolas opened this issue Jun 4, 2014 · 4 comments
Closed

Support arbitrary @-blocks #16

necolas opened this issue Jun 4, 2014 · 4 comments

Comments

@necolas
Copy link
Contributor

necolas commented Jun 4, 2014

There's also @viewport (and -ms, -webkit, -o prefixed versions) and probably some others that I've forgotten or don't know about. People building preprocessors might also want to use custom @-rules.

(Moved from https://github.com/reworkcss/css-stringify/issues/9)

@lydell
Copy link
Contributor

lydell commented Jun 19, 2014

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
Copy link
Contributor Author

necolas commented Jun 19, 2014

Yeah that sounds good.

@DracoBlue
Copy link

👍

@mtlehtin
Copy link

mtlehtin commented Jun 8, 2016

+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 '}'

@necolas necolas closed this as completed Apr 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants