High-fidelity design mock-ups have established themselves as a waypoint within the process of website making. Somewhere between the initial briefing and final deployment lies the well honed Don Draper reveal followed by — and who are we kidding? — client sign-off.

Designing with Code

Some responsive design aficionados are keen to scoff at this practice. If you’re not “designing in the browser” it’s time to get with the program. Their manifesto being that design mock-ups in [software of choice] cannot possibly be appropriate any longer.

Has responsive website design really changed the game that much?

Not in the slightest. First and foremost there exists a logically naive assumption that working directly with the medium is a shortcut to success. Or indeed the easiest way to find a solution. Secondly, I’m raising a bit of a straw man here, I hope. I don’t for one second believe anyone actually feels liberated designing in code alone without any in-between conceptualisation. It’s hard to know for sure with all the conference soundbites so often repeated.

Web design, of course, is more than just applying visual style. It requires aspects of user research, information architecture, content hierarchy, state and interaction design. The explosion in web-accessible devices has only highlighted flaws in what was deemed a suitable result.

The browser gives us direct feedback on what’s becoming an ever more difficult and scrutinised task. With that said, I’m hard pressed to think of anything more stifling than to use HTML & CSS to achieve the waypoints that lead to a final design. It’s a horribly tedious and distracting way to express creativity. This idea shuns high-fidelity design mock-ups for another equally inadequate extreme. The browser is a terrible tool for design. Sure, both methods can deliver a website, but are these polar opposites our only option?

A Matter of Process

Rather than dropping everything we know — which seems to be the sentiment behind the “RWD has killed Photoshop” notion — we need to adjust our process so that we can develop alongside design. Agile, not waterfall.

Getting this right allows us to see the actual in-browser experience while design can happen outside of the browser. Where it can flourish. Where common sense tells us text rendering will vary. Where imagination allows us to mentally visualise fluid components as we sketch them. Iterate and adapt quickly. Experiment with many mediums.

That doesn’t mean it’s ever wrong to make design decisions by editing code now and then — I do it often — but there’s no reason to impose this limitation. Intermediates exist.

Half Marathon

At the end of May I’m attempting the Edinburgh half marathon — 21 kilometres of pain! For whatever reason I was fed up last August and figured a jog would de-stress. I barely managed 500m but from that day forward running has changed my outlook for the better.

Being a freelancer has given me the flexibility for hour-long runs during the day. I was enjoying the late evening runs exploring East London but those nights weren’t the most social of activities. I was surprised at how difficult I found the transition to daytime. I suppose it was a lot easier to zone out under moonlight. That and the elevation in the Pennines is a killer.

I run so often now I suppose my career is shaping itself around this training. I’ll probably do an official marathon at some point to tick it of the bucket list. I’m not one for organised events though, I just enjoy the simplicity of stepping out into the fresh air.

Personal Projects

Aside from general hacking around and blogging, I’ve already published a couple of projects. The first release for my personal to-do/list app Macaque is under regular use. I’ve also refined and shared my front-end starting point and the process behind it. Back in March I gave my first conference talk at Responsive Day Out.

I’m making a conscious effort to limit all work — client or self-initiated — to “working hours”. Anything from 6–8 hours per day. Between 9am and 6pm. I want to avoid the temptation of working irregular hours, early or late. That means a choice between paid client work or unpaid self-initiated work. However, I don’t quite see the latter that way. While income isn’t direct, I’d never have landed on my feet had it not been for my writing and projects outside of full-time employment over the last five years.

I see personal projects as my most valuable lead generation skill. To date I’ve had a pleasant array of clients. A few referrals but most have been enquiries.

Client Work

I’m based in the UK but the web being the web my enquiries have been global. Initially I was skeptical of working with international clients but I’m already entering my 4th country — outside the British Isles — in as many months, figuratively of course.

