The Value of Meaning

November 11, 2011
CSSquirrel #89: The Value of Meaning

Divya Manian is a bright cookie. When it comes to the web, you can say with complete assurance that she knows her s***. She’s in that category of people that makes me insanely jealous of their creativity and intelligence.

All of which makes me think that somehow she’s trolling us today.

Our Pointless Pursuit of Semantic Value is a shortsighted piece, placing the value of markup solely upon the capabilities of browsers (and other user agents) today at the expense of tomorrow. It’s the sort of article that I would have perhaps expected from the internal website developer of a large corporation at the turn of the century that only permitted its employees to use Internet Explorer 6.

When I started getting paid to make websites instead of pizza, I was bombarded non-stop by the value of making websites that weren’t locked into the limits of the less-capable browsers of the moment (some of which, like the big blue e, were more than a little antiquated), but was instead encouraged to embrace forward-looking mentality of making the best of emerging features where I could and creating a fallback position where necessary. I can’t remember if we called this graceful degradation or progressive enhancement (I’ve heard the two used and misused so much that they blur in my brain), but nowadays we just call this technique “common sense”.

Did I make special span tags on elements that had rounded corners, placing background graphics on four separate corners so that the Great Blue Mentally Misunderstood Beast of the Internet could have pretty edges? Hell, no! I used border-radius and knew that somehow, someday, all browsers would eventually understand it meant I wanted pretty, round corners to nuzzle up against and whisper sweet nothings to at night.

I’m aware that HTML isn’t CSS, and what applies to one doesn’t necessarily apply to the other. But I’m fairly convinced that if anything, the principle applies even more with HTML today than it did with CSS yesterday. Barring a few legacy browsers that need to ride the HTML5 Shiv/Shim Short Bus, using a div or a header isn’t going to have any impact on a browser’s ability to properly render an element. Which means there’s no harm being done by using a semantic element before user agents get around to taking advantage of its extra meaning.

If I had to summarize Divya’s points in her article (I recommend you read it rather than relying on what’s bound to be a dramatic oversimplification on my part), it is that we shouldn’t bother with semantics because:

  1. Semantics Are Hard
  2. Current Browsers, Search Engines and Assistive Technology Don’t Understand It, So Don’t Bother
  3. Spending As Little as 40 Minutes To Learn About HTML5 Markup Is A Waste Of Time

Semantics Are Hard

Divya points out a piece by Mark Pilgrim on the difficulty of semantics. So, Semantics is hard. So what? Last I checked, I was a professional doing a job for a living. It’s my job to know what part of a website is its navigation or is its primary content. HTML5 isn’t really demanding much brainpower from me on deciding what element to use for what job. I’m fairly confident that the general meanings of header, footer, nav, time, audio, video, progress and summary elements are easy enough to grasp as a person who works with websites for a living. Agreed, article and section are a bit confusing, but I don’t think by and large that HTML5 semantics are a byzantine labyrinth of alien thought impressions that cannibalize the minds of sane men.

Current Browsers, Search Engines and Assistive Technology Don’t Understand It, So Don’t Bother

When I was making a few years back, Internet Explorer didn’t understand border-radius. Yet, despite that, I used it in making websites. And not only does IE now understand (and render) those pretty corners, but many of those websites still exist, using the same code I wrote back then. If I had chosen to not use border-radius because of the limitations of the time, the sites wouldn’t look good today because of my short-sightedness.

HTML5 is still settling down into its patterns. Some of the meanings are still being locked in. It’s not “done”, as evidenced by Hixie’s arbitrary and somewhat bizzare attempt to remove the time element from the spec. Does this mean that I shouldn’t be using elements from the specification because it’s not done now? Of course not! The sites I’m making today will not only be live for years, they very likely won’t see a redesign for much of that lifetime. Relying only on what’s “finished” now would be a disservice to my clients today, preventing them from benefiting from features for years because of a technicality on the spec’s status or the full support level of browsers.

