A Q&A about Susy and other toolkits, with Miriam Suzanne.
About Miriam Suzanne and the Q&A
Miriam is a co-founder of OddBird, and is the author of Jump Start Sass at SitePoint. She is the creator of Susy, as well as a creator and contributor of other open source toolkits and projects. Last week, she was able to join us on the SitePoint Community for a live Q&A session, and took all manner of questions on Susy, toolkits, and deciding what sort of tools are needed for your layouts.
Let’s dive right in and take a look at some of the many questions that Miriam was able to answer for us!
Your Questions
Q: What are your recommended first steps in determining what frameworks, libraries, toolkits (etc.) you should use for CSS layouts and styling?
Miriam Suzanne: There is always a trade-off between the speed/familiarity of toolkits, and the added baggage of dependencies. If you’re working on a personal project, go with familiarity. Treat yourself. Otherwise, start with the smallest and most abstract toolkits, then work your way in. Bootstrap is a big commitment. Accoutrement-scale is not. I have a few toolkits that I load up at the start of any project bigger than a single page — then I work my way out from there. If you know you’ll need it: add it right away. If you think you might not need it, wait until you do.
It’s always a balancing act, and there’s no way to “get it right” every time. Be prepared to change your mind later. Refactoring is not a mistake — it’s the entire point of iterative process.
Q: Why Susy?
Miriam Suzanne: At the time, in 2009, it was much more difficult to create fluid layouts on a grid. There were more browser inconsistencies, we only had floats to work with, and we didn’t have border-box sizing. I was using a technique that I picked up from Natalie Downe’s CSS Systems talk. It’s a great talk, if you want to see where all my inspiration has come from.
Her system is great, but it requires a lot of math. The math isn’t complex, but it’s very repetitive – and without Sass, the results look like meaningless numbers. I didn’t like that, so I complained at one of our work retreats, and someone showed me Sass – which was just starting to gain some small popularity at the time. I wrote Susy that night. It was tiny, and just helped me with the repetitive math. I also built in a few helpers to deal with browser bugs. That’s all I wanted.
The other open-source options at the time were huge CSS libraries with pre-determined grids, and I wasn’t interested in that. Susy, as far as I know, was the first to move grid systems into Sass in a native way. There is no way to build Susy in pure CSS.
Honestly, I don’t use Susy much any more. It doesn’t solve a problem that I face on a regular basis. But I hope it’s still useful to people who are dealing with floated grids and older browsers.
Q: What are the similarities and differences of using Susy vs border-box sizing vs flexbox?
Miriam Suzanne: You can use all three together! These actually solve slightly different problems:
- Flexbox is what I call a “layout technique” (similar to floats, inline-block, tables, etc). It’s a way that the browser understands creating regions on the page, and managing how they flow. All of these techniques have advantages and drawbacks. But flexbox was the only one designed to handle layout. Currently, that makes it my favorite, despite the issues. Soon, we’re also getting grid layouts in CSS, so that will be another option. I recommend learning how they all work, so you can use each one where it makes the most sense. One tool is never enough!
- Box-sizing helps you to describe the size of a single element in new ways. Do you want to define the content, and let the padding expand? If so, use content-box. If you want to describe the outer size, and let the content adjust, use border-box. Having that flexibility is huge, and a big upgrade from what we had seven years ago. Again, learn how both options work, so you can be more flexible.
- Susy is just a calculator. If you find yourself doing a lot of math to get the grid you want, use Susy. Or, in many cases, I think it would be better to say “maybe your grids don’t actually need to be that complex”.
Q: Can you share some of the calculations Susy is doing behind the scenes?
Miriam Suzanne: The primary Susy calculation is this:
$target-width / $context-width = $multiplier
At it’s simplest, that is identical to using percentage(1/5) to get 1 column out of 5. When you add gutters, that gets more complex. The total isn’t really 5 – it’s something larger.
If you are interested in the basics, check out the Susy 3ish branch where we’ve trimmed Susy down to the bare essentials.
Q: Is there a toolkit that you are predominately working on right now?
Miriam Suzanne: I’ve moved my focus back a step, concentrating less on consistent output (the style guide we want to generate) and focussing more on consistent input. I’ve been slowly building out a set of Sass helpers that, like Susy, are completely un-opinionated. Our Accoutrement tools are so abstract, they mostly have no output at all. But they are useful in helping us define patterns in the code, tracking those patterns in a single place and automatically generating style guides based on that information.
Q: What things should you consider, first and foremost, when starting to make a toolkit?
Miriam Suzanne: I love this one.
I love when other people are interested in building toolkits for themselves. I think building toolkits is a great way to learn about code. It doesn’t matter how many people have solved the problem, solving it again yourself is a useful exercise.
Here’s where I start:
- What doesn’t make sense in my code base? What isn’t readable to someone who didn’t write it?
- What problems do I have to solve over and over again?
- Where am I repeating myself, either in the code or in my process?
- Where do I get frustrated or bored?
Toolkits should always be used to make your code more readable, and more meaningful. A great reason to use Susy is because 12.456% doesn’t mean anything, but span(1 of 6) does. If you have code that isn’t meaningful, figure out what would give it meaning. clearfix is another great example of that. Without hiding it inside a mixin, your clearfix is just a strange mess of meaningless hacks. When you call a well-named mixin, you are adding clarity around why that code exists.
I also think it’s important to be iterative in your tool design. It’s ok for your first solution to be sloppy and over-engineered. That’s a great place to start! Then you try using it, find out which parts are getting in your way, and fix them. I think the mixins are getting in the way of Susy, so I plan to do something about it. Accoutrement have all gone through various stages as we add and remove features that don’t quite help as much as we expected.
Get it wrong first! Clean it up later!
Thanks for joining us!
Thanks to everyone who was able to join us for the Q&A, and for the excellent array of questions that were thrown out there. And thanks especially to Miriam Suzanne, for taking the time to join us! If you’re curious for more, check out the complete discussion on the SitePoint Community.
Stay tuned for more live events from SitePoint in the near future!
Jeff SmithJeff works for a startup as a technical writer, does contract writing and web development, and loves tinkering with new projects and ideas. In addition to being glued to a computer for a good part of his day, Jeff is also a husband, father, tech nerd, book nerd, and gamer.
Miriam SuzanneMiriam Suzanne is an author, performer, musician, designer, and web developer. She has been an active member of the Sass community since developing the Susy layout toolkit in 2009. She creates web software with OddBird, music with Teacup Gorilla, novels and poetry with [WriteyWrite], theatre with Vicious Trap, and Lego spaceships with anyone who is interested.