I’m using FreeAgent to manage my business — watch out, referral link! It’s an excellent website for accounts, invoices, time tracking, tax returns, it even has a direct feed to my bank account. Like many of my peers I drafted a contract based on Andy Clarke’s Killer Contract.

Touch wood my income will remain steady. I like the idea of being transparent in regards to finance and I’ll do an “annual report” if I’m still afloat next year. I have several projects in mind to generate passive income and a few ambitious start-ups ideas I may bootstrap. Client work will be my bread and butter for a while yet but I want to explore other avenues from day one.

If you want to work with me get in touch and tell me about your project.

A Good Decision?

All in all I’m very happy with the decision I made last year to pack it all up and start a new life. Of course, I miss friends in London and the regular tech meet-ups.

Despite great moments, with the freedom I have now I can’t see myself ever going back to my old lifestyle. I’ll never regret moving to London and I would never have been able to go freelance without my experiences there.

What is Origin?

Starting a new project for me used to mean cobbling together and rehashing code from past work. This year I started to consolidate everything into my own personal boilerplate to kick start front-end development.

“Origin” is my code name for this on-going project (everything needs a name). It’s not a behemoth of code like Bootstrap or Foundation. It’s specifically tailored to suit the websites I make. It will never be complete and it will evolve dramatically as my preferences and needs change.

This is not a framework I expect others to use ‘as is’ but I decided to make it public because:

• A lot of people asked kindly
• I learn from similar projects by other developers
• It will serve as a reference point when discussing particular techniques

If you care to poke around the code is on GitHub. Or you can see the GitHub page for my starting pattern library. This doesn’t include everything I consider a “best practice” and a lot of things aren’t commented. Make of it as you will — just please don’t include it in a “10 new resources for developers” blog post!

If you like the idea of automated builds and need a mature Grunt workflow then give Yeoman a test drive. For a BEM-style CSS framework there’s Inuit.css. And if you need to prototype something fast, Bootstrap and Foundation have their uses.

Defining support

Supporting a browser to me does not mean that a website will be identical in form and function. That is a fool’s errand leading to an unmanageable mess of polyfills and hacks.

I consider a browser supported if I actively test the core content and functionality — integral to the purpose of the website — is accessible. I’ll also take steps to ensure the quality of design and overall experience is on par with the browser’s capabilities.

I divide attention proportional to browser usage. I’m not going to deliver the best possible experience IE7 is capable of but it’s certainly not going to be broken.

Deciding where to test

When I tell people I often support IE7 the common response is “why?” — followed by an assertion that browser statistics show IE7 usage is now insignificant enough not to warrant attention. How could you possibly know that? I haven’t told you which website I’m building yet!

You see, aggregate statistics are a useful baseline — at least localised, not global — but they become irrelevant if you have data for an existing domain. I look at historical usage numbers, project for the foreseeable future, and only then do I start to decide the appropriate range of browsers to test in. Looking at numbers is not enough to make the final decision.

Other factors to considered include:

Budget and customers

Projects are more often than not limited in the funds department. Sometimes it’s just not financially viable to support and test the long-tail of browsers and devices. This can be a tricky situation in regards to client expectations.

Is the cost of development going to outweigh the loss in revenue that comes from abandoning the less technically astute customers? Imagine a website that sells high value products. A new sale is worth thousands of pounds; suddenly Mr. IE7 user — whom can’t get past the JavaScript error on the checkout form — begins to look like a good investment after all.

For this reason alone a blanket list of supported browsers shouldn’t be set in stone. When I wrote about browser support last year I said:

A traditional browser support list is completely ignorant of a website’s requirements. It wrongly aims for parity across browsers and leads to much wasted time and money.

Study requirements in detail. Adjust design and development practices to suit the bottom line. Doing this will tame the client’s expectations and make them confident with your advice.

Effort and time

When the previous iteration of dbushell.com launched last March I supported IE6. Yes, that’s a six. Why? Because the effort required was minimal. Even though the nature of my website means that Internet Explorer as a whole is barely represented in the logs. When I realigned this year the design was more ambitious and I moved the boundaries up to IE8 and above.

There is no universal scale for effort. It comes down to your ability, but if you decide a website must include the latest trendy 3D parallax effect prior to reading the brief you have no right to rant about the state of browsers or the ignorance of users.

The hard fact is good — appropriate — design for the web is not always glamorous. That means reining in the baseline experience and utilising solid progressive enhancement techniques.

Browser support only becomes a pain if you ignore reality.

That may mean saying “no” sometimes to an effect someone has been wowed by on their latest iPad app. And that is probably for the better.

• Part 1: Macaque: A New Project
• Part 2: Test Driven Development
• Part 3: Prototyping

— you’ll know I’m building a to-do app with Node and Ember. Macaque’s development has reached the point where I can use the app itself for issue and feature tracking. If you want to see my plans going forward you’ll have to clone the repository and run the app.

I’ve forked Macaque to use as my personal list app over the next few weeks while I focus on client work. It has a couple of known bugs but nothing that can’t be fixed with a good ol’ refresh. Hopefully when I jump back into development Ember Data will be more mature.

Ember Data and MongoDB

Using Ember has been a great learning exercise. After plenty of head scratching and many hours digging around in the source I’m now feeling comfortable with the core concepts.

If you’re using MongoDB behind your API here’s a few things I’ve learnt:

Primary IDs

MongoDB’s default primary key is an ObjectId in the _id field. Ember Data doesn’t like the underscore. Initially I was using Mongoose to add virtual id properties. It’s actually a lot easier to manage this client-side by extending the RESTAdapter:

Macaque.RESTAdapter = DS.RESTAdapter.extend({
    url: 'http://localhost:3000',
    namespace: 'api',

    serializer: DS.RESTSerializer.extend({
        primaryKey: function(type) {
            return '_id';
        }
    })
});

Macaque.Store = DS.Store.extend({
    revision: 12,
    adapter: Macaque.RESTAdapter
});

In here you can also specify the URL and namespace for the API.

Serializing the Primary ID

When the API is called to load a record its ID is serialized in the URL. For example, when a list in Macaque is viewed the RESTAdapter loads data from this endpoint:

http://localhost:3000/api/lists/5175a9dc67a7a40000000003

On rare occasions this will fail and you’ll see the ID has been serialized in this format: 5.1755256517945e — note the numerical notation. What’s going on?

The answer lies within the Serializer:

/**
    A hook you can use to normalize IDs before adding them to the
    serialized representation.

    Because the store coerces all IDs to strings for consistency,
    this is the opportunity for the serializer to, for example,
    convert numerical IDs back into number form.

    @param {String} id the id from the record
    @returns {any} the serialized representation of the id
  */
  serializeId: function(id) {
    if (isNaN(id)) { return id; }
    return +id;
  },

If the ID can be converted to a number in JavaScript it will be. ObjectId’s in MongoDB are a 12-byte construct. Usually alpha-numeric and thus “is not a number” — but not always. To fix this problem we can extend the RESTSerializer further:

Macaque.RESTAdapter = DS.RESTAdapter.extend({
    /* ... */
    serializer: DS.RESTSerializer.extend({
        /* ... */
        serializeId: function(id) {
            return id.toString();
        }
    })
});

(I’ve removed the previous code for brevity.)

Now our ObjectId values are never inadvertently converted to numbers. With these two changes Ember Data will play nicely with your MongoDB records.

Many More Things…

This is something I’ve been experimenting with so I’m not convinced it’s actually the correct approach. I thought it was worth sharing nonetheless because I’d imagine it’s a common issue. Anyway, if you have many-to-many relationships like I do in Macaque:

Macaque.List = DS.Model.extend({
    /* ... */
    tasks: DS.hasMany('Macaque.Task')
});

