Compass: Susy vs. Blueprint
Suno Ano
I would like to hear (from the developers; hello Eric/Chris) what the
plans are with regards to Compass and Susy and/or Compass and Blueprint
and therefore Blueprint vs Susy.
Why am I asking this? Well, I am too quite new to this whole concept of
SaSS and Compass so quite naturally I want to know with what I am going
to deal with say 2 years down the road from now? Will I be using Compass
on top of Susy and if so, why will I be doing so?
I have had a short conversation about this with Chris in IRC already
and, as usual, I have taken the bits and pieces and put it into my
notepad http://sunoano.name/ws/public_xhtml/appearance.html#susy
So far there are three reasons why I/we would use Susy. Eric? Chris?
others? :-)
Eric Meyer
the differences between the two and the advantages one might have over
the other? Or do you want to know how they will relate to the Compass
Core? Or something else entirely?
Here are my thoughts on the range:
I can't speak to the core features of Blueprint because I have never
used it for more than a few minutes looking at it the first time.
Susy was built as a set of functions/mixins to help me handle common
math problems related to the grid - originally the horizontal grid and
now vertical as well. Since I am designing a wide range of sites, I
needed something that would do the math and get out of my way - not
start having opinions on how I design. Because of that, Susy is almost
entirely structural, and will not add design to your site. The
templates that Susy has to get you started include some style defaults
for you to adjust, but there is none of that in the back-end. In fact,
Susy is agnostic in all cases: number of columns, width of columns,
units, gutters, side-gutters, markup, etc. You set every variable
there is.
Susy is also different because it is not possible without Compass.
Blueprint is a port, Susy is native. Because of that, it seems to me
that Blueprint doesn't take advantage of the full potential of Sass -
but still leans on outdated notions of what a framework is. Susy uses
the full power of Sass to allow absolutely any type of grid
(fixed,fluid,elastic) and even combinations, specializing in the
useful and difficult fluid-elastic, without any change at all in how
you use it. Susy is simply a set of tools that do math for you, and
that's how it should be used.
As for the future of the two in relation to compass core: It doesn't
matter. Compass is neutral to frameworks. Blueprint was bundled to
show what Compass can do and as a way to get people started. It may or
may not stay that way, but both (and any more that are built) will
continue to plug in just as easily as ever. Chose the tool you like to
work with, and use it. Both will continue being developed as long as
someone (me, chris, you) thinks there is something to develop. Two
years down the road you are using Whatever Framework You Damn Well
Please (Or None At All), Because You Can. That's how cool this project
is.
Did that come anywhere close to answering your question?
Cheers,
-e
On Apr 13, 11:24 am, Suno Ano <suno....@sunoano.org> wrote:
> Hi folks,
>
> I would like to hear (from the developers; hello Eric/Chris) what the
> plans are with regards to Compass and Susy and/or Compass and Blueprint
> and therefore Blueprint vs Susy.
>
> Why am I asking this? Well, I am too quite new to this whole concept of
> SaSS and Compass so quite naturally I want to know with what I am going
> to deal with say 2 years down the road from now? Will I be using Compass
> on top of Susy and if so, why will I be doing so?
>
> I have had a short conversation about this with Chris in IRC already
> and, as usual, I have taken the bits and pieces and put it into my
> notepadhttp://sunoano.name/ws/public_xhtml/appearance.html#susy
Jorge Vargas
> Hi folks,
>
> I would like to hear (from the developers; hello Eric/Chris) what the
> plans are with regards to Compass and Susy and/or Compass and Blueprint
> and therefore Blueprint vs Susy.
>
> Why am I asking this? Well, I am too quite new to this whole concept of
> SaSS and Compass so quite naturally I want to know with what I am going
> to deal with say 2 years down the road from now? Will I be using Compass
> on top of Susy and if so, why will I be doing so?
Same thing to ask about all the others featured at
http://github.com/chriseppstein
you have 960.gs, yui, they are tons of CSS frameworks like tons of
general web frameworks.
They will all evolve die and what not. What you should be asking
yourself is not what you will use 2ys from now but what solves your
problem today and for the duration of the current project.
Now SaSS and Compass (and Sass 3.0, whichs will add some interesting
stuff) is what you should be baking 2-3yrs from now as that is the
language you are going to learn and use.
And always remember frameworks are good to get you started and once
you grow you will have to tier them apart, cut and slash.
my 2 cents
Suno Ano
of you ... here we go:
Eric> I'm not sure I know exactly what you are asking. Do you want to
Eric> hear the differences between the two and the advantages one might
Eric> have over the other?
Yes, that was my intention.
Eric> Or do you want to know how they will relate to the Compass Core?
That too, yes.
Eric> Susy was built as a set of functions/mixins to help me handle
Eric> common math problems related to the grid - originally the
Eric> horizontal grid and now vertical as well.
vertical grid, sounds interesting, I have definitely look into that one
Eric> Since I am designing a wide range of sites, I needed something
Eric> that would do the math and get out of my way - not start having
Eric> opinions on how I design. Because of that, Susy is almost
Eric> entirely structural, and will not add design to your site.
so, roughly speaking, would it be correct to say: Susy I use for the
grid, Compass for the rest like colors etc.?
Eric> The templates that Susy has to get you started include some style
Eric> defaults for you to adjust, but there is none of that in the
Eric> back-end.
what do you mean by back-end here?
Eric> In fact, Susy is agnostic in all cases: number of columns, width
Eric> of columns, units, gutters, side-gutters, markup, etc. You set
Eric> every variable there is.
Sounds great.
Eric> Susy is also different because it is not possible without
Eric> Compass.
Ah, interesting, did not know that.
Eric> Blueprint is a port, Susy is native. Because of that, it seems to
Eric> me that Blueprint doesn't take advantage of the full potential of
Eric> Sass - but still leans on outdated notions of what a framework
Eric> is. Susy uses the full power of Sass to allow absolutely any type
Eric> of grid (fixed,fluid,elastic)
fixed, I know, fluid too, but what exactly makes a grid elastic? how is
elastic different from fixed and/or fluid? Into that, what is
fluid-elastic?
Eric> and even combinations, specializing in the useful and difficult
Eric> fluid-elastic, without any change at all in how you use it. Susy
Eric> is simply a set of tools that do math for you, and that's how it
Eric> should be used.
Ok, I really have to start using it to understand the implications on my
workflow you are outlining here.
Eric> As for the future of the two in relation to compass core: It
Eric> doesn't matter. Compass is neutral to frameworks. Blueprint was
Eric> bundled to show what Compass can do and as a way to get people
Eric> started. It may or may not stay that way, but both (and any more
Eric> that are built) will continue to plug in just as easily as ever.
Eric> Chose the tool you like to work with, and use it.
Exactly. But humans new to some technology/ecosystem naturally always
ask themselves what option to start with if several given. That is where
I am right now.
Eric> Both will continue being developed as long as someone (me, chris,
Eric> you) thinks there is something to develop. Two years down the
Eric> road you are using Whatever Framework You Damn Well Please (Or
Eric> None At All), Because You Can. That's how cool this project is.
Ok, I get the theory, have to see it in daily action to really know what
you are talking about.
Eric> Did that come anywhere close to answering your question?
Yes, you also gave some good insight on Susy itself and how/where it
differs from e.g. Blueprint.
Eric Meyer
By 'vertical grid' in this case, it might be more accurate to say
'vertical rhythm'. The code for that was originally written by Chris,
but is living in Susy at the moment.
> so, roughly speaking, would it be correct to say: Susy I use for the
> grid, Compass for the rest like colors etc.?
Susy is a Compass plugin, so they don't live at the same level. You
use Susy *on* Compass. Yes, Susy handles the grid, while Compass and
various other plugins will add more color/design aspects for you. And
if you want default typography you can pull in Blueprint Type. If you
want color themes you can pull in compass-colors. If you want pre-
designed buttons you can pull in Brandon's fancy-buttons. If you want
pre-designed site-maps you can pull in Thomas' compass-slickmaps. If
you want CSS-lightboxes you can use my css-lightboxes and so on. By
mixing and matching plugins you can build the right custom toolkit for
any job.
Susy does also include a few useful utilities that aren't strictly
grid-related (inline-block lists, for example), but all are built to
do the bare-minimum structural adjustment. Susy doesn't have "fancy-"
anything at all, and wont.
> Eric> The templates that Susy has to get you started include some style
> Eric> defaults for you to adjust, but there is none of that in the
> Eric> back-end.
>
> what do you mean by back-end here?
The Susy code that you don't see in the templates. The templates are
just there to get you started, with the assumption that you will
change them to work the way you want. The 'back-end' of Susy has all
the math, functions and mixins that you may never look at. Those
mixins and functions focus on page layout and have little opinion on
your design.
> fixed, I know, fluid too, but what exactly makes a grid elastic? how is
> elastic different from fixed and/or fluid? Into that, what is
> fluid-elastic?
Elastic grids are built on the 'em' unit, so they flex with the size
of the type, rather than the window. A fluid-elastic grid is built
with percentage-based columns inside an elastic shell. Susy then adds
max-width: 100% to that shell, making it so the grid becomes fluid at
smaller window sizes, while remaining elastic in larger windows.
In fact, all Susy grids are built fluid on the inside, which means you
can change the type of grid from fluid to elastic to fixed by simply
changing the units used on your container. Or, in Susy terms, simply
change the units you use to define your grid. Susy uses whichever
units you give it. Thus, Susy is completely agnostic to your type of
grid, without having three different systems in place.
All of that is based on Natalie Downe's "CSS Systems":
http://natbat.net/2008/Sep/28/css-systems/
> Exactly. But humans new to some technology/ecosystem naturally always
> ask themselves what option to start with if several given. That is where
> I am right now.
Certainly. But you don't need to worry about where plugins live in
relation to the core. Compass will continue being a platform for
plugins, and plugins will continue to be developed for it. Compass is
all about mixing and matching the parts you like, so you'll have to
make those choices on your own. The very best way to do that is to
play with them. Build some test sites using different systems and see
what A) makes sense to you for writing and B) outputs the code you
want. Then mix the best of everything to write the code you want to
write.
I wrote the basics of Susy the day I started using Compass, because I
knew what code I wanted and none of the other systems were writing it
for me. If the code Susy writes looks like code that solves your
problems in a way you can be proud of, use it. It will be hard to
choose a framework for writing CSS, if you don't know what CSS you
want to write. Maybe you don't even need a framework, but just want to
use Compass for abstraction within your own code - it's great for that
too.
If you are new to CSS, as Jorge mentions, you can get a great start by
playing with these different tools and seeing how they work. Just
don't be afraid to look at the CSS output files and check what they
are doing. Find the tool that seems to do what you need, and learn
what it's doing. Before long you'll be happily cutting and slashing.
These aren't gated systems, these are just shared tool-sets to help
you write code faster. There is no magic to them - they just output
CSS, the same CSS we've been writing for years. If you think of them
that way, this isn't a question of choosing between languages e.g.
Python v. Ruby, this is choosing which wrench in the box fits the nut
you need to loosen.
Happy Coding!
Cheers,
Eric