Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Have the core sass files available as a component #147

Closed
sungraze opened this Issue Dec 17, 2012 · 9 comments

Comments

Projects
None yet
5 participants

While the plugin is nice as-is (kudos), I would really like to use a tool like bower to manage the core of susy as a package.

It would suffice to add the sass folder to a separate repo and include it within the main repo as a submodule or otherwise. I've set up a repo with a simple component.json to test it with bower and I think it's pretty sweet.

Besides the compass project template are there anymore downsides to not using the full plugin? I've almost never used templates in general so that's fine with me. There's also the perk of having 1 less gem dependency and not editing the config.rb

Of course, you would @import "susy-core/susy" instead of just @import "susy" for this setup:

/project
    /components-land-here/
        /susy-core
        ...
    style.scss

With components-land-here set as my sass_dir.

A workaround would be to hold the susy subfolder in the second repo instead so that component users will have less redundant imports while the shorthand partial stays in the plugin repo.

@import "susy-core/support";
@import "susy-core/units";

@import "susy-core/settings";
@import "susy-core/functions";
@import "susy-core/grid";
@import "susy-core/padding";
@import "susy-core/margin";
@import "susy-core/media";
@import "susy-core/background";

Importing each partial on its own line is a reasonable trade imo and it's also more aligned with the philosophy of small reusable components.

For example, I would like to use units for its rem mixins on a project that doesn't necessarily need a susy grid.

What do you think?

Owner

mirisuzanne commented Dec 17, 2012

Susy is already set up to be managed as a compass plugin gem (with e.g. bundler). Is there a reason that system doesn't take care of what you need?

I've been using the gem so far and it works, the issue is more about having the option to use a subsystem that could fit certain workflows better.

Since Susy seems to work just as well as a drop-in set of partials (why I asked about other downsides) I prefer loading it as such and not worrying about whether the gem is set up (w/o bundler) and required in the config.

I also find it convenient to keep Susy in the same place as the rest of my components/partials because I can jump to the source faster to see what's going on and make some tests/edits instead of digging for the gem or browsing on github for reference, especially since most mixins are not your average 5 liners :)

To put it another way, since Susy is a grid system I would like to not have its roots go so deep within my working environment and be able to easily switch a set of partials with another if I want to try out some other grid system. A package manager would ease the process further in my case so it would be wonderful to take the package "straight from the source".

I think it's a great idea. I've experienced quite a few headaches maintaining the same gem versions across our team and having the Susy files included directly at the the project level, using a component manager like Bower for instance, sounds like a good workflow.

Contributor

scottkellum commented Dec 18, 2012

One down side of using Susy as flat files instead of a gem is if Susy ever moves any math over to Ruby. While a tool like Bower can solve the versioning issues, growth of Susy might break this workflow.

When Modular Scale moved components to Ruby for performance improvements just as Foundation started using it as flat files was very difficult as we were stuck on two different codebases when bugs came in.

@scottkellum I see your point. Was the performance increase significant and is there any chance a sass update might improve things?

Sidetracking a bit from the issue. I played with the ms gem a bit when I found it in Foundation and while I personally like it and I think the theory itself is an elegant thing to add to any design, I can imagine beginners and especially designers who barely got over consolephobia going all "what is this voodoo?". classics: https://twitter.com/Malarkey/status/268728358181941248

So in a broader view of things it's a bummer that great tools like ms or susy aren't easi_er_ to install.

@ericam would you have this issue with susy down the road? I've used 0.x as well so I appreciate what you've done in terms of simplifying so far but I still think it would be adopted/hacked more if the code base split would be possible.

Contributor

Snugug commented Dec 18, 2012

I know that for Sassy Math when I converted it from Sass to Ruby, it went from crashing Sass to having an unnoticeable tick. Similar performance increases happened with Modular Scale. These aren't things that increased Sass performance will solve as it's a cross-compile issue vs native issue.

As for making it easier to install, not a Sass issue, but rather a Compass issue, and really you should reach out to your favorite GUI app and ask them to make installing gems from the app easier.

On Tuesday, December 18, 2012 at 4:49 PM, GreenDude wrote:

@scottkellum (https://github.com/scottkellum) I see your point. Was the performance increase significant and is there any chance a sass update might improve things?
Sidetracking a bit from the issue. I played with the ms gem a bit when I found it in Foundation and while I personally like it and I think the theory itself is an elegant thing to add to any design, I can imagine beginners and especially designers who barely got over consolephobia going all "what is this voodoo?". classics: https://twitter.com/Malarkey/status/268728358181941248
So in a broader view of things it's a bummer that great tools like ms or susy aren't easi_er_ to install.
@ericam (https://github.com/ericam) would you have this issue with susy down the road? I've used 0.x as well so I appreciate what you've done in terms of simplifying so far but I still think it would be adopted/hacked more if the code base split would be possible.


Reply to this email directly or view it on GitHub (ericam#147 (comment)).

Well, the point I was trying to make with the easy install (I agree it's a compass thing) was not about the benefit some people would have from a GUI with better gem support but the fact that we're adding a dependency in ruby for a presentational technique used in CSS. GUI or CLI doesn't matter.

Wouldn't it be nice to write some Sass that makes use of Susy, pass it to whoever, knowing that you only need Sass+Compass (a reasonable core requirement) to compile or edit further? I'll install the full gem if I want to use a compass template or other CLI additions when I start a project.

I understand why such a separation is not acceptable for ms yet.

Owner

mirisuzanne commented Dec 19, 2012

We have a lot of major changes coming soon, so we'll keep this in mind as we work, and see where things land.

@mirisuzanne mirisuzanne removed the Susy Next label Mar 10, 2014

Owner

mirisuzanne commented Aug 27, 2015

I think this has been covered by the LibSass bower/npm/eyeglass packages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment