-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
sass-convert needs options for syntax operators #1018
Comments
I'm not sure what you're requesting. What is a "syntax operator"? Can you give an example of the output you're getting versus the output you want? |
Basically he wants |
More than that—I want options that would have output similar to this: http://css2sass.heroku.com/ Sorry if I'm using incorrect wording, but when I say syntax operators in this case, I'm specifically speaking about closing comments, including semicolons at the end of declarations, and closing curly braces for style blocks. So for an example, I would have this css:
And the output would be something like this:
|
Are you kidding?
|
The css2sass app is actually implemented in terms of |
I'm aware this has been submitted as a bug before, both when this was haml and after it was branched off but I feel it's warranted enough to bring up again:
There should be options in the
sass-convert
cli to include syntax operators such as brackets, closing comments, and semicolons.Given that the primary use case that I can imagine for using
sass-convert
is to reverse engineer legacy styles to be folded into a new framework, not including options for these syntax operators essentially renders all reverse-engineered styling incompatible with any library that doesn't follow this flavor of writing sass.While I understand that it is valid sass to omit these syntax operators, that doesn't necessarily mean that everyone does or should write sass the same way. I personally find it annoying to rely solely on whitespace for my code, and find it harder to read sass wihtout brackets—with or without syntax highlighting.
Such opinionated approaches to tools are annoying and inflexible to use.
And while it doesn't seem to be a valid point to certain contributors, I do think it is worth noting that almost all syntax highlighting tools that I can find either take a huge performance hit or fail to properly highlight this bespoke syntax outright.
The text was updated successfully, but these errors were encountered: