POSH

It’s tempting when embarking on a new project to reach for the easiest, off-the-shelf solution in the interests of getting something published as quickly as possible. There are a couple of problems with this approach, however.

Firstly, it leads you down primarily predetermined pathways (Bootstrap, Foundation, Skeleton… all have their own look and feel and if you’re not careful, you inherit this look and feel (more on that in a moment)). Secondly, when you use something off-the-shelf you rarely understand intimately how it works, inhibiting your ability to truly customise and craft it.

Designing with Defaults

The problem with frameworks is they come with out of the box design decisions that are difficult to break free from. Grid systems, typefaces (all too often Helvetica Neue), button styles, form controls…. All of this imparts its own look and feel to your work. The result? Your work looks like others’ work, not your own.

As Joshua Gross puts it in Please Stop Using Twitter Bootstrap:

Let’s be honest: a great many of us are tired of seeing the same old Twitter Bootstrap theme again and again.

Of course you can customise these frameworks, but few do, which is why we see a plethora of identical patterns emerging. All drawn from the same DNA, the result is a gene pool with too little diversity, a series of clones.

Add to this the fact that, if you’re like many a front-end designer or developer (or at least one who isn’t afraid to admit it), you have no idea how many of the files you’re using function. The result: It’s often safer to leave well alone. As Gross puts it, “It’s easier to use the defaults. You certainly can modify significantly … but most people don’t bother.”

Getting Under the Hood

As an alternative we might opt to start with HTML5 Boilerplate, “The web’s most popular front-end template.” Certainly HTML5 Boilerplate is design agnostic, and it draws together the talents of a hugely experienced team, however, download v4.2.0 (current at the time of writing) and, once you’ve unzipped it, you’re confronted with 36 confusing files. Google Analytics, CSS, jQuery, Modernizr… the list goes on.

Herein lies a different, yet equally challenging, problem. How to make sense of it all? I think we’re all agreed that designers need to be able to write markup and style it, but I’m sure a great many open the HTML5 Boilerplate payload and shudder. They see the crossdomain.xml file and have absolutely no idea what it does (I don’t, yet). Similarly, they see the following on line eight and are equally lost:

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

Of course, there’s nothing wrong with this, we can – should we choose – trust the collected knowledge of the team who built HTML5 Boilerplate. We often use off the shelf components, plugging in jQuery for example, but we should surely strive to understand the foundation on which we’re building at the most basic level?

Starting With Content

As part of my philosophy of starting from zero, I’ve decided to opt for some good, old-fashioned Plain Old Semantic HTML (POSH) to get the ball rolling. With every file, I’m adding richness, but I’m starting first and foremost with content, which I'm marking up using HTML5’s new semantic elements.

I’m reading as I go and I’ll shortly be publishing notes to accompany the files I’m making, where I'll outline the decisions I’ve reached and back them up with further reading material. It’s like (yet another) baptism of fire, but it’s worth it. I have to teach this, after all, so it’s good to keep up to speed with the latest thinking.

A by-product of starting with a solid foundation of semantic markup is that this page is responsive. Go ahead, do the browser-resize-shuffle and see. Of course, the web was always responsive, we just broke it when we went through that fixed width phase. More on that, too, shortly.