Tags: style



Whatever works for you

I was one of the panelists on the most recent episode of the Shop Talk Show along with Nicole, Colin Megill, and Jed Schmidt. The topic was inline styles. Well, not quite. That’s not a great term to describe the concept. The idea is that you apply styling directly to DOM nodes using JavaScript, instead of using CSS selectors to match up styles to DOM nodes.

It’s an interesting idea that I could certainly imagine being useful in certain situations such as dynamically updating an interface in real time (it feels a bit more “close to the metal” to reflect the state updates directly rather than doing it via class swapping). But there are many, many other situations where the cascade is very useful indeed.

I expressed concern that styling via JavaScript raises the barrier to styling from a declarative language like CSS to a programming language (although, as they pointed out, it’s more like moving from CSS to JSON). I asked whether it might not be possible to add just one more layer of abstraction so that people could continue to write in CSS—which they’re familiar with—and then do JavaScript magic to match those selectors, extract those styles, and apply them directly to the DOM nodes. Since recording the podcast, I came across Glen Maddern’s proposal to do exactly that. It makes sense to me try to solve the perceived problems with CSS—issues of scope and specificity—without asking everyone to change the way they write.

In short, my response was “hey, like, whatever, it’s cool, each to their own.” There are many, many different kinds of websites and many, many different ways to make them. I like that.

So I was kind of surprised by the bullishness of those who seem to honestly believe that this is the way to build on the web, and that CSS will become a relic. At one point I even asked directly, “Do you really believe that CSS is over? That all styles will be managed through JavaScript from here on?” and received an emphatic “Yes!” in response.

I find that a little disheartening. Chris has written about the confidence of youth:

Discussions are always worth having. Weighing options is always interesting. Demonstrating what has worked (and what hasn’t) for you is always useful. There are ways to communicate that don’t resort to dogmatism.

There are big differences between saying:

  • You can do this,
  • You should do this, and
  • You must do this.

My take on the inline styles discussion was that it fits firmly in the “you can do this” slot. It could be a very handy tool to have in your toolbox for certain situations. But ideally your toolbox should have many other tools. When all you have is a hammer, yadda, yadda, yadda, nail.

I don’t think you do your cause any favours by jumping straight to the “you must do this” stage. I think that people are more amenable to hearing “hey, here’s something that worked for me; maybe it will work for you” rather than “everything you know is wrong and this is the future.” I certainly don’t think that it’s helpful to compare CSS to Neanderthals co-existing with JavaScript Homo Sapiens.

Like I said on the podcast, it’s a big web out there. The idea that there is “one true way” that would work on all possible projects seems unlikely—and undesirable.

“A ha!”, you may be thinking, “But you yourself talk about progressive enhancement as if it’s the one try way to build on the web—hoisted by your own petard.” Actually, I don’t. There are certainly situations where progressive enhancement isn’t workable—although I believe those cases are rarer than you might think. But my over-riding attitude towards any questions of web design and development is:

It depends.


I’m working on a project with a team of developers who are trying out the BEM syntax for their class names. I’ve tried BEM before, but I’m not a huge fan of underscores (for no particularly good reason) so I tend to use a modified version that avoids those characters. Still, when it comes to coding style—tabs vs. spaces, camelCasing, underscores, hyphens, or whatever—my personal opinion takes a back seat to the group consensus. And on this project, the group has opted for proper BEM all the way, and I’m more than happy to go along with that.

When it comes to naming a modified version of a component in BEM, the syntax looks like this:


That raises a question about how you then deploy that class name in your HTML. You could just use the modified name:

<element class="component--modifier">

But then in your CSS you’d have to repeat all the style rules for .component selector inside your rule block for .component--modifier selector. SASS could you help out here, especially with its “extends” functionality, but the final CSS is still going to containing duplicated rules.

The alternative is to keep your CSS lean and modular, and write your HTML like this:

<element class="component component--modifier">

Now you’ve taken the duplication out of CSS and put into your markup. It looks a little weird. But, on balance, it’s probably the lesser of two evils.

It strikes me that this pattern of always having the base component class name appear anywhere you have a component--modifier class name is something that you could programmatically check for. It should be relatively straightforward to write a lint tool that looks in the value of every class attribute and, if it finds any instances of foo--bar, checks to make sure that foo is also in there.

Sounds like it could be a nice little task for Grunt or Gulp. Maybe somebody has already made it.

Mind you, it seems that most lint tools out there are focused very much on enforcing a coding style for CSS and JavaScript—not so much for HTML. I worry that this reflects the mindset of many front-end developers who view CSS and JavaScript as more important than markup …which is a bit odd considering that CSS and JavaScript are subservient to the HTML document that they’re styling and scripting.

Code refactoring for America

Here at Clearleft, we’ve been doing some extra work with Code for America following on from our initial deliverables. This makes me happy for a number of reasons:

  1. They’re a great client—really easy-going and fun to work with.
  2. We’ve got Anna back in the office and it’s always nice to have her around.
  3. We get to revisit the styleguide we provided, and test our assumptions.

That last one is important. When we provide a pattern library to a client, we hope that they’ve got everything they need. If we’ve done our job right, then they’ll be able to combine patterns in ways we haven’t foreseen to create entirely new page types.

For the most part, that’s been the case with Code for America. They have a solid set of patterns that are serving them well. But what’s been fascinating is to hear about what it’s like for the people using those patterns…

There’s been a welcome trend in recent years towards extremely robust, maintainable CSS. SMACSS, BEM, OOCSS and other methodologies might differ in their details, but their fundamental approach is pretty similar. The idea is that you apply a very specific class to every element you want to style:

<div class="thingy">
    <ul class="thingy-bit">
        <li class="thingy-bit-item"></li>
        <li class="thingy-bit-item"></li>
    <img class="thingy-wotsit" src="" alt="" />

That allows you to keep your CSS selectors very short, but very specific:

.thingy {}
.thingy-bit {}
.thingy-bit-item {}
.thingy-wotsit {}

There’s little or no nesting, and you only ever use class selectors. That keeps your CSS nice and clear, and you avoid specificity hell. The catch is that your HTML is necessarily more verbose: you need to explicitly add a class to whatever you want to style.

For most projects—particularly product work (think Twitter, Facebook, etc.)—that’s a completely acceptable trade-off. It’s usually the same developers editing the CSS and the HTML so there’s no problem moving complexity out of CSS and into the markup templates. Even if other people will be entering the actual content into the system, they’ll probably be doing that mediated through a Content Management System, rather than editing HTML directly.

So nine times out of ten, making the HTML more verbose is absolutely the right choice in order to make the CSS more manageable and maintainable. That’s the way we initially built the pattern library for Code for America.

Well, it turns out that the people using the markup patterns aren’t necessarily the same people who would be dealing with the CSS. Also, there isn’t necessarily a CMS involved. Instead, people (volunteers, employees, anyone really) create new pages by copying and pasting the patterns we’ve provided and then editing them.

By optimising on the CSS side of things, we’ve offloaded a lot of complexity onto their shoulders. While it’s fair enough to expect them to understand basic HTML, it’s hardly fair to expect them to learn a whole new vocabulary of thingy and thingy-wotsit class names just to get things to look they way they expect.

Here’s a markup pattern that makes more sense for the people actually dealing with the HTML:

<div class="thingy">
    <img src="" alt="" />

Much clearer. But now the CSS looks like this:

.thingy {}
.thingy ul {}
.thingy li {}
.thingy img {}

Actually it’s probably going to look more complicated than that: more nesting, more element selectors, more “defensive” rules trying to anticipate the kind of markup that might be used in a particular pattern.

It feels really strange for Anna and myself to work with these kind of patterns. All of our experience screams “Don’t do that! Why would you that?” …but in this case, it’s the right thing to do for the people building the actual website.

So please don’t interpret this as me saying “Hey, everyone, this is how you should write your CSS.” I’m not saying this is better or worse than adding lots of classes to your HTML. If anything, this illustrates that there is no one right way to do this.

