Web design? Resilient?

In the early days of the world wide web, determining the layout and function of a web page on a screen was approached pretty much the same as in the case of  a page in “print”. Which is actually quite understandable, since designers tend to design with designers’ minds, using designers’ tools. Try Photoshop: when starting a new document, the first thing to do is to set its width and height. The fixed-width approach to web page design, though crippled form the start, only started to grow really problematic since the appearance of the iPhone, and later the iPad, and the myriad of alternatives – all similar, but all with very distinctive screen widths. The problem was, as Jeremy Keith very eloquently points out in his amiable (and free!) book Resilient web design, that using fixed-width elements to design a web page rendered on variable-width screens, is materially dishonest.

But now we know better. Right? Now we use HTML strictly for marking up the meaning of content, and CSS strictly for presentation. That’s materially honest. And it’s a nice separation of concernsSo we use a table element to mark up the structure of tabular data, and never for layout purposes. Right? In HTML5, we even explicitly obsoleted the align and width attributes on table elements. Good for us!

The pair of HTML + CSS are very pleasantly loosely coupled: while the HTML would contain some hooks for the CSS to cling to, exactly the same HTML content can be presented in any imaginable way by applying changes to just the CSS, while on the other hand one single CSS file can serve to style any thinkable content in HTML. Another remarkable property is that the same HTML, when for whatever reason the accompanying CSS  is crippled or lost, will still get presented in a perfectly readable way. In a not so beautiful, default way, but still entirely useful for a clear interpretation of the content at hand.

But there’s more.

Both HTML and CSS share the property of being a declarative languagemeaning they don’t instruct a computer to follow a step-by-step recipe, but just define some information (HTML: meaning, CSS: presentation) about some content. This renders them a very forgiving attitude to errors: when a browser is rendering a page, and encounters an HTML tag it doesn’t recognise, it ignores the markup, and displays the tag’s content. It doesn’t report an error, it doesn’t stop processing, it just does the default thing, keeps calm, and carries on. Same thing in CSS: unknown selectors, properties, and values are just ignored, a default style is applied, and processing continues. That behaviour is by design, and it’s tremendously powerful! It’s a huge advantage. It really is. It’s true.

Thing is, the liberal way in which HTML & CSS are parsed, enables a profoundly robust route for innovation by leveraging the ever-extending feature sets of modern web browsers. Not every user on the web has the latest and greatest browser version installed, and not every device has the topmost capabilities. Still, it’s perfectly safe to use the hottest of the new stuff in your HTML and CSS, since you can rely on any non-supporting browser to just keep calm, and carry on. Nothing will break; some get to see the full glory of your endless creativity, everyone will get the same content in one perfectly usable presentation or another. Websites don’t need to look exactly the same in every browser.

Of course we have to consider that other language of the web as well: JavaScript. It’s quite popular. JavaScript is used in many ways, but its main concern is enabling advanced interactions between the content and the user, and between different elements within the content. A major difference with HTML & CSS is that JavaScript is an imperative language, instead of a declarative one. It defines a step-by-step program that the browser should execute. If something fails, an error is thrown, and execution stops. Compared to HTML & CSS, JavaScript is very, very breakable. It enables many nice ways of interaction, but it’s safest to look at those more as enhancements, than as core functionality. There’s a lot of things that can go wrong – it’s safe and wise to use it, but you’d better not rely on it for any core functionality.

Then what is a sound approach? Three steps:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

That’s the strategy for what’s known as progressive enhancementIt enables you to go as wild as you want on the latest and greatest hot new stuff, because you can always rely on the safety net of your basic resilient HTML+CSS design. Thoughtfully starting off with full focus on the basics, using the plain old bare open standards of the web isn’t actually setting you back to what we regarded normal in the days of Geocities – quite the contrary: it’s a great enabler of experiment and innovation. All by design. Enhancing progressively is an act of future friendliness.

If you follow the buzz, it very much seems that web development is just another word for choosing one of the popular JavaScript frameworks. The case for progressive enhancement in Resilient web design quite firmly augments to the reasons why e.g. React is a terrible idea (it’s sad!) It also adds to a solid foundation for the powerful recommendations of ROCA – resource oriented client architecture.

Enfin, you might want the book as well. It’s a good read.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s