A short and personal history of building web pages.

View the Slides or read the transcript :

This is my journey, shared so you can learn from the mistakes I’ve made.

Done in the hope that you aren’t making then same mistakes.

<p >Good judgement is the result of experience …

Experience is the result of bad judgement.

Fred Brooks,
The Mythical Man-Month: Essays on Software Engineering

In the beginning we had HTML Vomit.

The problem with all this inline style, of course came when we needed to change font size or type or colors it meant some very ugly and time-consuming find and replace.

Using CSS2 we moved our colors, and fonts into a separate CSS file. It allowed for the easy reuse of that color and font style across web site. Less repetition (DRY : don’t Repeat Yourself), easier to modify.

All good things!

But we were using tables not for tabulate data but for layout, so our html looked like this.

(I felt dirty writing that)

Actually it looked more like this :

  • Tables for Header
  • Tables for Navigation,
  • Tables for Secondary Navigation,
  • Tables for Footer,
  • Tables for alignment on our Fields.
  • And probably Tables within some of those Tables.

can you say “Table Vomit”?

(this may or may not be a template from 2001)


Problems included :

  • long rendering times;
  • understanding the rat’s nest of nested tables;
  • inflexible layouts.
  • And Just too many TABLES!!

Now some people didn’t think this was a problem,
but layouts change a lot in development and in maintenance (years after),
… and when they do then disaster often strikes.

but their was a solution for this : Grids:

So we moved to grids for layout and alignment, that also allowed for tricks like the CSS Zen Garden of swapping in a new style sheet and getting a completely new look for the same content.

and a Cambrian explosion of CSS frameworks (and framework generators) made it easier to move to grid layouts with the added benefit of best practices like :

  • Easy to understand Grids
  • CSS resets;
  • Print style sheets using media quires ;
  • Sensible default typography and styling baseline
  • some basic class for common needs;

Now we had much cleaner HTML markup and all our Layout in the CSS.

Also, around this time JavaScript Frameworks came on stream, first Prototype JS and then jQuery (plus others), which made DOM manipulation and AJAX even more practical (even fun!),

plus introducing unobtrusive JavaScript techniques, which allowed us to remove all our inline JavaScript (No more “onClick” javascript!) from the HTML.

So, much cleaner HTML markup (less JavaScript in our markup), all our behavior in separate files, and much more powerful behaviors.

But our layouts where still static, for fixed screens like 906 or 1240 pixels wide.


now some clever folk way back in 2001 where talking about flexible grids or elastic design,

but we ignored them because everyone was happy to support either 17″ laptops or 22″ desktop monitors.

Until 2007, January 9, Steve Jobs introduced the iPhone and everything changed

.. and it hasn’t stopped changing since then

with iPads, Android phones, Tablets; Windows Metro; and the Playbooks galore!

And suddenly those layouts that worked on a 17″ laptop didn’t look so hot. 🙁

Now there was a reason to get or web pages working on 320 px as well as 1240 pixels.

And CSS3 media queries (supported in the newest browsers) let us do CSS Zen Garden like tricks of swapping in a new style sheet at on a new screen size or orientation.

and within any given media screen, our layouts moved from static

to fluid to support the many (many) device sizes.

So now our designs could Respond to the different layouts on different deceives with out rebuilding the content, hence Responsive Web Design.

And our CSS framework became Responsive Design frameworks.

Now there was a problem that different browse has different experimental support for various CSS3 features, but

But different browsers sometime had only experimental support for various CSS3 features,

But, CSS preprocessors (like SASS) came to the rescue with the functions for CSS so this :

.simple { @include border-radius(4px, 4px); }

could become :

 .simple { -webkit-border-radius: 4px 4px; -moz-border-radius: 4px / 4px; -khtml-border-radius: 4px / 4px; border-radius: 4px / 4px; }

and we also got variables, math and other goodies. And now we have unobtrusive CSS frameworks to boot as well, thanks to CSS preprocessors mixin functions.

HTML5 allowed using to common CSS classes with clearer and meaningful (Semantic) markup for improvements in accessibility, searchability, interactivity, internationalization and interoperability.


But not all MODERN browsers supported all CSS3 or HTML5 features.

and of course there are dinosaur browsers out there that kill kittens.

Some people try to use User Agents to detect browsers and devices (sometimes called user agent sniffing).

But there are too many Agents


and some of them lie. (see Agent Spoofing)

Feature Detection to the rescue!  (Thank you Modernizer!)


So now we do test for features

and use additional CSS and/or JavaScript Pollyfills to implement non native features.

This we call Progressive Enhancement.

so we don’t have to code to the lowest common denominator, but enhance to support features missing in the device.

So, as of 2012, we have :


  • progressively enhanced,
  • responsive web sites,
  • built on frameworks of HTML 5, CSS 3, and JavaScript 5.

and No More Problems! 🙂

Leave a Reply