How browsers build pages

There are any number of guidelines and theories about how best to write sustainable CSS, and smacss (pronounced “smacks” apparently) is another of those. I was reading through the introductory chapters, and was interested to learn how browsers build pages.

The browser starts at the top and sees a body element. At this point, it thinks it is empty. It hasn’t evaluated anything else. The browser will determine what the computed styles are and apply them to the element. What is the font, the color, the line height? After it figures this out, it paints it to the screen.

Next, it sees a div element with an ID of content. Again, at this point, it thinks it is empty. It hasn’t evaluated anything else. The browser figures out the styles and then the div gets painted. The browser will determine if it needs to repaint the body—did the element get wider or taller? (I suspect there are other considerations but width and height changes are the most common effects child elements have on their parents.)

This process continues on until it reaches the end of the document.

This seems, to me, to be a very inefficient way of building a page since multiple “repaints” are necessary, but it is easy to forget just how fast and efficient modern browsers have become.

Below, you can view a vastly slowed down video of a Mozilla browser rendering a page using this method.

Pretty impressive, I think. But it still seems conceptually inefficient…

Using local colour variables in Less

One of the most time-consuming aspects of website design is when the customer wants multi-coloured menus—and for those colours to cascade through the other attributes on those site areas. This can involve lots of different selectors, and having to change them all to different colours can be a pain—and this is where using local colour variables in Less can save lots of time.

Standard colour variables

Consider the following set of declarations:

Now, imagine that these all had to be altered depending on the .site-area-x, and that we have huge number of selectors to restyle.

Obviously, we could simply declare our @color2, but then we have to go through and change the colour in all of the other declarations too.

And this needs to be done for each one of the eight different menu areas—it’s going to be pretty time-consuming.

Local colour variables to the rescue

There is a better way in which to do this—by using local colour variables. Consider the following set of declarations:

We now only have to change two attributes—the .site-area-x class, and the @site-area-colour.

OK, it’s not entirely automated, but it will take considerably less time than the first method.

Website wireframing

Some time ago I became a Beta tester of a website wireframing tool called MockingBird; our company has used it as a wireframing tool for some years now, and it has always served us very well.

MockingBird is an HTML5 application that enables collaboration on projects, and is extremely easy to use. This ease of use is partly conferred by the smallish number of widgets within the application.

As websites get more sophisticated, however, this selection of widgets seems a little limiting; personally, I had expected the creators to add more options after the formal launch of the application. They have not done so, and the blog has not been updated since December 2010.

Whilst I am not about to jump ship just yet, it seems natural to look around for other alternatives for our website wireframing needs, and so I followed a link to Moqups—another HTML5 website wireframing application, and apparently free.

I haven’t then experimented with it, but it does seem to have reasonable features—and a somewhat more design-oriented set of widgets.

But why have they adopted the awful kind of hand-drawn typeface for the text? It embodies everything that is awful about Comic Sans without actually being Comic Sans…

Generate a table of contents using JQuery

One of the under-used features of our company’s CMS is Virtual Documents: these are actually large HTML documents that can also be displayed and managed within the Media Manager in the same way as a “physical” file (such as Word or PDF). However, one of the ways that Virtual Documents could be made far more useful is through the ability to generate a table of contents.

Virtual Documents came about because one of our customers had a huge document library in Lotus Notes: they wanted to import these documents into our CMS, but maintain all of the permissions and access rights already applied.

The entire library was exported as XML-based PDFs, and we then wrote a parser to interpret and import the content (complete with styles), and also to gather and apply all of the access rights. The resulting imports became known as Virtual Documents.

A number of our customers have been interested in Virtual Documents, but felt that some features were lacking; one of these was pagination, but this could be by-passed by creating a table of contents that was derived automatically from the headings—as, indeed, Word and Pages do.

There has not been enough demand for us to devote heavy resources to this aim within the product itself, so I started looking around for front-end solutions. And I found a post by Janko at Warp Speed which details how to built a table of contents in JQuery.

It will need some tweaking to get it to behave with our current structure, but I believe that it is a very decent solution—especially the final scaled and fixed table of contents demo.

Writing sustainable CSS using SOLID principles

We all know what it’s like: you start off with the best of intentions—to write neat, sustainable CSS using all of the very latest fashions (DRY, OOCSS, etc.)—but then the clock is ticking and you find yourself rushing the project and producing a stylesheet that, whilst not totally awful, still resembles spaghetti.

This is a problem that only becomes compounded when you are writing Less: here the problem becomes one of lazy nesting and, next thing you know, not only do you have selectors that are 80,000 characters long but you have also “cemented” certain elements—you know that if the customer moves that slideshow from that position on that page, then the whole thing is going to fall apart.

Leaving aside the special considerations that you need to bear in mind when implementing designs onto a large CMS (which I intend to address in another post), writing sustainable CSS is absolutely essential to a web designer. The simple fact is that sites with well-written CSS will load faster, be easier to maintain (essential if your customers are regarded as partners), be more flexible (from a CMS point of view) and be generally more elegant.

Introducing SOLID Principles to sustainable CSS

There are, of course, many opinions as to what makes sustainable CSS: however, one of the best articles that I have read on the subject is this post on SOLID principles by Miller Medeiros.

SOLID is an acronym for five basic principles of object-oriented programming and design that when applied together can make systems easier to maintain and to extend over time. The term was coined by Uncle Bob and I’m pretty sure he didn’t had CSS in mind(although I didn’t asked him).

  • Single Responsibility Principle
  • Open/Closed Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

Now, this all sounds a bit too techie for me, but Miller goes on to explain the principles in  rather more detail.

Single Responsibility Principle

This principle states that an object should have only a single responsibility, and that responsibility should be entirely encapsulated by the object. When applied to CSS this means that we should separate structure from presentation, instead of creating a single class and/or element that does both, we should decouple them so you can change the skinning of the components without affecting the structure.

CSS rules should have a high cohesion, you shouldn’t normally see too many different kinds of rules grouped together. You shouldn’t have text styles + borders + colors grouped with dimensions + positioning and floats.

By doing so we can reuse the same modules inside a different container and increase the chance of reuse. It will also make maintenance easier since you can change the skinning without affecting the structure and can toggle the visual easily based on the context (eg. element with same structure but different colors).

This principle sounds sensible enough—and its particularly easy to address when using CSS pre-processors—but, in fact, it is usually the very first method to go out of the window when you are under pressure to deliver.

Open/Closed Principle

“software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”

That means that you should make it easy to overwrite/extend the base rules and should avoid editing the base classes.

You should only edit a base class if you are fixing an error, never add new behavior, otherwise you might introduce conflicts. That means that you should not change yourreset.css file or edit rules that affects multiple elements after the project is stable. Create a new class that augments it instead of editing it.

This is an easy principle to stick to, since it can save a lot of time: with the capabilities of Less, I quite often find myself writing things like this:

In Sass, you can use the @extend  class to do this even more sustainably. If you aren’t already doing this, then I heartily recommend that you adopt this methodology.

Liskov Substitution Principle

“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”

Classes that @extend others shouldn’t have a different behavior than the base class. You should be able to toggle between them without affecting the correctness of the app.

The idea behind this principle is that if you can swap Parent classes with their Children, without causing any undesired side effects, you will have a system that is more flexible and easier to understand. It will increase code reuse on cases that you couldn’t predict when the project started.

That means, modifiers should ideally affect only things that wouldn’t break the layout. If the base class doesn’t have a fixed height the child class shouldn’t have as well, the display and position also shouldn’t be changed.

Once again, this is a sensible principle that, again, often falls by the wayside.

Interface Segregation Principle

“many client specific interfaces are better than one general purpose interface.”

That means, it’s better to have multiple specific base modules than to have a single generic one. It will increase the cohesion of your modules and make code easier to refactor/change/maintain (since it reduces tight coupling).

Now, it has to be said that Miller does not seem to be entirely on board with this principle, or what it implies.

Sometimes it can be really tempting to create a base module that fits multiple scenarios trying to increase code reuse as much as possible. To be honest, lately I’ve been thinking that not all code reuse is a good thing. If you are doing it just for the sake of reusing(specially CSS) you might be increasing the coupling between modules without a need, that will make further changes harder to implement since it will cause a ripple effect to undesired modules (eg. changing the margin around an article in the homepage would also affect the margin around a blog post on the inner pages).

