Homeopathic HTML solutions

Our lives as web developers are amazing. Information flows plentiful and is ever increasing and our quiver of tools to play with ever replenishing. Every week there is some new, groundbreaking thing happening and web technologies are promising amazing access to hardware and making our lives much simpler.

Instead of picking and choosing from these offerings and using the right one for the job, we seem to spend an extraordinary amount of time re-creating the same solutions in several technologies. Not because it is needed, but because we can.

This becomes almost painfully ironic when you see articles that are a massive pat on our own backs for using “plain HTML”, “vanilla JavaScript” or “pure CSS” that utterly and totally miss the mark of using these technologies. Or just omit or misunderstand enough to be broken and a worse performer than a “closed technology” solution.

Examples like these are beautifully styled forms that utterly fail to have labels that do what labels do – connect input elements with descriptive text (both in assistive technology and by making the text clickable in browsers) – as the author failed to understand that you need to nest elements inside labels or connect them with a for/id attribute coupling.

Other examples are creating complex graphical animations and paint with I, B or DIV elements. These are impressive, but no, they are not – at all – semantic HTML. True, SPAN and DIV are defined as elements with no meaning for us to use any which way we want to and I and B are defined as “visual” elements that could display anything. However, nowhere is a definition that adding a lot of nested empty elements is a good idea. That’s like raspberrying, watermelon or capybara your hedgehog in aparagus, right? What? The last sentence didn’t make sense? Don’t worry, there is probably some conversion tool that will make it useful – sadly enough you don’t have access to it right now, though. This is what you do when you use HTML to paint in the browser. You abstract away meaning and make it dependent on other technologies.

Semantic HTML means a few things, none of which are covered by exercises like that:

• You deal in content. Semantic HTML describes content. It is not a tool to paint with. You could easily create an image using a table with a cell with a background colour as each pixel. It wouldn’t make sense though as a table is meant to give tabular data its structure and describe the relationship of the data parts to each other. Images do not have that need, what they need is an alternative text.
• You give content meaning. A P tag around a block of text says that this is a paragraph. It says it to people, browsers and assistive technology. It even means it displays with whitespace around it when there is no CSS and it allows you to collapse it in editors. A DIV with a class of “paragraph” does the same for human readers, but only makes sense visually with CSS and none to assistive technology.
• You increase maintainability. You keep everything that is to be changed when it comes to content in the HTML. You do not have text labels in JavaScript or generate textual information in CSS with pseudo content. That way people don’t have to wonder where a text on the screen came from when they need to change, translate or remove it. CMS have no issue separating content from presentation to make it easy for people to edit pages when you used semantic HTML. When all you use is DIVs with classes, CMS editors will choke.
• Semantic HTML is a sign of quality and future thinking – it is true: browsers do not care a bit if an element is a DIV or a P. Maintainers do though. And browsers and rendering software or marked up content comes and goes. Semantic HTML is there for humans, computers, search engines, conversion tools and many other things. You can create incredibly terse and nonsensical code and browsers will still do something with it. What you sacrifice though is readability. Sometimes in order to make things easier to understand, you need to write more. That is not a waste, it means you care about what you do and don’t leave it to machines to translate for you for other machines to display.

In order to reap the rewards of clean and semantic markup, you need to think about meaning first and then about code or markup. Writing intelligent, beneficial HTML is an exercise in organising and describing; you could say labeling. It is not about using HTML as the tool to create things that look impressive.

So next time you feel like showing off that you can do things “in plain HTML”, consider the consequences. Think if what you did in HTML really gives the content meaning or if you just painted with tags. We won’t succeed in promoting open technologies as the obvious and better alternative if we abuse them to reach a goal they were not meant for. This is especially important in terms of performance. Every DOM access, every reflow is costly. Let’s use them sparingly.

What we need is more rewards for doing the right thing. That’s why articles like Heydon Pickering’s “Semantic CSS With Intelligent Selectors” are so important. They don’t wave a flag for semantic HTML – instead they make it beneficial to do the right thing. We need more of those, giving people rewards for learning and understanding HTML before they apply it. What we don’t need is more experiments proving things can be done in a technology that wasn’t meant for them. These can be inspiring and are fun to do, but they don’t help the cause in the long run.