Semantic web design #SWD

Waiting in the wings since the dawn of the web, semantics in code will be our saving grace when the concept of the ‘screen’ becomes stretched (or compressed) further still and the next wave of web enabled devices hit…

Any web worker worth their salt, be it designer, content editor or project manager, should now have a good grasp of responsive web design; how we do it, what it looks like, and most importantly why we do it. So much so that it has become a bit of a buzzword/hashtag/go-to.

This obviously wasn’t always the case. The pioneers and early adopters had to discuss and explain this methodology to stakeholders and others. Cases like ‘responsiveness isn’t a bolt on’, why time investment was needed and how it was best to build from the ground up were born.

Next on the agenda for 2014 is Semantic Web Design. SWD (like RWD) has been floating around floating as a potential for years and years, but it’s only now we’re really grasping its full power, and more importantly, its need.

In the early days of the web, people built with fluidity in mind but as the discipline evolved, and designers and developers realised that the screen was a fixed canvas, fixed widths were given life, maintaining grids and giving structure. Many years later, when devices and viewports took centre stage, the fluidity once cast aside was re-employed to cater for this new challenge.

SWD comes from much the same stock, albeit has been kept in use throughout, but it’s only now, with the advent of our next web environments that we’re shining the spotlight into the sky, and calling the old friend for help.

So, what is it

The word semantic means ‘meaning’, so therefore semantic web design is literally designing and rebuilding our sites so they have meaning. Not ‘meaning’ in the conventional sense, as in “we want to make sure we serve everyone with top tasks”, but more nitty gritty; at the code level, down in the boiler room where the leg work is happening.

Just as adding a ‘?’ to the end of a sentence can change it from a statement to a sentence, adding intonation to how our voice goes up at the end, we want to ensure the majority of our code has a meaning attributed to it. By doing this, future technologies, screen readers and anything that will parse the code understands a bit more about it.


In the days of building for just desktop, we needed a solution for devices and the answer came with fluidity. Now, teetering on the horizon, is the next wave of tools and portals to the web, designed to make the average Joe’s life easier and the lives of web designers harder.

These new devices are a different breed. Although they will have a ‘screen’, or at least some semblance of that for our eyes to view the site, we can’t now think just in terms of viewport width and standard RWD. The showcasing of Google Glass enlightened us to the next world, where we can view the virtual world and the real world at the same time, and web designers world wide unanimously bellowed “How on earth do we design a site for that?!”

Ok, so how do we do it?

The answer comes, at the very least partially, with SWD. While we can’t predict exactly what devices will do, we can predict with some certainty that they will use the web technologies there. After all, they will need to work to some extent right from the get go, otherwise adoption will be poor.

This means they will of course use HTML, and read through that code and interpret it in some way. Without semantics, they could at the very least show the site how an RSS reader interprets it. Showing a title, looking for images and showing or reading paragraphs in the best format for the device. Yes, sadly, our lovely styling, gradients, and lovingly kerned typography might be gone, but we don’t need it, not really.

The introduction of HTML5, and other new aspects of writing for the web opens the gateway to how we make our websites more than just an RSS feed. How we design them without the visual but more the meaning.

Traditionally, our simple page might look like this…

<div class="main"> 
    <div class="article"> 
        <h1>This is the titleh1> 
        <img src="images/photo.jpg" alt="Photo of page"> 
        <p>This is the text of the article, it's really interesting and I could go on, but I think you <em>get the point.em>p> 
    <div class="sidebar"> 
        <h2>Some other cool thingsh2> 
        <div class="links"> 
                <li><a href="/">Poniesa>li> 
                <li><a href="/">Rainbowsa>li> 
                <li><a href="/">Semanticsa>li> 

This is a well marked up page, and by the old measurements, nothing is wrong with it; it validates, divs are used instead of tables, classes instead of IDs, h1s and h2s used, an emphasis tag, but it’s all a bit flat.

What we want to do is give this a semantic meaning, so things that aren’t human know what’s what. Giving the bot the ‘?’, essentially.

<section role="main"> 
    <article class="article"> 
        <h1>This is the titleh1> 
        <img src="images/photo.jpg" alt="Photo of page"> 
        <p>This is the text of the article, it's really interesting and I could go on, but I think you <em>get the point.em>p> 
        <h2>Some other cool thingsh2> 
                <li><a href="#">Poniesa>li> 
                <li><a href="#">Rainbowsa>li> 
                <li><a href="#">Semanticsa>li> 

So we can just change our code a bit?

Yes and no, well without the yes, so no. In theory, the exercise above works and, if we keep our classes in (and of course we’ve written our CSS correctly), we can change the markup and give some more semantic meaning. However, just like RWD not being a bolt on, SWD is also best served ground up.

Semantics work as a base but they also need to be relative to each other. We can have more than one section, with multiple articles, navs and asides within. We can have different header structures for each section, if we want, and different roles for each element. With this many options and possible structures, we can be pretty sure that our desired structure isn’t the one we have now. Again, harking back to RWD, where we might need to move left sidebars down to near the footer in terms of the markup (so they don’t stack and appear as a long list before the actual content of the page), we really want to consider this approach from the start.

Final thought – action rather than reaction…

While this new tech is still in the future and we can’t fully design for something that doesn’t exist yet, we can start to embrace semantic web design right now, ensuring our sites are future-friendly and fully considered, so that when the wave hits, the surf is up!

Originally published on the Jadu blog:

Posted on 27th Jan, 2015