Macaque.Task = DS.Model.extend({
    /* ... */
    lists: DS.hasMany('Macaque.List')
});

The API convention is to provide an *_ids array like this GET response for a list record:

{
    "list": {
        "_id": "5175786e3351480000000006",
        "task_ids": [
            "517579ab3351480000000008",
            "51757a0b3351480000000009",
            "51757adc335148000000000a"
        ],
        "is_hidden": false,
        "modified": "2013-04-22T18:01:00.959Z",
        "created": "2013-04-22T17:50:38.000Z",
        "name": "Macaque Testing"
    }
    "tasks": {
        /* task data here... */
    }
}

In this example I can side-load the three task records by including their data in a tasks object in the JSON root. That’s cool, but problems arise when I edit and save a record in Ember. When I commit the data a PUT request is sent to the API like this:

{
    "list": {
        "_id": "5175786e3351480000000006",
        "is_hidden": false,
        "modified": "2013-04-22T18:01:00.959Z",
        "created": "2013-04-22T17:50:38.000Z",
        "name": "Macaque Testing"
    }
}

Note the child task IDs are never sent back to the server.

From what I understand the hasMany relationships are only serialised in the JSON if you’re specifically embedding all data in every request. You can tell Ember Data to do this…

Macaque.RESTAdapter.map('Macaque.Lists', {
    'tasks': { embedded: 'always' }
});
Macaque.RESTAdapter.map('Macaque.Tasks', {
    'lists': { embedded: 'always' }
});

…but it’s not very practical; that’s a lot of data where an array of IDs would suffice. I’ve found a workaround is to extend the RESTSerializer — once again — to include the ID array:

Macaque.RESTAdapter = DS.RESTAdapter.extend({
    /* ... */
    serializer: DS.RESTSerializer.extend({
        /* ... */
        addHasMany: function(hash, record, key, relationship)
        {
            if (/_ids$/.test(key)) {
                hash[key] = [];
                record.get(this.pluralize(key.replace(/_ids$/, ''))).forEach(function(item) {
                    hash[key].push(item.get('id'));
                });
            }
            return hash;
        }
    })
});

This will now include the hasMany relationships in data sent back to the API.

When I send a new task to the server — including list_ids — I can then update the corresponding list(s) relationships in the database. The server returns the new task with its _id which Ember can confirm. Once the ID arrives I can reload the relevant lists to ensure their task_ids are up-to-date and finally make the task visible.

I’m not entirely convinced this technique is the best way to maintain many-to-many relationships. I haven’t tested the { embedded: 'always' } technique so I can’t confirm Ember Data actually handles this correctly. Either way it feels overkill.

Am I doing something wrong, or do you know a better way? Give me a shout on Twitter or comment on Hacker News.

Twitter Bootstrap is a great UI toolkit for prototypes. Don’t let it seduce you, my underlying code ain’t pretty!

Learning Curve

After the excitement of last weekend’s test driven development phase I hit hard times and considered throwing in the towel once or twice. I have very little experience with MVC frameworks. In fact, with the exception of a terrible two days flirting with Backbone, I’ve have none.

What exists in the Ember Guides is very good but far from complete as you’d expect from such a new technology. Ember Data is still under development so little documentation exists. For someone who has ‘designer’ written on his business cards; this is very slow learning. StackOverflow has rescued me many times. Ember Watch is also an excellent resource. Progress may be glacial, but I’m moving forward. Macaque is far from complete but you see the code on GitHub.

Experimental

Although I’m kind of ad-libbing this entire thing, I’m keen to tie in several project methodologies. I started with a half-hearted attempt at agile user stories (user can use to-do app). Unsurprisingly, it’s transpired that development is now meandering through whatever aspects of Ember I happen to figure out. This evolutionary approach isn’t quite what I had in mind. Once I feel more comfortable with Ember I’ll take a step back and refocus the project scope.

