On Semantics In HTML And CSS

Written by |

The semantics arguments are old, boring, and often misguided.

Semantics in HTML and CSS is a contentious topic. The problem is, when most people argue for writing semantic markup, the crux of what they’re speaking in favour of is mostly meaningless, confuses others, and gets in the way of getting things done.

People get tripped up on notions that they ‘have to‘ use a particular tag in one situation over another, in fear of violating the semantics of a document.

Other people will wail and gnash teeth over the use of CSS classes when a ‘more semantic’ element can be favoured without ‘littering’ your HTML with classes.

This is nonsense.

Stop it. Stop it. Stop it.

 

How To Think About Markup

So where does this all the discussion about semantics come from?

The HTML spec makes different tags available to us so that we can solve different problems.

HTML imposes few restrictions on our choices. Nothing is stopping us from using a span in place of a div, given a little CSS to address differences in layout. An anchor can do the same job as a button, with some Javascript to remedy differences in behaviour.

In both of these situations, however, experience tells us that we’re doing something wrong. This is because the tags defined by the HTML spec are there to guide us on how we should structure our documents.

Here’s the big semantics secret that HTML holds for everyone:

Use elements that support their context and intent

 

eric-wareheim-mind-blown

 

 

What Semantic Markup Looks Like

Do you need a heading on your page? Use one of the following:
<h1>, <h2>, <h3>, <h4>, <h5>, <h6>

Do you need a button to change state on your page? Use this:
<button>

Do you need a menu or navigation? Choose a combination of these tags:
<nav>, <ul>, <ol>, <li>

This is as far as the semantics argument ever needs to go. Ask yourself, ‘What am I doing, and what do I use to best describe those intentions with HTML?’

 

Do you have to use any specific element at any point in time? No. You can use almost any element you want, wherever you want. What is important is if the element you choose makes sense in the context in which you use it. Your elements should bolster the meaning of your document.

Nothing stops you from using a div instead of an hN tag, or an anchor when a button will do – but does it make sense for you to do so? Does using a specific element affect how your site is interpreted by crawlers? Do you have to do additional work to get one element to behave as another does by default? Is the intended use of an element meaningful for how you’re actually using it? These questions guide you in choosing which elements you should use in different contexts.

If you choose an element that doesn’t make you feel uneasy, then it’s probably fine, or you’re still figuring things out, and that’s also fine.

 

HTML Semantics And CSS

It’s not difficult to find arguments against adding classes to tags, or even that markup may be suffering from ‘classitis’. This is often accompanied with references to the poor ‘semanticness’ of classed markup.

Whether a class attribute is present on an HTML tag or not does not affect the semantics of that element. I’ll repeat that.

The presence of the class attribute does not affect the semantics of an HTML tag

As an example, Bootstrap 3 conflates eliminating classes from grid columns with making markup ‘more’ semantic:

… includes predefined classes for easy layout options, as well as powerful mixins for generating more semantic layouts. [emphasis mine]

More semantic layouts?! Because fewer / no classes better support the intent of a grid?! How is that so? A semantically questionable grid could be built out of <button> tags, surely not <div>s with classes.

What does affect the semantics is what a class conveys through its name. A class of .button on a <ul> contradicts the role that a <ul> plays. But if that list represents a menu, and the class is changed to .menu, we are supporting the intent of that element.

This is congruent with writing meaningful HTML. Classes may support the intent of a tag, but they shouldn’t contradict the tag’s role. Markup should make sense when it is read, and that goes for both your choice of tags, and choice of class names.

 

Conclusion

I hope this article has been enlightening. For the most part, whenever I see someone comment on semantics, their input is often not helpful in progressing thought, is based on wishy-washy ideas of what semantics are, or speaks volumes for impractical and dogmatic approaches to structuring CSS and web pages.

Additionally, you can ignore the nonsense-words ‘insemantic’ / ‘unsemantic’. Your markup choices may be semantically sound, in a grey area, or plain incorrect. We don’t need to invent words to confuse the matter further.

The bottom line is this:

Choose markup that supports the intent of your page.
Avoid class names that contradict that intent.

You’ll be happier with your output, your web pages will make sense to you and anyone using them, and that’s what’s important.

Share this article on twitter, facebook, or google+