Disclaimer: You may disagree with some of the things I’ve written in the ensuing article. That is okay. I do not claim to represent you, your company or your ideology so there’s really no reason to get upset. Just go ahead and disagree. Apologies to the vast majority of you who understand the mechanics of discourse and dialectics, for whom this disclaimer does not apply.
Update: This is now the first of two parts (!). Be sure to read the second part as well.
Multiple files
A lot of web development seems to be about splitting things up into manageable chunks or “components”. For each discrete bit of javascript functionality or each HTML partial I might make a dedicated file, then organize related files into folders named javascript and html or controllers and templates. Whatever you like. This way, you can easily dip into the file system and focus on just the file containing the code you want to edit at the time.
This doesn’t work so well for CSS. Javascript function definitions can go either before or after where they are called and HTML modules can be inserted wherever you see fit in the flow of the document. CSS, on the other hand, is a chronology. It matters a great deal in what order you declare styles. Heeding the language features of inheritance and specificity, you should start with generic styles (like a font-family set on body) and progress to more specific definitions.
CSS is an ordered, exception based language and there is no easy way for a file listing (which is typically organised alphabetically) to represent it coherently. It gives you the impression that each CSS file is autonomous, which it is not.
- buttons.css
- reset.cssSo you have two choices: You can either live in denial, grumbling that “specificity shouldn’t be part of CSS” as you try to force a square peg into a round hole, or you can work in one, well-commented file that clearly represents the arc of your inheritance-harnessing cascade. Specificity should never be a problem because the most specific selectors should be the last ones you write.
Summary: You shouldn’t organise CSS by splitting it into separate files any more than you should organise a pane of glass by dropping it on a concrete floor.
Nesting (with Sass)
I’m ambivalent about Sass. Some things about it really excite me, like the ability to write generatively, using loops and conditionals. Other features, like the ability to nest declarations infinitely, aren’t so hot.
I think a lot of people come to Sass to help them manage and maintain their CSS; to make it easier to read and write. The addition of Sass as a dependency and abstraction layer can’t help but make things more systemically complex, but there’s something to be said for the interfaces Sass provides, like parametric mixins. Employing them in projects for readability and brevity can be something of a boon.
Nesting, though? That can only make things worse. Picture the most badly organized CSS file imaginable. That mess may be messy, but at least it’s a one-dimensional mess: Single file chaos, if you will. Let someone who writes crappy CSS (that could be anyone, including me at times) have nesting and you’ve licensed them to branch out into a second crappy dimension. Great! Now the pandemonium spans from top to bottom and left to right.
Considering it’s a point of professional pride to avoid nested structures as much as possible in other languages, it seems rather silly to bring this capability to a language which doesn’t need it. Hugo Giraudel has written literally hundreds of instructive articles about Sass. Here’s what he has to say about nesting:
Fucking. Stop. Nesting.
Summary: Nesting is not the Sass feature you are looking for.
Pixel units
Back when Internet Explorer 6 was still a thing, we were told to set font sizes in em units. Newer browsers, with zoom functionality, made it easy to increase the size of the page content proportionately, but in IE6 you could only increase the font size. Since text set in pixels refuses to be enlarged, we’d otherwise be marginalizing a lot of low vision users.
Internet Explorer 6 is no longer a thing, but users of most operating systems and browsers can still set font sizes independent of zoom functionality. Should this be their preference, we ought to accommodate it.
I’m not even going to make this about accessibility, though. I’m going to appeal to your selfish side instead: Managing sizes using pixels in responsive design is an absolute fucking hog. The lack of relativity between separate elements’ sizes means you have to treat each setting as a separate concern, for each separate breakpoint. In fact, using pixels you even have to manage the font size and margin of single, isolated elements separately. You really don’t want to do that.
Take the following example:
@media (min-width: 400px) {
h1 {
font-size: 22px;
margin-top: 33px;
}
}How would I write that using relative units? I wouldn’t. In fact, I wouldn’t have to address font sizes or margins for any individual elements in any of my @media queries. I’d simply let the browser or user determine the font-size on the root element (<html>) and set all my other dimensions in ems or rems.
h1, h2 { margin-top: 1.5rem; }
h1 { font-size: 2.5em; }
h2 { font-size: 2em; }
/* all your other element styles */Then, when I wanted to scale things up at a min-width breakpoint, I’d just adjust the root font size, upon which everything else is proportionately based. I use a percentage value because this is relative to the user’s preference, if set:
@media (min-width: 400px) { /* "Should be ems too!" - lots of folks :-) */
html {
font-size: 120%;
}
}That’s it. That’s 90% of your responsive design strategy right there. For bonus points, you can set a common margin between all your sibling flow elements using a selector like the lobotomized owl:
body * + * {
margin-top: 1.5rem;
}Summary: Embrace relativity and reap the rewards.
Device breakpoints
A few months ago, in the wake of Apple’s latest Chinese factory exorcism, I read a tweet by a commentator. Their tweet contained a diagram of, “all the viewports available on iOS 9 for Responsive Web Design”.
What? What?
Then I recalled a conversation I’d had with Sara Soueidan, in which she described content breakpoints as responsive design’s “biggest secret”. Suddenly, it struck me: there are legions of folks out there targeting the specific screen dimensions of selected proprietary devices and calling it “responsive web design” — possibly thousands of web designers crying “oh fuck me” every time a tech’ company releases a gadget with a browser on it that “changes the landscape”. Imagine that!
“OHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKMEOHFUCKME”
I’m not supposing you labour under the same misapprehension, but just in case you have a friend who needs telling: breakpoints tailored to the specific dimensions of specific devices is not responsive design. It is not tenable. It does not work. If any devices you didn’t design for have unbroken layouts, it’s the result of dumb luck alone. Not really a strategy.
Instead, you should ensure your design is fluid, inserting breakpoints (or “tweak points”) only where the content poses layout issues. Between these points, the design should expand and collapse seamlessly, meeting the requirements of any device dimensions which appear within these ranges.
I told the commentator / thought leader that I didn’t think what he had to say had anything to do with real responsive design. He replied, “ideally I agree, but a key for a successful mobile experience is to understand the real world”. That was it — no clarification! I wonder what this real world is like… I must visit some day.
Summary: Apple aren’t the only people who make handheld devices with browsers on them. No really.
Fuck CSS, let’s rock
Thank you for indulging my opinions on CSS authorship. If you’re a fan of web accessibility and music (who isn’t?) and you’d like to support a couple of awesome organisations, check out A11Y ROCKS.
Part Two
There is now a second instalment of Things To Avoid When Writing CSS. Read part #2.