It’s worth remembering why we’re aiming for maintainability in what we write. It’s not for any technical reason. It’s for people. If those people find it better to deal with simplified CSS with more complex HTML, than the complexity should be in the HTML. But if the priority for those people is to have simple HTML, then more complex CSS may be an acceptable price to pay.

In other words, it depends.

Pattern sharing

Mike has written about the Code for America alpha website that we collaborated on:

We chose to work with ClearLeft because they develop a pattern portfolio (a pattern/style library) which would allow us to scale our work to our Brigades. This unique approach has aligned perfectly with our work style and decentralized organizational structure.

Thankfully, I think the approach of delivering a pattern portfolio (instead of just pages) isn’t so unique these days. Mind you, it still seems to be more common with in-house teams than agencies. The Mailchimp pattern library is a classic example.

But agencies like Paravel are—like Clearleft—delivering systems, not pages. Dave wrote about providing responsive deliverables:

Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs.

I think that’s a good way of looking at it: a Bootstrap for every project.

Here’s the front-end style guide for Code for America.

Usually these front-end deliverables will be password-protected on the Clearleft extranet for the client’s eyes only, but Code for America are all about openness, so they’re more than willing to let us share it with the world. That makes me very happy. I remember encouraging the guys at Starbucks to publish their front-end style guide and I’ve written about this spirit of sharing before:

These style guides and pattern libraries aren’t being published in an attempt to provide ready-made solutions—every project should have its own distinct pattern library. Instead, these pattern libraries are being published in a spirit of openness and sharing …a way of saying “Hey, this is what worked for us in these particular circumstances.”

If you’re poking around the Code for America style guide, you’ll notice that it borrows some ideas from the pattern primer idea I published a while back. But in this iteration, the markup is available via a toggle—a nice variation. There’s also a patchwork page that provides a nice glance-able uninterrupted view of the same patterns.

Every project is a learning experience and each front-end style guide gives us ideas about how to do the next one better. In fact, Mark is busy working on better internal tools for creating these kinds of deliverables—something we’ll definitely be sharing. In the meantime, I’ll be encouraging other clients to be as open as Code for America have been in allowing us to share these deliverables.

For more on the usefulness of front-end style guides, be sure to read Paul’s article on style guides for the web, Anna’s classic 24 Ways article, and of course, Anna’s pocket guide from Five Simple Steps.

Coding for America

Back when I was wandering around America in August, I mentioned that I met up with Mike Migurski in San Francisco:

I played truant from UX Week this morning to meet up with Mike for a coffee and a chat at Cafe Vega. We were turfed out when the bearded, baseball-capped, Draplinesque barista announced he had to shut the doors because he needed to “run out for some milk.” So we went around the corner to the Code For America office.

It wasn’t just a social visit. Mike wanted to chat about the possibility of working with Clearleft. The Code for America site was being overhauled. The new site needed to communicate directly with volunteers, rather than simply being a description of what Code for America does. But the site also needed to be able to change and adapt as the organisation’s activities expanded. So what they needed was not a set of page designs; they needed a system of modular components that could be assembled in a variety of ways.

This was music to my ears. This sort of systems-thinking is exactly the kind of work that Clearleft likes to get its teeth into. I showed Mike some of the previous work we had done in creating pattern libraries, and it became pretty clear that this was just what they were looking for.

When I got back to Brighton, Clearleft assembled as small squad to work on the project. Jon would handle the visual design, with the branding work of Dojo4 as a guide. For the front-end coding, we brought in some outside help. Seeing as the main deliverable for this project was going to be a front-end style guide, who better to put that together than the person who literally wrote the book on front-end style guides: Anna.

I’ll go into more detail about the technical side of things on the Clearleft blog (and we’ll publish the pattern library), but for now, let me just say that the project was a lot of fun, mostly because the people we were working with at Code for America—Mike, Dana, and Cyd—were so ridiculously nice and easy-going.

Anna and Jon would start the day by playing the unofficial project theme song and then get down to working side-by-side. By the end of the day here in Brighton, everyone was just getting started in San Francisco. So the daily “stand up” conference call took place at 5:30pm our time; 9:30am their time. The meetings rarely lasted longer than 10 or 15 minutes, but the constant communication throughout the project was invaluable. And the time difference actually worked out quite nicely: we’d tell them what we had been working on during our day, and if we needed anything from them; then they could put that together during their day so it was magically waiting for us by the next morning.

