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

Add sass file #557

Closed
wants to merge 1 commit into from
Closed

Add sass file #557

wants to merge 1 commit into from

Conversation

ppsirius
Copy link

On github we can find many repo with normalize in sass, why don't make this file on official repository?

  • file ready to import
  • output css a half smaller than file with comments

@battaglr
Copy link
Contributor

@ppsirius, hi! Thank you for taking the time to do this! Preprocessors or transpilers such as Sass have been the topic of many issues, such as #450, #446, #290, and the list goes on and on.

Before releasing v4 we considered this, since it has been asked many times, but we really couldn't find what value could it bring.

In all preprocessors/transpilers that I know of, you can import a vanilla CSS file; and while I agree "silent" comments are great, that doesn't justify maintaining two different files. If we decided to merge this, what about Less or Stylus, or any flavour of PostCSS, which would be our argument to not accept them —or end up maintaining lots of different files with mostly different extensiones?

@ppsirius
Copy link
Author

I agree with you, You should add other preprocessors. This files give us possibility to clean fast comments in output. Reducing the file size from 7kb to 3kb i think is enough reason. Otherwise on github you will see a bunch of duplicated repo.

@TrySound
Copy link

@ppsirius If you care about style size use css minifiers. If you use preprocessors I think it's not so big deal to add something in pipe.

@TrySound
Copy link

@ppsirius Your way is opposite to DRY.

@greypants
Copy link

For a while trying to @import css files would default to the native css @import and link to an external file rather than pull in the file directly like it does with scss/sass.

This was fixed in libsass and now works fine if you leave off the .css extension.

I added this to my sass options:

includePaths: [
  "./node_modules/normalize.css"
]

And can @import the normalize.css file just fine in my main .sass file.

@import normalize
// works!

HOWEVER, @battaglr, this is still an issue in Ruby Sass, and duplicating normalize.css as normalize.scss in this repo, would fix the problem for a lot of people. This project (normalize) was the use case mentioned in the issue.

There is a workaround, and this might be addressed in Sass 4, but in the meantime, this seems like an easy add and an easy win. Like @ppsirius said, it would remove the need for forks like https://github.com/JohnAlbin/normalize-scss

@battaglr
Copy link
Contributor

@ppsirius, please, keep in mind that development code is not the place for optimizations such as this one —if you're concerned with size, as @TrySound suggested, in your production code you may consider using a minifier. Please, don't forget that the detailed comments are an important aspect of this project.

@greypants, hi! Thanks for correcting me on this; I didn't know Ruby Sass had this behaviour. I'm not in charge of making any decisions, but regardless of how easy or difficult including this here could be, usually the best/right thing to do is to put the energy on solving the problems or limitations of a given project in said project, and not trying patch other projects because said problems or limitations. FWIW @chriseppstein himself wrote a gem to fix that: sass-css-importer.

@jonathantneal
Copy link
Contributor

It’s a noble idea, but if or when we introduce a Sass, Scss, Stylus, or Less version, or any other version, it will be generated from a true CSS source. Perhaps PostCSS can do this. May all of these extensions be generated in PostCSS?

For now, we must not repeat ourselves. I allowed for this in sanitize.css and now upgrades are a beast. So, I have experience going the other way, and I can say with confidence that it has hurt the project.

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

Successfully merging this pull request may close these issues.

5 participants