Previously, we had a friendly discussion on what we could use as a responsive layout framework for Drupal.org. Rupl, Banghouse, and myself played around with a lot of the options discussed in that post to work out which would be a good fit for us. Snugug also volunteered to help us out with technical questions and implementation.
We ended up deciding that using a Sass framework solves a lot of our problems, specially Susy. Implementing this framework is no small feat. We wrote a little summary of the Sass, Compass, and Susy implementation.
What is it
- Sass is a CSS Preprocessor designed as a meta-language on top of CSS and used to describe the style of a document cleanly and structurally, with more power than flat CSS allows.
- Compass is both a framework for Sass, providing standard and useful cross-project functionality (such as prefixing CSS3 properties, building and using image sprites, inlining assets, etc…), and a plugin architecture to allow others to build and distribute extension for Sass.
- Susy is a semantic CSS layout framework entirely native to Sass distributed as a Compass extension. Read the documentation
Why use it
As we move towards embracing responsive design, pure separation of content and presentation becomes even more important. Every element on the page could change its layout or styling depending on the context it’s being viewed in. Binding grid-specific html classes and applying the same CSS throughout does not allow us the flexibility that a responsive, mobile-first layout requires. Grid-specific classes also add additional weight to every page when page weight is still very important. CSS is cacheable in the browser, HTML is not.
Sass allows us to abstract complex calculations and perform them when we compile the CSS we use on the site. Column widths can be assigned with simple properties such as span-columns(8) for an area spanning 8 columns in the context of our site’s container or span-columns(3, 8) for an area spanning 3 columns nested within an 8 column wide area. This keeps styling maintainable and accessible. Sass also provides a commenting style (//, inline) that allows us to write complex comments without printing those comments to our CSS, thus reducing our CSS’s file size.
Adopting the power of the Sass preprocessing language and the powerful Susy layout framework will give us the flexibility to easily apply new layouts at different breakpoints. Eventual adoption of Sass for the whole of the Bluecheese theme will make for a more maintainable and readable theme.
Challenges
A lot of pages on Drupal.org use the current system, which is tied to the markup. In order to leverage the full flexibility of Sass and Susy we have to replace grid-specific classes with semantic classes. This is not necessarily taxing but it is a sizeable chunk of work, and will require a full audit of a large range of pages that are affected.
Sass requires some technical knowledge of the command line interface to install and Compass requires some initial work to leverage. This is a small technical barrier that may prevent some from contributing to the theme. This is outweighed by the increased usability that Sass, Compass, and Susy provide us as we build Bluecheese to be future friendly. There are also some GUIs that ease some of this pain for those unfamiliar with CLI.
Comments
That's jolly good news
I'd be happy to help out.
I've been using Sass, Compass and Susy on my projects at Panoetic for a few months and currently in the process of implementing a new starter theme at Code Enigma where we'll be building some pretty large sites.
SCSS/Compass/Susy
Since this has been my combination of choice for the past year as well, I would happily assist in working on this issue too!
mario rader
★ knowledge is a weapon. arm yourself. ★ websalat ★
I'll find a few spare hours,
I'll find a few spare hours, if that's helpful.
I'm the maintainer of Sasson and use sass daily on all of our projects, never used susy though.
Is there a place to start, an issue queue ?
Happy to help
My time is pretty limited, but I'm happy to help out in any way I can. I've been using Compass on all of my projects recently and I'm just finishing up my first Susy responsive site.
Would love to help, available in ~3weeks
This is great news! I've been using Sass, Compass and Susy for over two years and have been active in that community for the last year or so. (I've even made some contributions to Compass core). It's a lovely toolset.
I do need to get up to speed with Susy 1.0 (which is a big upgrade from Susy <0.9), but I've been meaning to do that for months, so this is a good opportunity :)
All that is a long-winded way of saying I'd love to contribute to this project! I do have a couple of other commitments though. I'll be unavailable to dig in for another three weeks, but will make time to be part of discussions.
omega 4 will be based on sass
omega 4 will be based on sass / compass and allow to integrate different grid systems including susy. also zen 5.x should do so
Omega
I personally like omega but am dying for a more lightweight base theme solution; something along the lines of bones for wordpress.
mario rader
★ knowledge is a weapon. arm yourself. ★ websalat ★
being a complete rewrite,
being a complete rewrite, omega 4 will be much more a lightweight but extensible base theme solution than omega 3 currently is :)
jake mentions some rough details on the recent drupaleasy podcast.
http://drupaleasy.com/podcast/2012/06/drupaleasy-podcast-84-jake-who
fubhy is already working on it, a first dev release is to be expected soon
Zen 5
Zen 5 is already a lightweight base theme with Sass/Compass integration. It was in development for over a year and is rock-solid now. You should check it out!
- John (JohnAlbin)
Really cool to see Compass
Really cool to see Compass with Susy being chosen.
I've been using it for a while now to help me with the maths of fluid grids and it's an awesome tool.
Both Omega and Zen were
Both Omega and Zen were considered heavily. We even built half working Bluecheese themes with both frameworks.
Omega 4.x was touched upon, it is simply not ready and not tested, so it wasn't really an option.
The other obvious point here is that we already have a working theme, base themes are great for building a site from scratch but that's not our use case. Using Susy to complement the existing theme makes a lot of sense.
Backstory: Base themes discussion(s) & etc.
Initial discussion: http://drupal.org/node/1438716
Later discussion during the First Portland Sprint: http://groups.drupal.org/node/226833
Portland Sprint EOW Summary: http://drupal.org/node/1438716#comment-5943290
http://drupal.org/project/bas
http://drupal.org/project/basic has been using SASS for quite a few years - with integration of the Compass module.
HTML5 + responsive on the road map :)
I work at The Jibe Multimedia, Inc.
Using Sass/Susy/Compass going forward
I've been working for a while with Omega 3.x building up this site but have been looking into SaSS/Susy based on this excellent article. The thing that's impressed me the most about SaSS/Susy is that it can be used to effectively inject responsive functionality into an EXISTING theme - i.e. you can use it to backport responsiveness into a mature site w/out having to re-build the theme from scratch in a framework. Depending on project needs, this can be a game-changing difference.
I've found Omega most helpful as a learning tool around responsiveness in Drupal. And it's a great solution if end-user GUI configuration of a theme is a requirement. But for a production solution on a large site which will retain it's theme for several years, I'm preferring the agility, control and markup structure we get with SaSS/Susy. There's a non-trivial learning curve with SaSS/Susy, but I'm finding that the design work around a fully responsive site ultimately dwarfs the implementation specifics, so the slight additional effort coming up to speed with SaSS/Susy on this one project will pay dividends for all projects ahead.
Just a nitpicky aside, Sass
Just a nitpicky aside, Sass is officially abbreviated Sass not SaSS. Also, it's an abbreviation for Syntactically Awesome Stylesheets.
Docs
The documentation link at the end of the description for Susy (under “what is it”) isn’t the official docs. It should be to http://susy.oddbird.net/guides/getting-started/
@lewisnyman can you confirm that the plan here is to use Susy 1.0?
We are indeed using Susy 1.0
We are indeed using Susy 1.0 RC right now
Awesome – next steps?
Thanks @Snugug. So, what are the next steps?
Documentation is currently
Documentation is currently being drafted to establish code standards and to provide efficient on-boarding for people who are interested in helping. Stay tuned, docs to follow.
Will do :)
^^
Susy for Drupal. A Susy theme is being worked on already
I like the Susy responsive framework a lot. It's light, elegant and semantic.
Some work is already started for a Drupal theme based on Susy. Check out this writeup at:
http://www.zivtech.com/blog/responsive-drupal-theme-50-lines-code-or-less
and check out "Tony", an experimental Susy-based theme in this sandbox :
http://drupal.org/sandbox/tizzo/1426556
Yay! But…
First off, I'm really pleased that Sass/Compass was chosen to implement the styling for Bluecheese. This is definitely the right decision. It is pretty clear from my vantage point that within the Drupal community, Sass is a clear winner over Less both in terms of usage within the community and in terms of features and capabilities of the preprocessor.
But I'm curious why you picked Susy for the layout framework. What was the criteria used to pick it over other Sass-based layout frameworks? I have several concerns about using it (listed from least important to most):
It just underwent a complete re-write last month. How many bugs did this introduce? There's no unit tests to run to verify the code works as designed. This is my most nit-picky point; feel free to completely ignore it. Note I'm not trying to produce FUD; I'm generally uncertain about the code quality. See the related point #3.
It makes you do too much math. Considering this is built with Sass, this point boggles my mind. Susy requires a few variables, one of which is $column-width. In order to use Susy, I had to do this:
$total-columns : 10;$gutter-width : 2%;
$grid-padding : 2%;
$column-width : (100% - ($gutter-width + $grid-padding) * $total-columns) / $total-columns;
That last bit of mathematical gymnastics just seems crazily unnecessary. Surely the framework should calculate all that for you. It’s possible I'm doing something wrong, but I don't believe so.
Rounding errors: it is susceptible to significant rounding errors in its fluid grid. I'm currently writing a blog post about the failure of webkit, opera and older IE browsers to properly account for rounding errors in fluid grids, but I added Susy to my demo page and the results are illuminating. From the screenshots on that page, you can see that Susy has problems in Webkit and Opera and even in Firefox 13, a browser which is immune to rounding errors.
Here’s a screenshot of Susy, a bespoke "float: left" method, and Zen Grids in the latest version of Chrome (a Webkit-browser susceptible to percentage-based rounding errors):
You can see more screenshots and the original demo at: http://johnalbin.github.com/fluid-grid-rounding-errors/
Given these points, do we really want to use Susy as the basis for drupal.org?
I started writing Zen Grids last December as a direct response to the limitations I saw in Susy. It’s currently at version 1.2 and includes unit tests so I don't break anything when adding new features. It’s also, IMO, way easier to use than Susy. http://zengrids.com
- John (JohnAlbin)
RE: Susy usability and rounding errors
@JohnAlbin Yes, we must make sure Susy is solid and reliable, as it is at RC1 and depends on Sass 3.2 (which is also prerelease but solid in my experience). I think it's a matter of testing to our satisfaction. <ins>Assuming we go with some version of Susy,</ins> I would regret having us use the older version, at the very least because Susy 1.0 it has some really handy features designed specifically for responsive layouts.
Which brings me to your second point about usability. Susy certainly doesn't encourage setting $column-width the way you have done. This is how I've been using it, and how it's intended to work. It will calculate the required percentages, and I do prefer to think in ems (better linkage to typographic measure).
The third point is a bit surprising. I've noticed webkit's rounding errors of course, but I don't think I've ever seen columns shifting as much as in your live example. I'd like to hear from others and find our what's going on there.
I've chatted with Eric A. Meyer (creator of Susy) before, though we don't know each other well. I've asked him to comment here if he has input.
Misunderstandings
I don't understand why, when you are creating a fluid grid (which means percentage-based units) Susy encourages you to set an em-based column width. It feels very counterintuitive to me.
Can you better explain how it is supposed to work?
Or is Susy designed for adaptive layouts and not responsive ones?
It seems pretty clear that I just don't get Susy. But to have a fair discussion about using Susy for drupal.org, I need to understand it better.
The live example actually came from Morten. He asked me a couple weeks ago to help him with this rounding error issue. I simply forked his example to show him what Zen Grids can give him. And then added Susy over the weekend when I saw this discussion come up. Morten’s live demo was designed to show off the rounding errors as much as possible. Most designs wouldn't have this level of compounding errors because they wouldn't have that many items floating next to each other. But that doesn't mean Morten's example shouldn't be considered.
If I've implemented the Susy example incorrectly, please send a pull request. https://github.com/JohnAlbin/fluid-grid-rounding-errors/blob/gh-pages/sa...
- John (JohnAlbin)
Same, but different
Susy isn't really that different, I don't think. You can use it for responsive grids or adaptive grids. And actually I got something wrong as well. I said:
It does allow column-widths in percentages and any other css unit, and it's certainly not intended to make giant calculations necessary. Susy does favour ems or pixels for its grid parameters from which percentages are calculated automatically. There are some advantages to doing this, particularly with ems: I find it helps me think clearly about how the grid relates to the underlying typography – and the grid should be derived from some kind of content-related constraint. It also helps when gauging measure (line-length), which as a rule of thumb I try not to stretch past 40em (~30-35em is optimal for readability). So for me using ems is more intuitive, more closely connected to the substance of the content I'm laying out, even if it's less direct with its column units.
Please let me know if any of the above is unclear. It's late here :)
Eric will probably have more apt things to say on all of this, and maybe be better able to answer questions.
Susy vs. Zen Grids
To me, Susy pretty much just has the first mover advantage in that race. I simply have not really been looking at alternatives that actively, since I started using it and thus must've missed Zen Grids. I'll happily have a look at it though; it doesn't seem all that different but it's always great to see more smart brains working towards the solution of a task.
mario rader
★ knowledge is a weapon. arm yourself. ★ websalat ★
A Susy Perspective (with corrections)
Hi John,
I'm happy to answer questions about Susy, and I'm sorry you have had such a hard time understanding it.
In regard to your concerns above:
This isn't true, and seems like a very strange complaint considering the age of Zen Grids. I did not do a "complete re-write", and it wasn't just "last month". I wrote Susy three years ago, and I added some new features over the course of this March and April, releasing them early May.
In those three years I've developed quite a large user base (nearly 43,000 downloads) that keeps me honest. In fact, I have more downloads in this one pre-release month than the entire download history of the Zen Grids project. With all those downloads, I've had only one single repeat complaint, and it's unrelated to the Code I wrote (it's an install issue related to dependency conflicts). Otherwise, there have been no bugs of note.
If this isn't meant to create FUD, I'm not sure why you brought it up. It's a losing argument all-around.
The main purpose of Susy is to create those percentages for you, based on other units. I recommend ems, so that you can be responsive to both window size and font size/line length. The result is not either "adaptive" or "responsive" as those terms have been defined, because it combines the two, while also being elastic. It is all-of-the-above, the most powerful and flexible option.
If you do want a purely fluid grid, there are two helpers to make it happen more easily ($container-style: fluid; and/or $container-width: ...%;).
Your demo is clearly built to a precise worst-case-scenario for sub-pixel rounding in Webkit. It's a case you will almost never see under proper Susy usage, or in any production design, and the misuse of Susy exacerbates the problem.
But sub-pixel rounding does exist, if rarely so blunt, and we've simply chosen different sides of a trade-off. My approach is simple and meaningful, but willing to sacrifice a small level of pixel-exactitude. Your solution adds a great deal of overhead, including columns being removed from the flow, in order to achieve more precision.
You've added extra markup and CSS work-arounds to your side of the demo, but not to mine. Your solution includes heavier HTML, Sass, and output CSS, while Susy doesn't even need all the code you gave it. That's because Susy is most concerned with being slim and flexible - to fit any markup you have, with as little force as possible.
I don't mean to ignore this case entirely, but given the option to work around it in those rare cases where it does come up, the solutions aren't difficult. Susy comes with all the functions needed to do your own grid math and apply it anywhere. I'm simply not willing to sacrifice all my defaults to this one extreme case.
I chose this side of the sub-pixel trade-off because I believe a responsive approach already requires sacrificing pixel-exact design, but should not sacrifice markup/flow as well. That's a decision that I'm glad to stand behind.
Long-overdue apologies
I was falling ill when I wrote the original comments and lost track of the thread after I recovered.
But I want to state for the record that Eric has formed a great team around the Susy project and its a terrific choice for any project. See http://snugug.com/musings/introducing-susy-next
“Note I'm not trying to produce FUD; I'm generally uncertain about the code quality.” Guh. It's embarrassing that I said that. I humbly apologize. I'll try to remember that when I want to preface a sentence with "I'm not trying to produce FUD", I'm headed straight into FUD territory. :-)
- John (JohnAlbin)
A good team
Susy Next has built a great team.
Have you [Zen grids] considered joining up?
Zurb Foundation
I guess the debate is over and Susy is picked. But better late than never.
I want to nominate the Zurb Foundation framework for consideration. It is another Sass/Compass responsive framework :
http://foundation.zurb.com/
Check out the Drupal project implementing Zurb Foundation :
http://drupal.org/sandbox/ishmaelsanchez/1332338
I was looking at Zurb. I'm I
I was looking at Zurb. I'm I right that it uses presentational class names (e.g. pull-one)?
I'm not a fan of presentational class names, that's why I like Susy.
Foundation is more of a
Foundation is more of a prototyping framework to get something looking solid quite quickly. It uses classes for everything with very little Sass integration. Drupal doesn't really suit that kind of framework as it's a lot of work to wrangle the mark up to work with the supplied classes.