AT, browsers, search engines, they will all catch up with taking meaning from semantics at some point in the future. When they do, would you rather that your website was ready for them, or would you like to spend time (and money) re-coding your mess of divs into something slightly more relevant? There is no harm in using divs now (when other, more semantic elements might be better). But there is a very good chance that it will put your site at a disadvantage later, when the technology catches up.

Saying that I shouldn’t use semantic markup because AT, browsers or search engines aren’t consistently taking advantage of it in the present is like saying that I shouldn’t use video or audio elements because some browsers aren’t taking full advantage of them yet. It’s limiting my future benefits by over-adhering to the present. How many of Divya’s CSS tricks shown at her presentations at conferences work on all current browsers? In all likelihood, none of them. Does that mean they don’t have value, and shouldn’t be used?

How is making use of semantic markup any different?

It’s not.

Spending As Little as 40 Minutes To Learn About HTML5 Markup Is A Waste Of Time

I am shocked that she said this. I’d almost characterize it as insulting. We are professionals in a career that demands continuing education.

At the end of the very same post, Divya suggests that developers learn Javascript. Which is good advice. Learn it. Love it. But how can you advocate the value of self-education while simultaneously characterizing spending forty minutes of your time to familarize yourself with the meaning of some of HTML5′s elements as a waste of time?

Sometimes the choices we make in markup don’t result in manna from heaven. Personally, I don’t attempt to adhere to sensible, semantic markup for the sake of SEO (which I consider a bunch of snake oil bulls*** anyhow) or for accessibility purposes. I do it because there’s an inherent value in attempting to do something in a consistent and correct fashion. There is meaning and purpose in constantly attempting to improve one’s level of craftsmanship.

There is nothing pointless in pursuing good standards, including adding semantic value to your website. Even if there was no future benefit to properly, professionally crafted markup (and there will be), there’s an inherent value in taking pride in your work and producing a product that is more elegant than that of your hurried, slapdash competitor.

There is meaning in striving for meaning.

Or as Karl commented in Divya’s post:

inadf, rjfsnsl nx pjd yt zsijwxyfsi jfhm tymjw. ny’x ymj xthnfq htsywfhy ns gjybjjs tzw nijfx. dtz fwj rncnsl uwthjxxnsl fsi rjfsnsl. vznyj xfi.

