🎉 Looking to get started with Grid? Download my free ebook! Get into Grid Now »

What Can We Learn from CERN's WorldWideWeb rebuild?

WorldWideWeb browser with a few different sites

Have you ever wanted to go back in time and see what it was like to browse the web using Sir Tim Berners-Lee’s first web browser? I have. Apparently so did the team at CERN.

For the 30th anniversary of the world’s first web browser, The European Organization for Nuclear Research (CERN) brought togoether a team to recreate WorldWideWeb in a modern browser.

You can read a decent bit about the project over at its site worldwideweb.cern.ch.

Check your sites in a purely text-based browser

I’m a fan of semantic, server-rendered HTML, so I had to see how my site would perform. I crossed my fingers, launched the browser and pulled up my site. I’m proud to say that this site and my company site (codecontemporary.com) perform admirably. Both seem to be well structured and surface content in a way that makes sense.

Image: the code blocks on this site don't show well-formatted code

There are a few exceptions. My code blocks handle formatting with JavaScript – which wasn’t invented yet. All the code examples are gibberish. My “Side Projects” in the footer are just links with images inside. The <IMG> tag (caps intended) wasn’t proposed until 1993 (3 years later). Check this site in the browser to see for yourself.

If you want to know how well you’re writing semantic HTML, see what it looks like in a web browser that understands almost no modern code.

Image: Amazon homepage

On a lark, I pulled up Amazon. Why yes, Amazon, I’d love to buy a Top Deal for $29.99 instead of $37.99… whatever it is, that’s a deal!

It’s not too surprising that a company the size of Amazon uses a lot of JavaScript, but I didn’t expect some content to appear and other pieces not appear.

Image: NYtimes homepage

A news site like The New York Times fares a bit better. If you can get passed the absolute glut of navigation, you’re presented with the news of the day. From a hierarchy perspective, all content is smashed together, but that’s not any different when you give them CSS and JS. You can’t blame an old browser for that! Oooh sick Journalism UX burn!

At a glance, a “topic of the day” looks like a random floating name. Their use of related stories also makes it really hard to tell to which stories the comment counts are attached.

The real site suffers from hierarchy issues, but it’s also interesting to see how design issues easily bleed over to HTML. In fairness, most of their content shows up, unlike Amazon.

What’s the point? Why should we look at our sites in WorldWideWeb and feel shame or pride?

If your site’s content flows properly in a browser as old as this, you can feel some sense of security that maybe screen readers and web crawlers can understand your markup.

This is no replacement for proper accessibility testing, but it’s an interesting side effect of a “Digital Archeologists.”

So what can we learn from this? If you write the basics properly, your content can stand the test of time. Don’t forget to at least think markup first.

If your markup is clean, semantic, and actually there then your content has staying power and reusability in any browser.

What are your thoughts? Should we care about how our markup is served?

You May Also Enjoy

Client work and the JAMstack

I worked at an agency for almost six years. In that time, I created only a handful of static sites. Part of this was because the agency had a custom content management system. The other part was an unwillingness to give up "dynamic" websites. I've created a website to aggregate resources for agencies and freelancers looking to branch out into the JAMstack.

Grid vs. Flex: A Tale of a "Simple" Promo Space

I love the new layout modes in CSS. Grid and Flexbox are both amazing features. They each have their place. What if I told you that if you used the "wrong" one, you could double your CSS and HTML? Let's take a look at what appears to be a simple promo grid.

Using Eleventy's (11ty) JavaScript Data Files

I enjoy building workflows for pure static sites. I enjoy ingesting data into my build process instead of loading my client-side with fetches. In this example, we'll use Eleventy's ability to use a JavaScript file, to execute code to fetch data on site build, negating the need for task runners like Gulp.

My Side Projects

Web Workers Logo Web Workers Logo Web Workers Logo Web Workers Logo