It’ll be a while yet before the new site rolls out, but in the meantime they’ve put together an alpha site—with a suitably “under construction” vibe—so that anyone can help out with the code and content by making contributions to the github repo.

A question of style

I’ve just a written a post over on the Clearleft blog about the way we’re currently nailing down some front-end design principles.

Front-end development principles Gathering principles

I’m a big fan of design principles for many reasons, not least of which is they way they can help to quickly resolve debates and arguments. They become a kind of higher authority to appeal to, taking opinion and ego out of the equation.

They can also lead to specific design patterns. This is something I’ve talked about in the past: the goals of a project inform its principles, which in turn inform the patterns that are used.

In the case of front-end design principles, they are informed by some higher-level goals. As I wrote on the Clearleft blog, some of those goals are user-centric, and some are developer-centric:

The user-centric goals include:

  • performance,
  • accessibility, and
  • device-agnosticism.

While the developer-centric goals include:

  • maintainability,
  • readability, and
  • modularity.

In turn, the final patterns produced—the actual markup and CSS and JavaScript—should be influenced by the resulting principles: the code should be maintainable, readable, and modular. So at the same time as we were figuring out high-level principles, we are also defining an in-house coding style.

In-house code style

Now here’s the thing about coding style: while it should ideally be informed by your design principles, there’s another factor that overrides everything else—what coding style is preferred by the developers who will be inheriting your code?

When it comes to things like tabs vs. spaces, or indentation, or naming variables, what matters is not which style you use, but that everyone is using the same style.

So, for example, I favour tabs over spaces. And I don’t tend to camelCase variable names in JavaScript. And I don’t like indenting my markup (I make judicious use of new lines instead). But I’m in the minority. I could try to force my style on everyone else at work but that wouldn’t be very productive. It’s far more important that everyone settles on the same style—any style—than it is for a coding style to be “correct.” The only “correct” coding style is the one that everyone is agreeing to use.

Mind you, people who write JavaScript functions with the opening curly brace on a new line are just plain wrong.

Sharing pattern libraries

I’ve been huffduffing talks from this year’s South by Southwest, revisiting some of the ones I saw and catching up with some of the ones I missed.

There are some really design and development resources in there that I didn’t get to see in person:

One talk I did get to see was Andy’s CSS for Grown Ups: Maturing Best Practices.

CSS for Grown Ups: Maturing Best Practices on Huffduffer

It was excellent.

You can have a look through the slides.

He talks about different approaches to creating maintainable CSS for large-scale projects. He touches on naming conventions for classes, something that Nicolas Gallagher wrote about recently. And while he makes reference to SASS and Compass, Andy makes the compelling point that’s what more interesting than powerful tools is the arrival of powerful approaches like SMACSS and OOCSS.

Over and over again, Andy makes the point that we must think in terms of creating design systems, not simply styling individual pages—something that Paul has also spoken about. One of the most powerful tools for making that change in thinking is in the creation of style guides for the web and Paul has even created blog dedicated to the BBC’s style guide.

Andy referenced the BBC GEL style guide in his talk but pointed out that because it’s published as a PDF rather than markup, it isn’t as powerful as it could be—there’s inevitably a loss of signal when the patterns are translated into HTML and CSS. Someone from the BBC was in the audience, and in the Q and A portion, acknowledged that that was a really good point.

After the talk I got chatting with Lincoln Mongillo who worked on the recent responsive redesign of Starbucks.com. He mentioned that they created a markup and CSS style guide for the project. “You know what would be really cool?” I said. “If you published it!”

Here it is. It’s a comprehensive library of markup patterns; exactly the kind of resource that Anna wrote about in 24 Ways.

In my experience, creating a pattern library for any project is immensely valuable, whether you’re working in a team of two or a team of two hundred. I’ve found they work well as the next step after Style Tiles: a way of translating the visual vocabulary of a site into markup and CSS without getting bogged down in the specifics of page structure or layout (very handy for a Content First approach). The modularity of a pattern library enforces a healthy .

