Skip to content

Facilitate autoprefixer needs #20

@necolas

Description

@necolas

this issue mostly for discussion, but as long as we share ASTs we can have better interoperability. I totally get the need for node-level utilities to inject declarations etc, but I think we could have a suite of tools (or nodes "classes") on top of the vanilla AST

the most "elegant" thing to do would just be piping streams of things that manipulate the CSS, but since that's slow and causes needless re-parsing it would be great if we could either a) make this parser facilitate autoprefixer's needs b) spec the AST to maintain compatibility


@ai said:

I think we should:

  1. Try to parse custom at-rules. By spec, unknown at-rule can contain any content. By all current at-rules (and custom at-rules from frameworks) contains only rules or declarations. The best solution is:

    • Try to detect content type (rules or declarations) by names.
    • Try to parse rules or declarations inside.
    • If we can’t parse rules content, we should store just as string.

    But it is ideal way (in PostCSS I had no time to realize it in PostCSS) :).

    I had a lot of issues from new at-rules or special JS libraries. Also, it is easy to configure some Rework plugins by custom at-rules. Like:

    @sprites {
      padding: 10px
    }
  2. Saves all outside spaces. Of cource, we should do it by special option.

    This is important for text editor and keep style from uncompressing (some users use Autoprefixer after Sass with :compressed output, some users use win text editors).

  3. Integration tests, to understand that we parse most of production CSS. For example, previous version of Rework had issue with parse even Bootstrap. I test GitHub, Twitter, Bootstrap (a lot of hacks for old IE) and Habrahabr (Russian IT Reddit with very bad CSS files as example, how developers can write :) ).

    Bad written CSS is importnat for me, because a lot of Rails project use some 3th part CSS from libraries and had problem with Autoprefixer, because they can’t fix libraries (like Bootstrap).

  4. Saves comments inside values. There is some difficult situation with comments inside declaration’s values and at-rule parameters. We should clean values from comments for Rework plugin developers, but we need to keap origin raw dat with comments to stringify (PostCSS has special hack with raw properties).

But this PostCSS feature is only for integration test. I just check, that PostCSS’s parse/stringify doesn’t change any bite of production styles.

And I will be glad to remove postcss/parse.coffee and use PostCSS only as object high-level API under the css-parse AST.

BTW, I didn’t think that fragmentation is really bad. In real world we support diversity for languages (there is Red List for language) and biologically species (IUCN Red List). Diversity is important to evolution (hieroglyphs is very unusable but we hasn’t “cool” tattoo or Matrix digital rain if China moved to phonetic alphabet). But it is only philosophical note, I think most of Autoprefixer users will be glad to come back to Rework with PostCSS features :).

(Moved from https://github.com/reworkcss/css-parse/issues/68)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions