Written by Lincoln Anderson on 04 September 2012
Semantic markup rocks. The mass adoption of a semantic approach to content presentation has allowed our community of designers to thrive on the web. Common sense methodologies have led us to more scalable, reusable, maintainable assets. In broad terms, this wasn’t true ten years ago. But now, our code is cleaner, and everyone is happier.
The basic principle of semantic markup is that HTML itself should describe the content, or “what it is”, while CSS declarations should describe the presentation, or “how it looks”. This is easy to understand and implement, allowing designers to separate concerns and group like-assets. It feels great, and it results in code you can be proud of.
But these two layers are not as decoupled or as complete as we might think. HTML is not purely a hierarchical content inventory; it also implies presentational layout though the nesting and ordering of nodes. You can do a ton with pure CSS, but there is always an invisible wall you’ll hit where a design change cannot be accomplished without modifying the markup. You might need to alter the order of two nodes, or wrap a couple nodes in a <div/>. This is true whether your class names are centred on the data models of your specific project (“product-summary”, “shopping-cart”, etc.) or if you’re using a flexible, grid-based system with portable classifications (“span3”, “btn-primary”). So HTML is also — to some extent – layout.
Additionally, HTML contains implied functionality, even in the most basic tags. If you consider HTML to be purely the realm of content, consider a <button/>. What content does it represent? You could point out a button’s label, but even the button label as a communication device tells the user “you can interact with this thing right here.” How about an empty <input/>? Basic HTML; zero content. An anchor tag’s “target” attribute pulls us even deeper down the rabbit hole. Now we are authoring how the user’s web browser behaves. The list goes on; you get the picture.
These interactive elements make HTML more than a document language; it’s an interactive product language. But why is this important?
Speaking strictly in interface design terms, toolkits like Bootstrap and LESS can make going from concept to code faster in your text editor than in Photoshop. I’ve recently shifted more towards designing and developing within the browser, alongside frameworks such as KnockoutJS and ASP.NET MVC. Both of these frameworks support some form of templating or data-binding, and can weave a level of functionality into your markup. What struck me about KnockoutJS was how unobtrusive it is if you structure your viewmodels semantically. You might see something like this in your code:
<button data-bind=”click: login”>Log In</button>
Now, even if you don’t know what data-binding or KnockoutJS are, you can probably understand= what we’re trying to do here. We have a login button, and when the button is clicked, we log in. I call this “semantic binding” because it doesn’t ostensibly contain any script or foreign language; instead it simply describes what the content is, or what the interactive element does from a user’s perspective.
Like semantic HTML, it’s simple, descriptive and human-readable.
I showed a snippet like this to a colleague of mine, and I was sure he was going to love it. He didn’t. He argued that the function of the button should be placed elsewhere, separate from the clean, semantic HTML content. I thought about this for a long time, because this particular guy is brilliant, and HTML is his game. But this time, I didn’t agree with him, and wanted to figure out why. His stance is probably a common one among designers, and was the catalyst for me writing this article.
I’ve made a few observations since that time, and I’d like to share them with you.
1. Any coder can understand clean, semantic bindings — even without an introduction to a framework
Hell, they can even write them, if handed a short list of stuff the interface is capable of. That’s extraordinarily empowering for an interactive designer. Think about it - once the support system is in place, if you can understand the line of code above, you have all the tools to go from concept to functioning product simply by describing what you want the thing to do, as you’re designing it.
2. Organising assets is useful, but separating concerns is better
Have you ever added a jQuery “click” event onto a link or button, and stored that script in an external JS file? There are often good reasons for doing so, but what happens when you want to repurpose that button? You have to hunt down the script associated with it in a completely separate file from the markup. Did you remember what CSS selector you used 2 months ago? Since a button only exists to perform a command, why not describe -- semantically -- what the command is on the button itself? In my experience, this brings the pain of context-switching way down as you build.
3. Great tools and frameworks reduce the latency between inspiration and result
This is one of the reasons the Flash animation tool evolved into a powerful RIA platform over the years. Designers played with the tools and found they could draw something and see it come to life rather painlessly. Flash transformed web designers from artists into developers, simply because it was easy.
In the distant science-fiction future, we might simply have an idea for a product or design and it appears in front of us instantly. So today, as our tools and practices evolve we should seek to not only write better code, but to reduce the code we have to write. When it comes to technology, abstractions and automations make us happier and more productive.
4. The semantic markup movement has led some web designers to forget they are crafting interactive experiences
If you are placing a button on a web page, are you thinking about what happens when that button is clicked, or only about how it looks? When pressed, will it immediately disable itself? Will it send the user to another page, or pop a modal? Maybe it will do nothing; it will just sit there like a dead fish until someone else on your team wires it up.
Designing for the web is more than creating great looking content templates. We want to craft great experiences for the user. That means being just as detail-oriented with interaction behaviour as we are with aesthetics.
That last point is the real essence. This isn’t a promotional piece for data-binding frameworks or an attack on semantic markup. My hope is to point out the opportunity for linkage between semantics and interaction design, and how making that connection a priority can lead to better practices and better results for every designer.
About the Author: Lincoln Anderson is a Senior Interactive Designer with 352 Media Group specialising in experimental projects and web-game development. He’s been with the web design company for more than 10 years and works with the agency’s biggest clients, including Microsoft.
Got a talent for writing? Interested in Guest Blogging for the UKWDA? Contact Us.