Navigation

Writing contextual CSS

Organization and struc­ture of CSS might be one of the largest dif­fi­cul­ties for be­gin­ners as for pro­fes­sion­als in web de­sign. It is hard writ­ing good CSS. It is some­what easer with pre-proces­sors (SCSS, LESS, Stylus), but they’ll only give you the tools: it’s up to you how to use them (what I can’t do with­out is the @import fea­ture).

What I’ve learnt dur­ing re­cent years is to write con­tex­tual CSS: how sim­i­lar el­e­ments and prop­er­ties should be close to each other in the code. How I want to find the prop­er­ties of an el­e­ment in one place. This post de­tails how I pre­fer to write CSS, based on the num­ber of pro­jects where I’ve been forced to dig through my own code.

Finding all prop­er­ties in one place

When I first started do­ing web de­sign, I (as you of­ten do) started out by read­ing other peo­ple’s HTML and CSS. Inspecting every el­e­ment, check­ing out the un­der­ly­ing CSS struc­ture. I noted that many de­vel­op­ers tended to split their stylesheets in files such as layout.css, typography.css, and more. I did­n’t ques­tioned why, but did the same. I ended up dis­lik­ing the ap­proach. Why? I jumped be­tween the two stylesheets to find and al­ter prop­er­ties.

When go­ing through my (and oth­ers’) CSS, I want to find prop­er­ties of an el­e­ment and find them fast. Depending on how one is do­ing ab­strac­tions (that’s a fu­ture post of mine) I don’t want to jump around in the par­tials to find that par­tic­u­lar place where those spe­cial prop­er­ties are sneaked into the code.

I be­lieve it’s per­fectly fine to mix and match all kinds of CSS prop­er­ties: col­ors, ty­pog­ra­phy, box model stuff. Go nuts. Since it’s very sel­dom those cat­e­gories won’t end up af­fect­ing each other any­way, I don’t see any rea­son why they can’t go to­gether. For in­stance, when you’re chang­ing font sizes you may also have to tweak the paddings.

Proximity of re­spon­sive styles: in­line me­dia queries

This ap­proach can go for re­spon­sive CSS as well. One of­ten has sep­a­rate stylesheets for dif­fer­ent view­ports where all CSS for that par­tic­u­lar view­port goes. Perhaps small.css, medium.css, and so on. This is cool. If I want to tweak styles for a par­tic­u­lar view­port I visit that file, sim­ple as that.

But, that also calls for jump­ing be­tween con­texts, and I’ve started to find that tir­ing. When an el­e­men­t’s prop­er­ties are spread out over sev­eral files I tend to lose grasp of the whole thing. This is a night­mare in semi to large pro­jects.

But pre-proces­sors got our back. By us­ing in­line me­dia queries, mix­ins, SCSS place­hold­ers, and vari­ables, one can write the re­spon­sive styles in the same con­text as the el­e­ment is de­fined in the core CSS:

// Custom mixin using SCSS placeholders
@mixin respond($width, $mode: "max") {
@media only screen and (#{$mode}-width: $width) {
@content;
}
}
$small-screen: 30em;
h1 {
color: #000;
font-size: 2em;
@include respond($small-screen) {
font-size: 1.5em;
}
}

will com­pile to

h1 {
color: #000;
font-size: 2em;
}
@media only screen and (max-width: 30em) {
h1 {
font-size: 1.5em;
}
}

So in­stead of hav­ing the de­c­la­ra­tion of the h1 font site in a sep­a­rate _small.scss par­tial, we can write it be­side the orig­i­nal de­f­i­n­i­tion (if that po­si­tion is suit­able).

I’ve started to fall in love in this so­lu­tion and have used it in a cou­ple of smaller live pro­jects. My work­flow be­comes much ef­fi­cient when I can tweak the dif­fer­ent me­dia queries at one place.

Performance of re­peated me­dia query blocks

That’s not DRY!”, you might say. Well, it re­ally does­n’t mat­ter, oth­ers have con­cluded.

The post Sass and Media Queries on SassCast comes to the con­clu­sion that for per­for­mance, it re­ally does­n’t mat­ter if you’re hav­ing re­peated me­dia query blocks in­lined in your SCSS code, un­less it’s a huge num­ber (around 2000+ blocks).

There’s a thread on this sub­ject in the CSS Tricks fo­rums (“SCSS: Inline me­dia queries vs sep­a­rate me­dia query blocks”). A com­menter men­tioned a Ruby gem for merg­ing re­peated me­dia query blocks to­gether: Sass Media Query Combiner.

Conclusion

This might seem like a small de­tail, not wor­thy of a post, but try it out: I find it re­ally awe­some. Life’s too short for pre­ma­ture op­ti­miza­tion of CSS files: Gzip will have your back.