This process is very good for agile design. Right now I’m letting development lead the experience and making design decisions as and when required. That’s not much right now, which is a good thing. I’m not over committing to style or interaction that could prove impossible later (or ill-advised). It may be a simple concept but designing whilst actually using the app is a lot better than designing from imagination alone.

Update: Part 4 — Ember Data and MongoDB

Isn’t it beautiful?

As you can see, my big ideas for Macaque focus on design but I am building it end-to-end. For the supporting back-end I’ve spent the weekend writing and testing an API. I could have thrown together a diabolical concoction of PHP and MySQL and been done with it. However, since I genuinely plan to use this app, I’ve opted for an ultra-trendy Node solution.

Testing an API

My app has a very simple RESTful API that interfaces with a Mongo database. My API can retrieve, edit, and add items to one or more lists. That’s innovation right there. You can follow my code progress on GitHub.

In fairness, It’s probably the least impressive API one could possibly development but that doesn’t make it any easier to test. Even if the front-end wasn’t lacking in functionality at this stage it would be a tedious way to find bugs. Inspired by my old office mates at UVd and Browser, I’ve spent some time implementing test driven development into my workflow.

For this I’ve used Mocha to write a series of tests for my API. Each test calls the API and then checks the returning data. For example, to make sure /api/lists is returning an array:

describe('Lists', function() {
    it('should return an array of lists', function(done) {
        macaqueAPI('/api/lists', function(data) {
            var json = JSON.parse(data);
            assert.equal(true, Array.isArray(json.lists));
            assert.equal(false, isNaN(json.lists.length));
            done();
        });
   });
});

When I run all tests from the command line:

Pretty cool, right?

This effort has already paid dividends when I came to refactor my API to make use of Mongoose — a library that provides schema, data validation, and generally easier coding. I had to rewrite much of my code but running the tests again gave me instant confidence it was correct.

Onwards

I’ve already got Ember working with the API to output list and task templates. It’s now time to focus on design of the front-end user interface.

Following my experience with Mocha I’m hooked on automated testing and I look forward to bringing it into the browser with other frameworks.

Stay tuned for prettier pictures.

Update: Part 3 — Prototyping
Update: Part 4 — Ember Data and MongoDB

This project exists because:

• I want to learn more Node and Ember
• I’ve failed to find a list app I like (oh lord, please don’t suggest one)
• I’d like to own my data and ‘reinvent’ the list app experience (for myself)

If you care you can follow my progress on GitHub. I’m keeping the features stupidly simple because there is already so much to consider.

Starting point

I’ve played with Node before but I’m starting Ember development with a blank slate. This weekend I’ve been casually introducing myself.

While I dived into Ember routes and templates I threw together a quick Express app to serve fake API data. I feel comfortable with that now. I can see a list of tasks! The next step is add, edit, and delete functionality. That means going back to data storage and a real API. I want to do this quickly because it’s not my main interest.

Moving forward

Once the API is ready I’ll return to Ember and implement the functionality. For UI design I’ll start with either Bootstrap or Foundation so it’s not ugly. I’ll be designing the final interface as I learn Ember and will eventually throw out the framework and rebuild the HTML & CSS from scratch. The interaction design I’m envisioning will require advanced Ember concepts (I expect) so it will be useful to having a basic version in place first.

I plan to publish everything under the MIT license prior to implementing my advanced design. I think it will be a helpful review project for future beginners.

And if I get that far? I’m plotting the heinous crime of parcelling the website in a native Android wrapper and installing it on my phone.

Words cannot express how happy that would make me.

Before I continue with any of this I need an icon! If you see me tweeting a poorly traced Macaque face, this is why. If you too are interested in Ember, aside from the oficial docs, Robin Ward (Evil Trout) has a great Ember series on his blog.

Update: Part 2 — Test Driven Development
Update: Part 3 — Prototyping
Update: Part 4 — Ember Data and MongoDB