15 Responses to “The Value of Meaning”

  1. This is a reductio ad absurdum rebuttal of my post. I have never said, just use p tags or em tags or span tags throughout. I merely point to the fact that we try to keep struggling to reach a sisyphean ideal of semantic markup that will never happen and will not profoundly change the web even in the unlikely event of it happening. I am very much a proponent of using clean, readable and efficient markup, but not for pedantic arguments over if a piece of text needs to be marked up with i or b or strong or em.

  2. I think the point she was trying to make is more that no one is cooking anything. And for all the hours we’ve spent carefully labeling the twenty or thirty jars we’ve made, they’re being chucked into a fridge that already contains over twelve billion other jars—some of which are well-labeled, most of which are not, and many of which contain animated .gifs of dancing babies that are just labeled “WELCOME TO MY GEOCITIES HOMEPAGE.” Not only is no one using these labels to cook, it’s barely possible to cook anything—if it’s possible at all.

    That doesn’t mean I’m switching over to tags for everything. I’m no idealist, but rest assured I’m gonna stay the course and fight the good semantic fight. I know Divya will, too, and so too should you all. But she’s right: despite our years of careful craftsmanship the landscape is still looking pretty bleak. There’s never any harm in taking a step back and thinking critically about how we’re working.

  3. @Divya – I admit, I reduced your speaking points to a rather simplified bullet list, as I stated at the time. But I feel that the post as thoroughly addresses your post’s apparent intent as one could expect when you repeatedly state the only value of the semantics in an incomplete specification is based on what is currently practiced (aka don’t take future/planned implementations into account), and when you refer to a 40 minute research session into the meaning and purpose of html5 elements as a “waste of time”.

    Although I’m not an expert with accessibility, every conversation I’ve had with the more-informed on that topic does draw a line between semantic markup and accessibility. Yes, there -is- abuse of HTML markup, but that might just be due to people advocating that “semantics is a pointless pursuit”. Rather than suggesting that people not bother, maybe more resources could be exerted on educating people on the proper meaning and use of the elements that exist.

    Your piece repeatedly questions the value of semantics based on the current state of implementation by user agents. I say, and I don’t think it’s an unreasonable counter, is that viewing the value of any web practice on what implementers currently do is inconsistent with how we’ve bettered the Web in the past or will make it better in the future. CSS implementation didn’t get better because we stopped using it until IE caught up. Why would this be any different?

  4. Accessibility is accomplished through the relationships that accessibility APIs create. They can occur with attributes or tags or heuristics. Assuming ‘semantic’ elements lead to accessibility is a pitfall. No screen reader makes the distinction between b or i and neither does it make sense to. An article or a section makes no difference to a sighted reader, so what purpose does it serve creating a ‘feature’ in screen readers to make that distinction?

    There are a lot of issues that ARIA solves which has nothing to do with semantics of the elements you use but all to do with interaction of content with the reader. We need more awareness on ARIA and its interaction with HTML5 and not pedantic discussions on what kind of tone you are conveying using a tag to markup content.

  5. Neither Assistive Technologies nor search engines give up on extracting semantic meaning from markup simply because there are badly marked-up sites out there – any more than users give up on extracting meaning from visual design because there are many badly designed sites. So the suggestion that Geocities and its successors hinder the proper use of semantics is nonsense.

    As for the point that article and section make no difference to a sighted user, it’s true that browsers do not give them a different visual treatment. They don’t display header, footer or nav any differently either. But just like the latter three tags, there are many situations where the differing semantic values of article and section will lead information architects, interaction designers, and visual designers to give them a *very different* visual treatment. There is no reason to force UAs to use heuristics to derive this information (inevitably less reliably) when we can use tags to inform them up front.

  6. I have never expressed any concern over header, footer, or nav. Those are awesome I love them and I recommend using them (if anyone had any inclination to read the full post). It is concerns over divs and sections and articles that are tedious.

  7. Divya saying the Squirrel’s piece is pedantic reducto ad absurdum? After she drops that bucket of straw man pedantry on us yesterday?

    At least the Squirrel is trying to be funny. I’m not sure what Divya’s trying to do, other than piss everyone off by conflating the problems of semantics on the web into a polar argument saying No Semantics Not Ever No Way You’re Stupid.

    Between this and the TIME debacle I’m wondering what the hell is happening on the WHATWG side of the fence. Semantics have ALWAYS been hard. Trying to lay a base semantic layer onto HTML 4 and its divs and spans was the right thing to do, but the further we went down that road (cowpath) the less it became about semantics and the more it became about… I don’t know what. But there was a lot of fighting.

    If the problem is with whether someone is an ASIDE or not, maybe the problem’s not with the content or the creator. Maybe the problem is with the definition.

    And maybe that’s it. HTML5′s semantics have turned out to be as half-baked as HTML 4 and XHTML. They’re an incremental step, but a numbers of things were just elided outright (kinda how accessibility was until the W3C folks finally got their acts together). This recent thrashing around about semantics is a result of these poorly considered choices. Make it all one tag! If you’re spending 40 minutes on semantics you’re the problem!

    Maybe, instead, we should try to fix what we can with HTML5′s semantics while we still can, starting with TIME.

    Meanwhile, we can consider a screed-free read of Divya: Semantics are good things, but getting wrapped around the axle over them isn’t worth it, given that every version of HTML has significant failings when it comes to semantics.

    But I do wish she’d either learn how to rant right (I can give lessons!) or learn how to edit herself. Because whenever she does this sort of polar argument I’m Right sort of stuff, it defeats the purpose of what she’s writing about. Reminds me, oddly, of Mark Pilgrim on his bad days.

  8. @Divya I think you may have misunderstood what I was saying. I have read your original article; I have also read Jeremy Keith’s followup article, which highlights what is perhaps the clearest expression of what you were trying to say.

    My comment above was aimed specifically at the idea (in your comment above) that the default styling provided by visual UAs is any guide to the usefulness of semantic distinctions to non-visual UAs.

    The article and section tags do have different semantic meaning: they are associated with different types of content. It’s not hard to thinks of examples where this difference is seen in the information architecture and interaction design – which would, very often, lead visual designers to give different visual expression to the two tags. It makes no sense to deny this information to non-visual UAs (or force them to resort to heuristics) by using tags without semantic meaning.

    I think we should look past the tedium of deciding between article and section, and instead ask from an IA perspective: can the distinction between the two add valuable semantic information to the IA structure?

    If not, then we can by all means fall back to a div; but we shouldn’t remove valuable information simply because some UAs won’t make use of it.

  9. @matthew “My comment above was aimed specifically at the idea (in your comment above) that the default styling provided by visual UAs is any guide to the usefulness of semantic distinctions to non-visual UAs.”

    I did not mean visual styling alone. If a “normal” user is unable to understand or use the distinctions of a section or an article what is the semantic information that is being conveyed to devices that use the accessibility APIs? What is this distinction that could be used?

    “It’s not hard to thinks of examples where this difference is seen in the information architecture and interaction design – which would, very often, lead visual designers to give different visual expression to the two tags.”

    But it is. In the mailing lists I maintain for HTML5 Boilerplate, the most frequent question is when to use articles or sections. Same on IRC channels I provide support for. And these are not newbies asking these questions but experienced designers/developers. Today’s section can be tomorrow’s aside. How do people deal with that kind of uncertainty for ‘future-proofing’? What is ‘future-proofing’ when the semantic meaning of each element keeps changing every few years (who is going to go back and change their markup which uses the ‘cite’ element?). If visual design dictates the use of sections and articles then clearly there has not been enough separation of presentation and structure.

    You may not have an issue with articles or sections, but there are several who do. These people get stuck in trying to figure out the semantic distinctions and constantly under doubt over what to use when, so much so that the various practical uses of HTML5 are missed by them, and they get stuck in discovering the “real answer” to semantic interpretations of newer elements.

  10. We should all be a little “pedantic” in the face of markup, especially new tags. Without a good grasp now, HTML5 tags, especially those like ARTICLE and SECTION, would become about as useful as the unlabled jars in Kyle’s comic. Let’s not forget, as Roger Johansson of 456 Berea St thankfully reminds us, the Web is a web of content, not an application framework.

  11. @Divya – since I’ve been chastised by many people for my lack of political correctness for previously calling you a Young Lady (and no offense was intended) I am none-the-less going to now point to your lack of “PC” in your response to @Matthew. You wrote:

    If a “normal” user is unable to understand…

    Surely you aren’t suggesting that non-sighted users are thus “un-normal” are you? That somehow their inability to pick up subtle visual clues (such as, for example, nested ARTICLES) makes them not normal. I STRONGLY advise you that you spend a bit of time actually learning about what web accessibility means before you start handing out advice with regard to serving that community.

    With regard to the oh-so-confusing <article> element, you need only remember that it is a direct mapping to the ARIA role of, well, “article” (as in <div role=”article”></>), so ya, sure go ahead and use a div if you are prepared to add that ARIA role, however it think it’s much shorter to just write <article>. Isn’t it one of the goals of HTML5 to make accessibility “just happen”?

    But “why” you claim everyone asks, when us sighted majority don’t see a difference.

    The problem here is that you are seeing something, but it is subtle. From the ARIA Candidate Recommendation:

    article (role)
    A section of a page that consists of a composition that forms an independent part of a document, page, or site.
    An article is not a navigational landmark, but may be nested to form a discussion where assistive technologies could pay attention to article nesting to assist the user in following the discussion. An article could be a forum post, a magazine or newspaper article, a web log entry, a user-submitted comment, or any other independent item of content. It is independent in that its contents could stand alone, for example in syndication. However, the element is still associated with its ancestors; for instance, contact information that applies to a parent body element still covers the article as well. When nesting articles, the child articles represent content that is related to the content of the parent article. For instance, a web log entry on a site that accepts user-submitted comments could represent the comments as articles nested within the article for the web log entry. Author, heading, date, or other information associated with an article does not apply to nested articles.

    While King Ian the All-knowing is taking his <time> tweaking HTML5 from under your feet, the ARIA specification is currently in Candidate Recommendation at the W3C, which is exactly the same state that CSS 2.1 was in for over 5 years: I am here to tell you that using the ARIA landmark roles is both perfectly safe to do and provides very real benefits to end users.

    You ask:

    Today’s section can be tomorrow’s aside. How do people deal with that kind of uncertainty for ‘future-proofing’?

    There are a couple of easy answers there.

    The first is to stop bowing down to the altar of King Ian the All-knowing. When 1 person can write and re-write sections of a specification in the same amount of <time:7gt; that you would spend knocking out one Photoshop comp for a client, then yes, you are going to experience uncertainty. I am a huge adherent to the W3C process which, because there is a process, controls this wild flopping back and forth, because, as people are now starting to discover, that actually turns out to be important.

    Second, if you are really concerned that sometime in the near (or distant) future <article> sill turn into some completely different “semantic container” (likelihood = < 1%) then to “future-proof” that element write <article role=”article”>, because you see, the W3C’s HTML WG decided that ARIA role semantics will over-ride any other ‘semantic’ implied or otherwise: you can use that markup today with no fear that an article will ever be interpreted as anything other than an article.

    What is ‘future-proofing’ when the semantic meaning of each element keeps changing every few years (who is going to go back and change their markup which uses the ‘cite’ element?).

    (equal parts FUD, and why the accessibility community is still up-in-arms over the removal of things like @longdesc – smaller community, same concern) The answer again is don’t give all the power to 1 person – HTML is a shared resource and the community, via consensus, should be making those kinds of changes; if the community wants to make those kinds of radical changes they will go back and do the hard work of repairing the broken content.

    You may not have an issue with articles or sections, but there are several who do.

    All the more reason that when those who claim to be educators and community leaders – “web openers” – speak, they do so with real answers and researched responses, rather than harmful and backward advice based on ignorance and misunderstanding.

    Yes Divya, I am very annoyed with you, because instead of taking what could have been an important teachable moment, you used your bully-pulpit to run a headline that suggests that pursuing semantics is pointless. Those “un-normal” non-sighted users might disagree: Semantics are important.

  12. I think the major takeaway from Divya’s article is that semantic markup has a real-world cost for a theoretical future benefit. Some of that cost is in bytes-over-the-wire (because you can’t simply replace a div with a header in all browsers). Some of it is in training. Some of that cost is in client relationship: not all clients will accept the border-radius example Kyle made in his post.

    Often that cost is negligible, but sometimes it’s not. It’s refreshing for me to see that reality being discussed.

  13. [...] nonsense of course drew quite a bit of criticism. Our buddy CSSquirrel chimed in, which solicited a response from Divya herself. While I was significantly annoyed with her first [...]

  14. I agree with John’s points and won’t repeat, just want to comment on one little point.

    No screen reader makes the distinction between b or i and neither does it make sense to.

    Actually, most screen readers do recognize and report to the user this information. This is done by request of the user rather than changing the way that the content is voiced, but still there is semantic meaning there. It is undoubtedly true that what that meaning is can be ambiguous, but that’s part of what sighted users get to interpret when the text is shown visually so it does need to be expressed for assistive technologies to consume and utilize.

  15. I should clarify that that quote is not from John, but from Divya.