Skip to content
This repository has been archived by the owner on Dec 2, 2018. It is now read-only.

Which syntax(es) to support? #80

Open
keithjgrant opened this issue May 12, 2017 · 3 comments
Open

Which syntax(es) to support? #80

keithjgrant opened this issue May 12, 2017 · 3 comments

Comments

@keithjgrant
Copy link
Collaborator

Which syntaxes should we support? Vanilla CSS and Scss?

@keithjgrant
Copy link
Collaborator Author

Misc thoughts/questions:

@ai suggested vanilla CSS, PreCSS, and CSS Modules

If I understand PreCSS correctly, it's very similar to SCSS. I'm not sure what sets CSS Modules syntax apart from vanilla CSS, either—doesn't it just introduce the composes property and that's it?

Is SCSS a superset of vanilla CSS? Can we get away with just supporting SCSS, and if the dev writes vanilla CSS, that's basically automatically included?

@ai
Copy link

ai commented May 12, 2017

PreCSS = nested CSS. So PreCSS is much more simpler than SCSS.

@jeddy3
Copy link

jeddy3 commented May 13, 2017

I suggest starting with support for just standard CSS constructs.

In stylelint we do some gnarly gymnastics to identify and ignore non-standard constructs (see the isStandardSyntax* utils e.g. isStandardSyntaxRule). I don't believe ignoring constructs is an option for an automatic AST formatter because, as mentioned in prettier talk, it must get the format 100% correct.

Also, after my time on stylelint, I feel the same way as David about how non-standard syntaxes are an unnecessary obstacle to CSS tooling.

More of the stylelint team share their thoughts on non-standard syntax support in stylelint (and stylefmt) in stylelint/stylelint#2259.

Once the standard CSS constructs are nailed, then that seems like a good time to discuss how, and if, non-standard syntaxes can/should be supported.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants