-
Notifications
You must be signed in to change notification settings - Fork 10.6k
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
Normalize.Sass #450
Comments
I don't think the main reasons that the contributors don't want to use SASS are related to a learning curve. A SASS file would be another file to maintain and deal with distributing and hosting. You don't need a stylesheet to be in SASS to use it with other SASS styles (also applies to other preprocessors), and there helpful tools (like this) to convert CSS to other preprocessors like SASS. Also, supporting languages other than CSS could cause a slippery slope of choosing which languages to support. |
Then why sass? Why not stylus or less? Maybe versions for all three? I don't think that's a conversation that normalize needs to have or a choice it needs to make when the current choice of css works great for all. I'm a huge fan of sass but still don't see any benefits to this. |
@TheJaredWilcurt I’m using a npm postinstall like described here to rename the file from |
I was typing this up on my phone for my other issue and it was closef in the process, since I can't reopen it I'm just making a new one.
Not everyone uses grunt/gulp. Normalize is something beginners will be using to learn. And beginners who learn more advanced stuff are more likely to run into a GUI based pre-processor like Scout, Koala, Prepros, Hammer, Mixture, etc, than they are to set up all the text files by hand to automate the processes those GUIs perform. For those with the know-how already, having more options doesn't hurt. Sass would be producing an identical css file AND minified css file which Normalize isn't even doing now. This is an improvement.
Having to go to a third party to get a Sass version means you ALSO have to come here anyways to make sure it's up to date. Additionally it means that it won't get the same level of attention as it would if it were part of the main repo. If it's from a third party, that means you don't know if their version is reputable. You'd have to manually go line by line to make sure the third party person converted it correctly and at that point it's quicker to just do it by hand anyway. Having a Sass version as part of the repo by default just acts as a time saver so I don't have to manually do it myself each time there is an update.
It's obvious there are people who want this. I don't understand the resistance to this request. It's a developer desired feature, it saves time, and has the benefit of automatically maintaining the 3 most common style files (.sass, .css, .min.css). This is wins all around.
The only reasons not to do this is:
There now this has been made public for the open source community to weigh in on. So you can now feel free to passive-aggressively close this ticket by quoting the same mantra you have to the many others making this request.
The text was updated successfully, but these errors were encountered: