Make compass an optional dependency

[yckart]

Since the people cry for a world without dependencies, we should drop compass. Or, at least, we should stick together a version without compass.

For sure, there are a lot of great forks out there, but you are the leader at NPM, RubyGem etc.

After a bit of research I found this gist, which could help us: https://gist.github.com/ry5n/2026666

[gussyboy]

This is a awesome suggestion, I've just dropped compass due to its ruby dependency. Be great to have a non compass version too. Personally I'm now using autoprefixer for browser support prefixing.

[nicky-lenaers]

I would LOVE to see a non-compass version aswell! Please provide!

[gussyboy]

As compass is now dead, time to move over to Eye Glass?

[JohnAlbin]

@gussyboy Link that says Compass has been abandoned?

[himedlooff]

I think a non-Compass version would be useful as well, so that I can keep all of my deps in Node.

[JohnAlbin]

I see Chris Epstein is working on Eyeglass instead of Compass now. https://github.com/sass-eyeglass/eyeglass

Ok then!

[chrisvanpatten]

Another +1 on this... Compass helpers are nice but with a lot of that compatibility tooling moving toward autoprefixer and the like, it seems less useful.

[Undistraction]

Fewer and fewer people are using Compass. Please ditch the dependency.

[JohnAlbin]

Starting on this. I need it too.

[AdamWills]

Anything I can help out with here?

[esr360]

+1 for optional Compass support. I don't use it.

[francisfeng]

Was looking for a version without compass. Really looking forward to it.

[JohnAlbin]

If anyone wants to help out, take a look at the 4.x branch. https://github.com/JohnAlbin/normalize-scss/tree/4.x

[JamesVanWaza]

@JohnAlbin I installed Normalize scss, but when I run grunt, I can't find the following files below, kindly let me know where they are located.

[AdamWills]

@jgacuca567 These references aren't to files - but referring to Compass specific functionality - http://compass-style.org/. You'll need to have Compass installed to run this in it's current state.

This thread is about removing the Compass dependancies.

[JamesVanWaza]

@AdamWills Thanks, Because @compass, is not being used anymore, then normalize that uses compass components should be removed.

I went to the Compass Homepage, but the modules were not on Github so I was unable to copy the files.

[JohnAlbin]

@AdamWills Thanks for responding! I'm not sure why @jgacuca567 isn't understanding your comments. They are are spot on.

Anyway…

If you take a look at the 4.x branch, I've now done the bare minimum to remove Compass.

Can I get some reviews of the work in 4.x before I close this issue?

There's still more work I'd like to do in the 4.x branch before I merge it into master. For example, I'd like to make it so you have to @include normalize(); after you import it, instead of just immediately dumping all the CSS at the point of @import.

[chrisvanpatten]

@johnalbin why would you want to separate the import and the include? Wouldn't you just put the import where you would have put the include to get the same effect with one less line of CSS?

[JamesVanWaza]

@AdamWills, @JohnAlbin , I understand, only problem is with the Compass Homepage where the files cannot be found because the url is incorrect.

[esr360]

Totally agree with @JohnAlbin about being allowed to include it wherever you want using:

@include normalize()

@chrisvanpatten, the reason why this would be beneficial is that it allows you to control exactly where the code is output. You may want to keep the imports organised and chronological or whatever. It just provides you more flexibility and control.

Another reason why you might do this is to be able to customize the code without touching the source code. Perhaps this isn't so much applicable for Normalize, but in theory you could do something like:

@include normalize((
    'option-1'  : true,
    'option-2'  : false
))

This way you can customize the code you serve without touching the source code.

[AdamWills]

I'm with @chrisvanpatten on this one. I use my main sass file as simple a place to import partials. As I would consider normalize a partial as well, and would just use/expect import to work. Adding a second requirement seems a little redundant... but that's just me.

@esr360 - "Perhaps this isn't so much applicable for Normalize" - I think exactly that. If there's things to change, you can do so using variables before calling normalize.

@JohnAlbin - not knowing the history and what this specific repo is doing on top of just a basic sass port of normalize - if there's some more specific things I can help with, perhaps create some issues that some of us could tackle?

[chrisvanpatten]

@chrisvanpatten, the reason why this would be beneficial is that it allows you to control exactly where the code is output. You may want to keep the imports organised and chronological or whatever. It just provides you more flexibility and control.

