The history of the web browser is crucial to answering questions about modern web design. In this article, we'll explore the answer to the question: can you design websites as resilient as the world wide web itself? We dive into the history of the world wide web to find out.
From the beginning
On 12 March 1989, a young computer scientist named Tim Berners-Lee published a memo. He was working at CERN, the European Organisation for Nuclear Research. The thousands of scientists working there needed a way of collaborating over the internet. Berners-Lee had a potential solution. He published his idea under the title Information Management: A Proposal.
It wasn't exactly a page-turner and the diagrams were completely incomprehensible. But there was enough there to get the project started. This project became the world wide web. Within a year of publishing his initial proposal, Berners-Lee created the first version of HTML, the first web server and the first web browser. The browser was somewhat confusingly named WorldWideWeb.
Thirty years on from the original proposal for the world wide web, a group of designers and developers gathered together for a week at CERN to recreate the experience of using that first ever web browser. You can see the final result here (opens in new tab).
Extending the web
Scientific collaboration was the first use-case for the world wide web but the project wasn't designed to be limited to that usage. Berners-Lee knew that he couldn't predict how the web would be used in the future. He therefore designed it to be extensible.
The first version of the HyperText Markup Language had just a handful of elements. But the HTML language is open to new elements being added. Over time, we got more form fields, more structural elements like section and article and even more media like audio, video and responsive images. None of these additions introduced breaking changes. That's because of the error-handling model of HTML.
When a web browser encounters an HTML element it doesn't understand, it renders whatever is in between the opening and closing tags. It displays the content while ignoring the tags it doesn't understand. What's interesting here is what the browser doesn't do. The browser doesn't throw an error. The browser doesn't stop parsing the HTML as soon as it encounters an element that it doesn't understand.
This kind of lax error handling is an example of a design principle called The Robustness Principle or Postel's Law: "Be conservative in what you send. Be liberal in what you accept."
Browsers are very liberal in what they accept when it comes to HTML. On the one hand, this can be quite frustrating if you're a developer trying to isolate a mistake in your HTML. On the other hand, this looseness has enabled HTML to grow over time without breaking in older browsers.
In the first decade of the web's life, HTML saw an explosive growth. New elements and attributes were added to the language. Some of those additions were adding new semantic granularity but some had absolutely nothing to do with semantics. Elements and attributes for specifying fonts sizes, colours and borders were introduced. HTML, which was intended for defining document structure, was looking in danger of being swamped with presentational instructions. The solution was to split structure and presentation into two different languages.
01. The presentation layer
Håkon Wium Lie and Bert Bos joined forces to work on Cascading Style Sheets. Using CSS, developers could add presentational information without having it intermingled with HTML.
With the arrival of CSS, HTML could return to doing what it does best: describing the structure of a document's content. The new separation of concerns had other benefits. A single CSS file could be responsible for one HTML document or it could be responsible for multiple HTML documents: 10, 20, 100 HTML pages could all reference the same style sheet. Tweaking the visual style of those 100 different pages no longer involved changing each and every one. Changing the single CSS file was enough.
But CSS still needs some way of understanding which parts of the HTML it should be styling. It has a kind of 'mental model' of how parts of HTML can be targeted for styling. This model is represented in the form of selectors. Using CSS's selector vocabulary, developers can target elements with a particular tag name, class name or ID. You can think of this way of modelling a document as being like a document selector model.
Crucially, CSS adopted the same error-handing model as HTML. If you use a selector that the web browser doesn't understand, it will ignore the enclosed declarations and skip ahead to the next selector. The web browser won't throw an error. It won't stop parsing the CSS file at that point and refuse to go any further.
Likewise, if you use a property or value that the browser doesn't understand, it will skip over it and move on to the next declaration. This has enabled the vocabulary of CSS to grow over time, without waiting for universal browser support. You can use new selectors, properties and values even if they're not available in every browser. The non-supporting browsers ignore what they don't yet understand. They are liberal in what they accept, which hopefully means less reliance on the technical services of your web hosting service.
02. The behaviour layer
Describing the structure and the presentation of a document is empowering but it has its limits. Using HTML and CSS, you can craft beautiful, accessible, semantic web pages but they're static. Interaction is bounded by HTML's vocabulary. Links and form fields are interactive by default but if you want to extend the interactivity of HTML you need a scripting language.
HTML and CSS are declarative languages. Rather than giving step-by-step instructions, you describe the outcome you want using the vocabulary of the language (elements and attributes in HTML, selectors, properties and values in CSS). On the plus side, these declarative languages have the loose error handling that makes them relatively easy to get started with. But, on the downside, you're always going to be limited by the language's vocabulary.
The document object model
JQuery, AJAX and more
Most DOM scripting patterns – like image rollovers and form validation – involve finding a particular part of a document and then executing code when a particular event is fired. You could summarise these patterns as: 'Find stuff and do stuff to it'.
The principle of least power
When Tim Berners-Lee was working on his world wide web project, he applied a number of design principles: simplicity, tolerance (in the form of Postel's Law), modular design and the principle of least power: "Choose the least powerful language suitable for a given purpose". See it here (opens in new tab).
On the face of it this seems like unusual advice but remember that powerful languages come with a price: fragility. Less powerful languages are more forgiving and more widespread.
We can apply the principle of least power when we are creating products