I’m really pleased to see more and more pattern libraries being made public. That’s one of the reasons why I shared my pattern primer and Dan shared his Pears theme for Wordpress:

Breaking interfaces down into patterns has been immensely helpful in learning and re-evaluating the best possible code to implement them.

But Pears isn’t about how I code these patterns—it’s a tool for creating your own.

I love that. These style guides and pattern libraries aren’t being published in an attempt to provide ready-made solutions—every project should have its own distinct pattern library. Instead, these pattern libraries are being published in a spirit of openness and sharing …a way of saying “Hey, this is what worked for us in these particular circumstances.”

For that, I am very grateful.

Typing up

I’ve been making some tweaks to the CSS for the default skin here at adactio. If you only ever read via RSS then you won’t have noticed but I’ve been adjusting the vertical rhythm.

I also wanted to get some horizontal alignment: I wanted to make sure that the bottom of the first heading in the main column lined up with the baseline of the first heading in the sidebar.


My basic unit is 20 pixels: a font size of 12 pixels with a line height of 1.6667. Whatever sizes I made the headings, I wanted to be sure that they were multiples of this basic unit.

body {
 font: 12px/1.6666 Helvetica,Arial,Verdana,sans-serif;
body * {
 font-size: 1em;
* html body {
 font-size: 76%;

Because Internet Explorer refuses to resize text specified in pixels, I’m using the * html hack to give it a percentage value. Using any kind of hack—or filter—makes me feel slightly icky. Once I’ve established the base font size using pixels, percentages, or any other unit, I can use ems to scale up and down from here on out.

The level two heading in the main content takes up 40 pixels in total (twice the basic unit). The font size is 24 pixels, the top padding is 8 pixels and the bottom padding is also 8 pixels.

h2 {
 line-height: 1;
 font-size: 2em;
 padding-top: 0.3333em;
 padding-bottom: 0.3333em;

level 2 heading

So while the overall size is 40 pixels, the descent is at 32 pixels: 40 minus 8 (the bottom padding).

I wish I could accurately calculate the baseline but as far as I can tell, font-size is calculated from the ascender height to the descender height. In the absence of any reliable way to pinpoint the baseline, I’m going to have to work with where the descent begins instead.

Level three headings also take up 40 pixels in total but the space is apportioned differently. The font size is 18 pixels, the bottom padding is still 8 pixels but the top padding is 14 pixels.

h3 {
 font-size: 1.5em;
 padding-top: 0.7778em;
 padding-bottom: 0.4444em;

level 3 heading

The descent is still at 32 pixels: 18 plus 14.

The same pattern follows through for level four headings. The font size is 16 pixels, the top padding is 16 pixels and the bottom padding is 8 pixels. So the overall size is still 40 pixels (twice the base unit) and the descent remains at 32 pixels (16 plus 16).

h4 {
 font-size: 1.3333em;
 padding-top: 1em;
 padding-bottom: 0.5em;

So far, so good. With a little bit of addition, it isn’t too hard to ensure that everything slots nicely into the rhythm established by the base unit.

It gets a little trickier with the content in the sidebar. There, the basic unit has been scaled down to 15 pixels: a font size of 10 pixels with a line height of 1.5.

.box {
 font-size: 0.8333em;
 line-height: 1.5;

I wanted to make the bottom of the level three heading in the sidebar line up with the baseline of the level two heading in the main content, but I still wanted everything in the sidebar to follow its own vertical rhythm.

The font size of a level three heading in the sidebar is now scaled down to 15 pixels (18 pixels multiplied by 0.8333). I’ve changed the top padding to be 17 pixels and the bottom padding to 8 pixels.

.box h3 { padding-top: 1.1333em; padding-bottom: 0.5333em; }

level 3 heading in the sidebar

This gives me the descent at 32 pixels that I wanted. Unfortunately, the overall size of 40 pixels isn’t a multiple of the base unit of the sidebar (15 pixels).

Further down the page, there are so many factors influencing the positioning of all the elements that it’s almost impossible to guarantee any kind of horizontal alignment between both columns. Still, I was happy to get things lining up at least at the beginning of the page.

all the headings

You can peruse the style sheet if you like. You’ll see that I’ve also made some changes to the fonts I’m using. Gone are the headlines set in Verdana with body copy in Trebuchet MS. Instead, I’m using the oh-so-hip Lucida Grande for the body with some negative-spaced Helvetica for the headlines… the same kind of headline style I’ve been using in my presentation slides.

I really ought to tweak the vertical rhythms on all the other skins too but I’m not sure I can face all the maths just yet.

In the meantime I’ll be doing my homework by re-reading Richard’s classic 24 Ways article and Mark’s trials with incremental leading.

all the headings, animated

Print stylesheets

CSS Naked Day was fun. It felt almost voyeuristic to peek under the CSS skirts of so many sites. It also made me realise that the browser default styles are what people are going to see if they decide to print out a page from many CSS-based sites.

I’ve had a rudimentary print stylesheet in place for Adactio for a while now, although I should probably revisit it and tweak it some time. But a lot of other sites that I’ve designed have been woefully lacking in print stylesheets.

For instance, the situation with the DOM Scripting site was brought home to me when I received this message from Adam Messinger:

Would it be possible to get a print stylesheet for the errata page that does a better job of preserving the table layout? As it is now, it’s sometimes hard to tell which page numbers match up to what errors. Just some borders on the table would help a lot.

That one made me slap my forehead. Of course! If ever there was a web page that was likely to be printed out, the errata for a printed book would be it.

As well as adding borders to the errata table, I set to work on creating a stylesheet for the whole site. It was fairly quickly and painless. I hid the navigation, let the content flow into one column, set the font sizes in points and used a minimum amount of colour.

DOM Scripting blog on screen DOM Scripting blog in print

I did much the same for Jessica’s site, WordRidden.

WordRidden on screen WordRidden in print

Principia Gastronomica was crying out for a print stylesheet. Half of the entries on that blog are recipes. Most people don’t have computer screens in their kitchens so it’s very likely that the recipes will be printed out.

A lot of the entries on Principia Gastronomica make heavy use of images. Everyone likes pictures of food, after all. I was faced with the question of whether or not to include these images in the printed versions.

In the end, I decided not to include the images. Firstly, it’s a real pain trying to ensure that the images don’t get split over two pages (page-break-before would be a draconian and wasteful solution). Secondly, I bowed to Jessica’s wisdom and experience in this matter. She often prints out recipes from sites like Epicurious and, when she does, she wants just the facts. Also, these are pages that are likely to printed out in the home, probably on a basic inkjet printer, rather than in an office equipped with a nice laser printer.

Principia Gastronomica on screen Principia Gastronomica in print

If you’re implementing a print stylesheet for your site, I highly recommend reading Richard’s guide, The Elements of Typographic Style Applied to the Web. All the advice is good for screen styles, but is especially applicable to print.

These articles on A List Apart are also required reading:

In an interview over on Vitamin, Eric makes the point that context is everything when deciding which stylesheets to serve up. Clearly, articles on a A List Apart are likely to printed out to be read, but the front page is more likely to be printed out to get a hard copy of the design.

For a detailed anatomy of a print stylesheet, be sure to read the latest in Mark’s Five Simple Steps to Typesetting on the web series: Printing the web.


My site has no stylesheets (“how does it smell?”, etc.) but you probably won’t even notice because chances are your reading this in a feedreader.

In any case, it’s nice just to look at the flow of the document sans styles. Notice the “More information” h2 tag that is normally hidden from view. With styles enabled, the visual layout makes this heading redundant but without styles, or for non-visual user-agents, it’s a useful marker.

The man responsible for this CSS nakedness is Dustin Diaz, himself no stranger to nudity.

I had a pleasant chat with Dustin yesterday which forms the basis for the latest episode of his podcast. It was fun for me. I don’t know how much fun it’ll be to listen back to. I ramble on about JavaScript, comments, food blogging and George Clooney. Listen for yourself.