Yeah, but you can just put @import exactly where you want the code to be output.

Keeping this behaviour would also make the upgrade path easier… just update your gems, no need to change your Sass.

[JohnAlbin]

And… this is why I asked for feedback. :-)

It seems clear that both usages are used by many people. So normalize-scss should support both usages.

Here's 2 options for normalize-scss:

Option 1

// For those of you who prefer to @import a library and @include a mixin:

// Import the library's variables, functions and mixins. Does not output any CSS.
@import "normalize";
// Output the normalize.css.
@include normalize();

// For those of you who prefer to @import the CSS immediately without any other steps:
@import "normalize/import-now";

Option 2

// For those of you who prefer to @import a library and @include a mixin:

// Import the library's variables, functions and mixins. Does not output any CSS.
@import "normalize/library";
// Output the normalize.css.
@include normalize();

// For those of you who prefer to @import the CSS immediately without any other steps:
@import "normalize";

Obviously, option 2 would be the easiest upgrade path since we've never had a normalize mixin before in this normalize-scss library. However, 99% of Sass libraries that I've seen work the way Option 1 does. The convention is that @import "library-name" will load the library and not output any CSS.

Okay, more feedback, please!

[AdamWills]

My standard use for sass libraries uses wiredep, a handy library that takes bower packages and auto inserts them into your project files. This workflow would favour option 2.

Just looking at what other popular sass libraries are doing:

• Twitter Bootstrap - just an import
• Bourbon - just an import
• Susy - just an import
• Gumby - just an import

[JohnAlbin]

@AdamWills Interesting. I'll do some research. Looks like https://github.com/twbs/bootstrap-sass#c-bower has good hints; bower.json needs to point at a Sass stylesheet that outputs CSS when it is imported.

However, you are wrong about Susy. Add @import "susy"; to http://sassmeister.com and you'll see that it outputs zero CSS by default. Same with Bourbon; no CSS is output when you import Bourbon.

That just leaves Bootstrap and Gumby. And that behavior of Bootstrap drives me crazy as it outputs way more CSS than any site could use.

Having said that, I can see the utility of getting the full CSS output of Bootstrap or Normalize just by using the "main" item in bower.json via wiredep.

Are there other usages of Bower's "main" that expect a Sass library and no CSS output? (I hope not.)

[Undistraction]

FWIW, I think separating the act of importing with the act of rendering the styles is a great idea. This kind of control is really helpful in organising Sass code across multiple files, especially if you are aiming for flattened specificity through controlling source order (See ITCSS. Yes it's overkill for a small marketing site, but for large sites and complex webapps, this kind of control is a real boon. Using Bootstrap as a model or example to learn from is a bit like using McDonalds as an example of how to set up a nutritious, ethically sound restaurant IMHO, and I've yet to encounter anyone using Gumby in production. Besides, Bootstrap is doing everything at once, whereas Normalize is doing one focused part. It is such an important part that giving users more control of how it's applied can only be a good thing.

Using a mixin would also allow you to offer customisation, for example:

@include normalize($exclude: print);

[AdamWills]

@JohnAlbin - Looks like I got a little carried away with my examples... I forgot that Susy/Bourbon work by providing the developer mixins to incorporate with their existing code (using your own classes/elements and using their mixins to style).

Bootstrap outputs everything, which yes, does create extra bloat - but you can also import individual partials into your project to cut that down.

I've always used normalize.css as just a drop-in, not worrying about changing/adding/removing to the pieces involved.

How do other people here use it?

[JohnAlbin]

I've updated the README describing all the possible uses that I know of. https://github.com/JohnAlbin/normalize-scss/tree/4.x#how-to-use-it

• (optionally setting variables and then) importing immediately
• (optionally setting variables and then) importing with other libraries and later @includeing the CSS output
• downloading and forking the code

I actually use the third option and putting the normalize.css code into mixins makes it harder to fork. So I'll be adding a "fork-versions" directory with several options for that purpose.

[JohnAlbin]

I just tagged 4.0.0-beta.1 with the work so far. I'm looking for feedback on what doesn't work. Thanks, all!

[JohnAlbin]

I fixed some inconsistencies and bugs. And I've finished the fork versions.

At this point, I think I've incorporated all the feedback above. If I've missed something, please let me know. We can certainly fix it!

Thanks, everyone!

Tagging 4.0.0 now.