Which is fair enough.

Dependency Inversion Principle

  1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
  2. Abstractions should not depend upon details. Details should depend upon abstractions.

I like to think this rule on the CSS domain means that the container shouldn’t care about the existence and the visual style of its children as long as it behaves how it expects it to behave. For an .article component it shouldn’t matter how the .title is styled, as long as the title doesn’t break the layout. We should delegate the styling of child components to their own modules and do it in a way that the child elements can be swapped without affecting the parent element. This is the core idea behind OOCSS.

Nested selectors are a sign that you might be breaking this rule. Instead of making nested selectors like #sidebar .group > h3 you should create a new class .group-title. That way it can be an <h3>, <div> or any other element you need. It will be easier to create new modules with slightly different styling/behavior by simply swapping the dependencies (child elements). This also favors composition over inheritance.

It also couples with an absolute principle that I advocate: that you should avoid targeting the mark-up element whenever possible—especially in these days of shifting HTML5 specifications!


I have been adhering to most of the SOLID principles for many years without really knowing about it, but this article is extremely good at articulating why I have been coding in the way that I have.

Over the years, I have had to dive into far too many website implementations and then recoiled when I have seen the state of the CSS (let’s leave aside the HTML for the moment).

These experiences have convinced me that one of the most important issues facing our company—if not the web as a whole—is the production of sustainable CSS.

Apple Maps App

There has been a fair amount of grumbling in the technology press about the Apple Maps App released in iOS6—apparently it is not as good as the Google Maps that it replaced and, indeed, seems to direct people to the wrong place quite often.

However, as Kontra at CounterNotions points out, mapping is a complicated business, and Google Maps has had eight years to get where it is today—and it still advises that the best way to get from Ibiza to Valencia is to walk across the sea!

Furthermore, as Kontra also says, Apple has taken these gambles before—and they have paid off.

Q: Does Apple have nothing but contempt for its users?

A: Yes, Apple’s evil. When Apple barred Flash from iOS, Flash was the best and only way to play .swf files. Apple’s video alternative, H.264, wasn’t nearly as widely used. Thus Apple’s solution was “inferior” and appeared to be against its own users’ interests. Sheer corporate greed! Trillion words have been written about just how misguided Apple was in denying its users the glory of Flash on iOS. Well, Flash is now dead on mobile. And yet the Earth’s obliquity of the ecliptic is still about 23.4°. We seemed to have survived that one.

Personally, I have not had enough time to play with the Apple Maps App, but I do know that Apple partnered with turn-by-turn sat-nav maker TomTom to get a lot of the mapping information.

Which rather explains all these stories about sat-nav abusing lorry drivers ending up at Beachy Head, or grannies driving the wrong way up the motorway, eh?

Anyway, the main point is that a reliable mapping application needs a great deal of information to be fed back to the author; as with Apple’s voice recognition software, Siri—which also operates better the more data is fed back to it—the general consensus seems to be that these apps will get better, more quickly if they are released into the wild.

Once this has happened, then the wisdom of the crowds enables feeds information back far more quickly and cheaply than would otherwise happen.

As such, like Siri, I am confident that the Apple Maps App will get better very quickly—as, it appears, do Apple themselves. And, at that point, Apple will have broken a rival’s stranglehold on one of its most vital technologies.

Using Less as a live CSS engine

Following on from my last post on CSS pre-processors, there is an interesting guest post over at CSS Tricks—from Andrew Powers of PageLineson using Less as a live CSS engine.

It seems that PageLines—who craft WordPress Templates—actually use Less as a live CSS engine for enabling customers to change settings in their templates.

How we implemented it

For us the the key to executing a live LESS engine was this port of the LESS processor to PHP (link) which allowed us to parse and cache LESS files based on user action on our server. To get this working the framework just does the following.

  • Grabs all the LESS files throughout the framework and adds them to a PHP variable
  • Uses the above PHP script to parse the LESS into CSS and puts it in a variable
  • Outputs the CSS to a file which is cached both on the server and on visitors browsers
  • The process is run again whenever a user saves their settings or installs a new extension