I’m aware I’m reinventing more than a few wheels here. This project has always been about starting from the ground up and questioning every choice.

* Yeah, I’m a big advocate for agile “decide in the browser” web design/dev, but I have to admit that a beautifully maintained PSD deliverable still feels like Christmas.

Boilerplate

I’ve always maintained a personal set of HTML & CSS files to use as a starting point for any build. Mostly good practices, general preferences, and stuff I forget like the favicon.

This practice has never actually helped me remember the favicon — you have to love boilerplate deployment — but after catching up with Chris Coyier’s screencast I have a new found love. I’m currently writing the favicon-first manifesto…

Repository

I use Git as source control for everything. This includes my boilerplate which I can evolve and fork for new projects. Starting a new build requires these steps:

1. Initialise a new Git repo
2. Merge in my boilerplate code
3. Run npm install to pull in dependencies (basically Grunt + tasks)

Sublime Text 2 and iTerm (with oh-my-zsh) are my apps of choice for code management.

And yes, I work on the master branch and name my devices after monkeys.

As you can see my project directory structure looks like this:

• build/
• src/
• tasks/
• templates/
• Gruntfile.js
• package.json
• README.md

The build directory is generated by Grunt and never committed to Git. It contains the final static website with no outside dependencies. I can view it in the browser, archive and email to a client, toss on a server, or just delete and rebuild it entirely for a laugh (that novelty wears off).

The src directory contains the actual editable source and original assets; Sass, JavaScript, SVG, web fonts etc. The templates directory contains HTML (I should probably move this into src for consistency). My HTML Grunt task — new and improved* — lets me separate HTML includes and reference relative assets or paths. All without server-side scripting.

* use at your own risk.

The basic principle here is to keep a single source for all working assets. If that isn’t the final output — e.g. Sass or un-minified JavaScript — the output should get compiled automatically. Similarly, I don’t want to manually maintain PNG fallbacks for vector graphics if they can be built from source. The whole set up is complex but the act of building is simplified.

The complete set of build tasks can be quite slow so I need to build individual components as and when they are modified.

Who watches the watchmen?

I’ve been using Compass for a long time to generate CSS. With pre-processors you get a nice command line programme to watch for changes and automatically generate plain CSS output. This alleviates the burden that an extra step adds.

With my new practice of separation between source and build I need a more powerful watcher. Grunt watch comes to the rescue. For each requirement I instruct it to watch a set of files and then perform a specific task. HTML is edited? Rebuild it. CSS changes? Recompile it. SVGs are modified? Optimise and create raster fallbacks (OK, I haven’t perfected that yet).

Whenever I’m working on a project I just run grunt watch and let it go.

Next step

Like I said, none of this is particular ground breaking but I’m learning a huge amount by starting from scratch. I could jump straight into an existing solution like Yeoman but I’d never really understand the “why” behind the process. My quest is automation and I’m already making life easier. Even with the less than optimal set of tasks I’ve hacked together.

I’ve written a lot about facilitating the build process but not the actual practice of writing HTML, CSS, and JavaScript itself. The most time consuming thing of all. I’ll follow up on that soon, for now read my 5 Tips for Responsive Builds and be sure to read Dave Rupert’s excellent article on Responsive Deliverables.

This article is my response to that question.

Anatomy of a grid system

Responsive grid systems can be broken into two main parts:

1. A CSS construct for the basic grid cell/unit
2. A catch-all methodology to cover generic column layout

Most systems I see feature a largely trivial decision around part #1 and a load of nonsense for part #2 — in my opinion. I don’t mean to insult those who attempt this. Many smart minds have produced very interesting results worth studying. I call it nonsense because overcomplicating the problem will always produce crazy complex solutions. I believe this comes down to a desire to abstract code too far.

This is how I handle responsive layout:

Part 1 — the basic unit

There are numerous ways to achieve this. The principle is to align elements as columns with an even gutter between them. Here’s a five-column example:

