Tag: responsive design

Sassy Styles

Jeroen

In my previous post I ranted about the way the design community seems to violate the DRY principle. Let’s revisit the code (and Repeat the code, I know, I know):

What’s going on here? Well, to get to our beloved Em measurements, we apparently need a calculation based on our body’s font-size (24px) and the h1 target font-size (16px). This “would make future adjustments much, much easier”.

It’s not that I dislike this really, but more that I despise (having to do) this. We’re saying “1.5em” here, only we’re doing it twice.

Last week I’ve tried one of the solutions to this: SASS. And let me say, this feels like it could be love at first sight! With SASS, the above snippet will quickly transform into the following:

Much better, no? We’ve now only stated once what the font-size should be: a certain fraction × 1em. I’m a little bit disappointed about needing the “* 1em” there, but hey: it’s a great reason to ask another Stack Overflow question.

Anyways, SASS doesn’t stop here. It will add more improvements, one of particular importance to the above snippet. Consider this:

What’s up with the additional lines of code? Isn’t that extra code bloat? Well no, those lines help us achieve two very important goals:

  1. Our calculation is now much more meaningful, and will now truly “make future adjustments much, much easier”.
  2. We can reuse those variables in our style sheets. In the somewhat contrived example above it doesn’t really shine, but you can surely imagine this is a great benefit to the entire style sheet.

For my current pet project I’ve tried SASS in a feature branch, but I’ve already closed that branch: it was merged into the main branch after only a few hours. With this I’m indeed implying there’s a very friendly learning curve for SASS.

And yes: I’m also implying that you should try it for yourself! There’s many more nice features I haven’t even mentioned yet. And if I didn’t convince you, perhaps the two-page tutorial will!

Measurements in Responsive Design

Jeroen

My wife called me out for looking at CSS through a pair of Programmer’s Glasses™. She hastily added this could well be a Good Thing, and I suppose I’ll just interpret it as a compliment. In fact, I must say I agree, feeling more like a “developer” than a “designer”.

Let’s first look at how we ended up at this name-calling. Here’s a code snippet from Ethan Marcotte‘s book Responsive Web Design from the A Book Apart series:

He then goes on to state that:

I usually put the math behind my measurements in a comment to the right-hand side of the line, which makes future adjustments much, much easier for me to make.

At first glance, this makes sense. However, in the long run, this feels really weird to me: it smells like code duplication. The actual result and the calculation in the comment both express the “what“, just in different form. It reminded me of Clean Code, where a whole chapter is dedicated to comments, and I’d think this would fall under the Bad Comments section (“Noisy Comment”, perhaps?).

Now I’m currently thinking I must be wrong: everyone who is something in responsive design is generating this type of sample code. Maybe it is because I should read this kind of code like:

Both forms describe what the font-size should be. Form 2 is probably “best” from a Clean Code point of view (as it’s most descriptive), but unfortunately only form 1 is valid (plain) CSS. As a compromise both forms are kept.

So, what are the options for improving things? There’s at least a few I can currently see:

  1. Combine “Form 1 and 2”. Accept that you’ll need discipline to keep the measurement and comment in synch. This is what the Responsive Design community leaders seem to practice.
  2. Just use “Form 1”. You’ll loose (or never have) the benefit of understanding your measurement.
  3. Use a CSS pre-processor. There are Sass and LESS, the most well-known ways to introduce (among others) calculations in stylesheets.
  4. CSS3 modules. The CSS3 Calculations module introduces calculations, and the Variables module may even take this one step further (as far as preventing code duplication is concerned).

To be honest, this list is currently my reverse order of preference. I’d love for option 4 (the CSS3 modules) to become a success. Until then, I’m bound to investigate the CSS pre-processors, because option 1 and 2 are both crappy, in my opinion.