This is extremely interesting because, ever since I started using Less, I have been contemplating using it for precisely the same thing within our company’s CMS.

Right now, our CMS uses a very advanced Dynamic Templating System (DTS) which reconfigures the page depending on what the user has placed on it, i.e. if you place a widget in the left-hand column, then it will generate a left-hand column; if you don’t, it won’t.

However, currently, all of the aesthetic styling has to be done by our own implementers; however, with the advent of multi-site functionality in our CMS, we are seeing an increased demand for advanced users to be able to make changes themselves.

Although we have implemented a system where aesthetics can be saved as Custom Style Presets—which can then be applied by the user—we have to write those presets first.

Ideally, we would actually allow the user to change certain colours themselves—but that leads to all sorts of complications that, in the end, would constrain our designers and deliver only partial control to the user.

Using Less as a live CSS engine is the way to get around this problem. However, since our system is not written in PHP, we would need to see if Less has been ported to ColdFusion (unlikely) or write the plugin ourselves (not currently a priority).

Whichever way we go with this, it is nevertheless great to see that there is an operating version of this concept being deployed in the wild.

CSS pre-processors

I discovered CSS Less about eighteen months ago (although I forget how) and began using it almost immediately: the power and flexibility of CSS pre-processors over the standard CSS language are immediate winners.

The real problem with CSS is that it is, by its very nature, a static language: it isn’t compiled by the browser—which makes rendering very fast, but limits the possibility for time-saving features such as variables.

And although the CSS Working Group have released a Draft Specification for CSS Variables (and WebKit has implemented it), the syntax is pretty clumsy to say the least.

So, for an increasing number of front-end developers, using a CSS pre-processor is becoming incredibly important. There are two main languages to choose from—the aforementioned Less, and Sass—but both share some common traits.

Both were written as Ruby Gems, both introduce time-saving concepts—such as variables and mixins—in syntactical extensions of CSS, and both feature compiling engine that “watch” your files, compiling them to CSS on save.

The mighty Chris Coyier wrote an article comparing both engines in which he came down firmly on the side of Sass: looking at his arguments, and code that I have seen in the wild (on CodePen, for instance) I accept that, logically, Chris is probably right.

However, for me, Less is the better language, and there are a few reasons for this:

  • although it originally started as a Ruby Gem, it wasn’t long before it had been ported to Javascript. Whilst JS is not my forte, it does mean that you can deploy Less on a live site (or, rather, during development): my colleagues and I deployed this method when lots of us were simultaneously implementing a site during 2011’s GiveCamp;
  • when I started investigating pre-processors, the talented Brian Jones had written a free Less compiler app for Mac OS X which meant that I didn’t have to muck about with the Terminal to get things set up. I now use his invaluable CodeKit application for all my compiling needs (although it does much more than just compile, e.g. image compression);
  • the Less syntax feels more CSS-like to me. As someone who is both very busy and entirely self-taught—as well as not being a natural “process” coder, this is an important point. It makes Less very quick for me to write, and to take advantage of the power of it very easily. (And I am only just tentatively scratching the surface of Less’s more powerful—and more code-like—features, such as Guard Expressions.)

Ultimately, it is entirely up to you which pre-processor you feel most comfortable with: but if you do any CSS work, you should definitely be using one of them. Here are just a few examples of the power that CSS Less gives you:

Variables (with colour operations)


Variables are worth the price of admission on their own, especially when combined with colour functions such as lighten, darken and fadeout.

We have saved substantial amount of time in implementing sites on our CMS simply by looking at all of the colours that are used in the front-end templates, and driving them off a few basic colour variables (which are dictated by the customer’s brand guidelines).


Mixins allow you to group together lots of properties for re-use. The single most useful deployment of mixins is for taking the tedium out of vendor prefixes—rounded corners, for instance:

As you can see, the above mixin will output all of the various vendor-prefixed variables: all I have to write is:

As you can imagine, just those two abilities have saved me huge amounts of time in building websites—and in maintaining them.

