As a young web developer back in the mid-90’s, we didn’t worry about stuff like separating content from appearance. We just built our frame sets and table-based layouts, added all the fonts and styling inline, and just let everyone gaze in awe at the mere fact we could make one of those magical “web thingamajigs.” Plus we walked up-hill both ways to school, in the snow, and with no shoes. GET OFF MY LAWN!!
Where was I? Oh, yes, separating content from appearance. These days, things are very different, and with the advent of content management systems, it’s become increasingly important to truly separate your content from the appearance. This is the first in a series of articles that will explore some best practices for making your content portable.
Semantic Markup
Whenever I teach a basic web development class, I try to split a web page up like so:
- Content is handled by HTML
- Appearance is handled by CSS (and images)
- Interactivity is handled by a client-side languages such as JavaScript and server-side languages such as PHP
For now let’s focus on the Content in HTML part of that list, which has a fancy name for it: semantic markup.
When you use semantic markup, all of your HTML will define the meaning of the content, and not its appearance. Sounds simple, right?
Read through your markup. Do any of the terms you used impart visual information? For example:
<i>Look at me!</i> <div id="left-col">...</div> <span class="red-highlight">Some important info to highlight</span>
Think about how you could adjust those lines of code without using any visual terms.
Let’s say, for example, you used the “red-highlight” class from the example above in a client’s site, because it went well with the logo, and it was defined like this:
.red-highlight {
background: #ff0000;
}
Then imagine, a few months later, the client comes to you and says, “We’ve updated our logo, and it’s now blue and green. That red-highlighted text looks horrible with it. Make it green instead!” Would you do this?
.red-highlight {
background: #ffff00
}
Really? You would have a “red highlight” that is actually green? I hope not. Maybe it would have been better to think about why the content is getting highlighted in the first place. Maybe it’s urgent information for visitors, so let’s use a word that correlates with the meaning behind the content, and not its appearance, to define the class:
.urgent {
background: #ffff00
}
You might be wondering why this is so important. It’s all about portability! Web sites get redesigned all the time, and if you use visual terms to identify your content, then you’ll either have to change the terms, or updating the styling so it no longer reflects the meaning behind the identifier.
Grids and Frameworks
There are some great, widely-used, responsive frameworks out there, such as Foundation and Bootstrap, that might just be undermining the whole semantic markup crusade. While it’s not very obvious at first, this markup is not semantic:
<div class="rows"> <div class="columns large-8 small-6">...</div> <div class="columns large-4 small-6">...</div> </div>
The classes are dividing the content of the page up visually, and the terms “rows”, “columns”, “large-8,” “large-4,” and “small-6” specify appearance. In general, if a grid or framework uses terms such as rows, columns, large, medium, small, center, tiny, any other word that specifies appearance, or abbreviations of those words, that grid or framework is not totally semantic.
Don’t get me wrong. I’m not telling you not to use these frameworks, especially since we use them here at Pongos to help speed development, but you do need to be aware that when you use them your markup won’t be totally semantic. I find these to be less offensive to my semantic super senses than the “red-highlight” example I used earlier.
If you want to stay totally semantic, there is a Semantic Grid system that’s worth a look.