Semantic CSS

Another day, another attempt on my part to make a point, and another derailment and ignoring of my point because people want to argue over definitions. It’s particularly ironic (and meta!) this time because the disagreement seems to be over my use of the word “semantic”.

Define: semantic

The dictionary says that “semantic” has to do with the definition or meaning of words. Sure, that’s true.

But is that really what we as developers are talking about when we use the word “semantic” in relation to elements in our web pages? I don’t think that the dictionary definition quite encompasses what we mean.

So, what do we developers mean by “semantic”? I think we mean the intent. I think if we use an

element in our markup, if we’re doing this correctly, the more important part is what we mean with that element, and not so much what that element will end up looking like. Keep that distinction in mind — I’ll come back to it in a moment.

HTML

So, let’s talk first about the stuff most people can agree on: the semantics of some HTML element in the markup.

The

element has a pretty clear intent when used, and that is that it be treated as a main-level heading. But, treated by who? Ah, that’s the question!

Most developers seem to stop at defining “semantic” markup to be the meanings that an accessibility tool or search engine crawler will pull out of the markup.

Example? I worked at a company where we had an entire SEO team, and any time we went to put out a new HTML page, we had to send our markup to the SEO team for “review”. They would often come back and tell us to insert

or

elements in seemingly random places in our markup, and then we’d have to go back in and “un-style” the default stylings of those elements so they didn’t look different to real users, only different to search engines.

It’s probably no surprise that I think this sort of thing is stupid. I don’t care if it’s “proven” to work in SEO. I don’t even want to debate the value of it, so please save your typing. I just think it’s dumb. Or, to put it another way, I would call it a hack.

meaning = intent

I want for the markup I use to convey a bigger meaning that to just the accessibility or search engine crawler tools. I want the choices I make in markup to mean something to my future self and to other developers, those on my team or those who may look at my “code” later. As a writer/developer, I want to use a header to convey my intent with organizing my content into sections and groups and a hierarchy.

I don’t want to overload or conflate what I mean/intend by the use of an element with some “proven” set of conventions about how to trick other tools into presenting or interpreting things in some alternate way to get some other side-effect.

Don’t get me wrong. Accessibility assistance is not bad. Search engine indexability is not bad. But those tasks shouldn’t be overloaded onto me as a developer expressing my intent by the choices I make in my markup.

CSS

Now, enter CSS. CSS is supposed to take all the presentation questions out of our markup and hide them away in our stylesheets, which on the surface should separate our semantics from our presentation.

In many cases, I agree this is true, but it’s not as perfect as it sounds.

Let’s imagine that CSS added a feature called display:header (or even worse, display:h1 or display:header-level-1). The styling behavior of this rule would be to give it the same default stylings as if you’d used the corresponding