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 <h1> 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 <h1> 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 <h1> or <h2> 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 <h1> element. You may think that’s a crazy notion, and that they’d never do that. Put a mental bookmark here — more on that “craziness” in a second.
Now, I want to ask you to compare these two snippets based on my definition of semantics:
<h1>Very Cool Header</h1>
vs.
<div style="display:header-level-1">Very Cool Header</div>
Will these two snippets be treated differently by search engines and screen readers? Yes, no question.
But… did the developer really express a different intent (aside from search-engine and screen-reader interpretation) between the two? I would argue: No. In both cases, it’s very clear that the developer intends for this element to be treated as a main level-1 header. Both of them are examples of the developer giving a pretty strong hint as to the intended structure.
Moreover, the display of each can be independently controlled, and even be swapped completely, so the question of intent is orthagonal from the question of presentation, EVEN THOUGH CSS WAS USED IN ONE OF THEM.
Let’s look at it another way. Let’s assume instead that there’s no display:header-level-1 (crazy idea, right!?), but instead let’s assume the developer creates this in their stylesheet:
.h1 { ... make it look like the default h1 ... }
And then they do:
<div class="h1">Very Cool Header</div>
Does that change your mind much about what the intent of the developer is (again, setting aside SEO and A11Y)? For some, I’m sure it does.
For me, it’s tomato, tomato. I don’t assume, nor do I see plainly, a substantial difference in intent between those two, in terms of what the developer was trying to convey. My opinion stands independent and orthagonal to the fact that I know some tools will in fact distinguish them.
Here’s my point: if you take a word like “h1″ and move it from your HTML to your CSS, you haven’t actually changed your developer-intent (your “semantics”), but just your code’s maintainability.
By contrast, if instead of using something like class="h1", you chose to say class="important", what you’ve done there is make a clean break between what “h1″ means in markup and what you’re defining as your intent via the CSS.
But you don’t get to move a tomato from the tomato bin into the banana bin, and then start saying it’s more like a banana because of which bin it’s in. That is crazy. The thing itself, in our case, the word itself, carries inherent intrinsic meaning — built-in semantics.
Table Semantics
Now, let’s talk about tables. That’s where this article comes from. Because there are a number of developers who have been trying to convince me over twitter, emails, and blog comments that tables are special and somehow not subject to my above observations. I bet you can guess what I’m about to say, by now.
<table> in my markup means that I’m laying out a set of data to be presented in a grid (aka, a “table”). That’s what the markup element was intended for, and if developers were well-behaved, they would only use tables for that purpose.
Notice that, consistently, I’m not talking about how search engines or screen readers interpret tables. I actually don’t care as much, personally. But I know they also follow a similar pattern of interpretation.
But what I care about is what my intent is, as a developer, to myself and other developers on my team. I should use tables where they make sense, and I should avoid them (even though they may be very handy for their hack’ish side effects) in places where they would violate my intent — that is, my intended semantics.
Table CSS
Remember above, when we all scoffed at how ridiculous an idea it would be to add a display:h1 or display:header-level-1 feature to CSS? Yeah, that’s crazy. No sane CSS spec author would ever do that.
Except… oops. They did. They went and display:table‘d us. That’s right, they took the word “table” from the markup world, and they put it directly into the CSS world. You know what else they did? They made the display-functionalities of the two identical, complete with the hacky quirks we all love about table-cell alignments.
And then, and here’s where it gets good, they said to us all, “Pay no attention to the main behind the curtain. Pay no attention to the fact that display:table is obviously connected to <table>. When we moved tables into CSS, we ditched all their semantic meaning and they became entirely presentational.”
Do you buy that? I call bullshit.
Just like above, when I said that style="display:h1" or class="h1" are every bit as much exposing their semantics, style="display:table" screams at me, “hey, I, the developer, am intending to use this as a table.”
I see absolutely no difference in developer intent — intended semantics. The only difference is whether the markup has a bunch of <td>‘s or <div class="td">‘s in it. It’s obvious the intent is tables.
Like I said, tables are not bad. But please stop trying to fool me (or yourself!) into believing that the file extension where some rule sits magically controls the developer intent. The semantics are self-obvious.
The <end>
If I use <end> or I use display:the-end here, either way, you know exactly what I mean. I mean I’m at the end of the post and wrapping things up. Which technology umbrella I hide under isn’t the point. What I mean is the point.