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

Normalize.Sass #450

Closed
TheJaredWilcurt opened this issue May 13, 2015 · 3 comments
Closed

Normalize.Sass #450

TheJaredWilcurt opened this issue May 13, 2015 · 3 comments

Comments

@TheJaredWilcurt
Copy link

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:

  1. The maintainers are not familiar with Sass. (It's super easy to learn, takes about a week or two to get the whole thing.)
  2. The maintainers think Normalize is a long-term project that could outlast Sass (a technology that could be replaced by something else in the future). It doesn't matter because the project can be switched to the new thing or back to plain CSS if that's ever the case, but for the foreseeable future at least we can have the benefits.

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.

@nickserv
Copy link

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.

@fleeting
Copy link

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.

@isellsoap
Copy link

@TheJaredWilcurt I’m using a npm postinstall like described here to rename the file from .css to .scss. It’s a pretty simple and efficient fix.

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

No branches or pull requests

4 participants