I’d be worried if that surprised you but illustrations make a long article look nice. From experimentation last year I’ve been using this CSS construct ever since:

.grid {
    @include clearfix;
    margin: 0 -1.5em;
}
.grid-unit {
    box-sizing: border-box;
    display: block;
    float: left;
    padding: 0 1.5em;
    width: 100%;
}
.layout .grid-unit {
    width: 20%;
}

The .grid class acts as a container for grid units. The unit padding and negative container margins make for very tidy alignment — I’ll come back to .layout later.

Units are outlined in black in the diagram below:

You can achieve the same thing with inline blocks or table-cell display. I called this choice trivial. It’s not entirely inconsequential. You need to consider browser support and it will affect how you style content inside the grid.

Personally I like to separate these layout elements with an extra div to avoid conflicts with visible content styles. You may gasp in horror at the thought of extra markup — I’ll be in the pub Friday evening by 6pm. That’s literally the only significant consequence.

When support for CSS Flexbox hits critical mass I’ll likely transition towards that for grid units. It has a magic order property that will solve responsive layout forever.

Part 2 — responsive layout

This is the meat and potatoes of a responsive grid system and the reason I ultimately reject many of them. The ones that try to offer pre-defined classes for every possible column arrangement are a lost cause.

In my opinion there’s a fundamentally flawed logic in trying to write a generic catch-all solution. You’re always going to end up with hundreds of unnecessary variations. If you use classes it’s going to look hideously confusing. If you don’t use classes it’s going to look horrendously perplexing.

I write responsive layout CSS on a per-module basis as-and-when required. Let’s say I have four feature boxes on my home page:

By default they’re stacked vertically (I may progressively enhance to a fancy carousel but that’s beside the point). On a medium sized viewport I want them two-by-two. Widest breakpoint; one row, four columns.

My HTML is as you’d expect, ignoring possible semantic choices like section or article elements. I may not even need an extra div to style my features:

<div class="grid home-features">
    <div class="grid-unit"><!-- feature 1 --></div>
    <div class="grid-unit"><!-- feature 2 --></div>
    <div class="grid-unit"><!-- feature 3 --></div>
    <div class="grid-unit"><!-- feature 4 --></div>
</div>

The additional CSS I need is minimal:

@media screen and (min-width: 40em) {
    .home-features .grid-unit {
        width: 50%;
    }
}
@media screen and (min-width: 60em) {
    .home-features .grid-unit {
        width: 25%;
    }
}

In practice it’s a bit more complicated because I’m ignoring vertical spacing here but my basic principle still applies: avoid defining layout until I need it.

(In practice I actually use a lot of CSS preprocessor techniques to avoid multiple classes.)

Abstraction

This doesn’t mean I can’t abstract and reuse common layouts. If my features module is used beyond the home page I just apply CSS with a non page-specific class name.

Say I reuse the features module on the “blog” page but it’s now nested inside another layout with half the available width? I simply abstract the common visual styles with a .features class and apply different layout and breakpoints using .home-features and now .blog-features (or a hook higher up in the DOM).

You can’t define good responsive breakpoints until you know content and location. That’s another reason to avoid pre-defined systems.

Job done

I’ve build websites large and small with this philosophy and I really don’t see a situation where it needs to be any more complicated. I love modular CSS as much as the next person but there’s a point where it becomes an abstraction too far. Don’t solve a problem until it exists. From my experience, trying to find a pre-defined system for every permutation of nested grids is a fool’s errand.

Design vs code

Finally, though a website is designed on a grid doesn’t me we have to replicate it entirely with a single code system. In my Passenger Focus case study I highlight the areas where my technique above kicks in (grid units are outlined in blue):

The header was designed on the grid but bespoke layout CSS was easier to manage.

So for those who often enquire about my responsive grid “solution” — it’s about 10 lines of code. Not a problem that keeps me up at night.