Many articles have been written about the power of pre-processors, so I am not going to recreate the user guide here: however, I shall be posting novel or useful Less snippets from time to time.

Scroll into View

This might be useful: the scrollIntoView() method scrolls the element into view.

iTunes-style coverflow

… at least, that is what I have attempted (it’s notoriously difficult). It’s not perfect but the cards do move in 3D space (although the active one is not centred), and they’re controlled by using the check-box hack.

You can navigate through the cards either using the numbers or incredibly—and in a massive affront to all Accessibility practices—by clicking on each card (as usual, there’s no Javascript here at all).

You can view it in fullscreen, or view the code.

Emulating a multi-line ellipsis in CSS

There are various methods for clamping the number of characters, words or lines that can be fitted into a particular space on a website. However, most of them involve limiting the characters either through Javascript or server-side language (and most involve unpleasant Regex expressions).

And while there are a few options for text-overflow , there is currently no elegant cross-browser solution for clamping the number of lines then ending with an ellipsis in CSS.

My personal favourite—because it focuses on the number of lines (which is more important for pernickety designs) rather than words or characters and ends the text excerpt with said ellipsis—is WebKit’s line-clamp property.

Which renders as:

On Webkit browsers, this should be limited to two lines and end in an ellipsis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam non auctor nunc. Aenean porttitor eros quis tellus dapibus vel scelerisque quam laoreet. Fusce vel nulla vitae erat adipiscing feugiat. Nam vitae mauris orci, et congue dolor. Aenean et leo eu dui ullamcorper pretium id at mauris. Donec dolor mauris, dignissim dapibus commodo eget, pretium id lorem. Nullam pharetra mollis imperdiet.

However, this method far from ideal for generating a multi-line ellipsis: it requires all of the attributes above, and is Webkit only—and, even then, it’s a non-standard property. (My theory is that it was created to clamp the information on TV show episodes in the iTunes Store.)

So, Mobify has created an excellent simulation of the line-clamp which will work in most browsers—yes, even in IE (with some tweaking). So, now you can deploy a multi-line ellipsis in CSS…

Welcome to The Devil’s Repose

For nearly seven years, I wrote a political blog from a libertarian stand point. However, in early 2008, I was hired by a small software company based in Surrey, in England. Since this time, I have become more and more interested in the web, and its development—as such, I have laid down the stale and futile political mantle, in favour of writing about technology.

And so here we are…

A bit about me

I started my career designing posters for the Edinburgh University Theatre Company (traditionally known as Bedlam) and, from the winter of 1996 until the end of 2006, I designed hundreds of posters, flyers, programmes and leaflets. (I also variously lit, directed and produced over forty productions there.)

I had ostensibly been studying Microbiology at the University of Edinburgh but, swiftly realising that this consisted mainly of biochemistry (which I disliked), I dropped out at got a job as a Mac Operator in a small Edinburgh print-shop. Over the next eight years, I moved through a variety of similar jobs—each one having more of an emphasis on design (rather than processing the designs of others)—before moving to London (where, of course, the streets are paved with pure gold) in 2006.

During my last two jobs in Edinburgh, I had learned the art of website building and taught myself HTML and CSS. And so, in London, I set up as a freelancer and worked enough to ensure that I remained comfortable.

But being comfortable is rather dull, and before long I found myself craving company and people from whom to learn. And so, via a variety of coincidences, interviews and impulsive decisions, I ended up working for my current company—which builds and deploys websites and intranets on its own content management system (CMS).

Although hired as a second-string designer, my strong views and inability to keep my mouth shut has resulted in my being deployed through various parts of the business over the last few years: I have been a designer, a project manager, marketing manager, an information architect, product manager, UI/UX designer and creative manager.

About this blog

This blog aims to bring together many of the things that I have learned along the way, and to keep track of trends in current web development; from a coding point of view, I shall be focusing particularly on what is traditionally known as front-end development—and cutting-edge HTML5 and CSS3 techniques.

Many of the posts will simply be links to interesting articles and methods, but I shall also be undertaking longer posts about personal experiments and opinions. At some point, it is likely that others will join me.

I hope that you enjoy this little divertissement, and do feel free to comment and join the discussions…