It’s been a few days since I wrote my post (and comic) entitled The Value of Meaning, wherein I registered my objection to Divya Manian’s article about HTML5 semantics called Our Pointless Pursuit of Semantic Value. In that time there’s been a great deal of continuing discussion on the topic from a lot of intelligent people that’s worth pointing out in case you missed it.

• Firstly, there was a great comment thread on my post including voices such as Divya’s. Check it out.
• In particular, you should read John Foliot’s response at the end.
• Jeremy Keith’s Pursuing Semantic Value is a must-read. In it he agrees with Divya’s core message, notes an issue with tone, and guides you through the process of where his agreement with that core message takes him to a very different conclusion.
• Steve Faulkner replies to Jeremy’s article with a comment that grows up to being a full-sized article of its own: HTML5 Semantics and Accessibility.
• Paul Irish, a veritable Chuck Norris of web development, also wrote in response to Jeremy Keith with Semantics in practice and mapping semantic value to its consumers.
• John Foliot responds to Divya in a detailed, no-holds barred post that examines the merit (or lack thereof) of her speaking points about semantics in My Thing About the Thing That Thing Wrote About Thing.

If you have time, you should read all of these. They’re all written by intelligent people getting into the heart of the HTML5 semantics debate with more clarity and detail than I could ever manage.

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.

Edit: Roughly twenty minutes after I posted this, the W3C took action on the issue, insisting that the <time> element be placed back into the specification. You can read about it here. But please read on. It’s a good primer for the next time something like this happens.

Contrary to what you may have already heard, the <time> element hasn’t disappeared from HTML.

Yes, officially <time> is currently not part of the HTML spec. (Thanks to the muddle that is “HTML Living Specification” I’ll be honest and admit I’m not sure if is no longer part of HTML5 or it’s in some sort of Schrodinger’s Cat quantum-zombie state of existing in HTML5 but missing in the “ongoing HTML” that the WHATWG is proud to keep rolling down the conveyor belt.)

That doesn’t mean it’s not being used by authors (how’s Drupal builds, 2.6 million WordPress installs and the Boston Globe for you?) nor does it mean that is it not being used by user agents (ever-plucky Opera supports it).

What it means is that a single human being has decided that he doesn’t care for time one wit, and that a rather vague element called <data> can replace it instead.

This human is none other than Ian “The Benign Leviathan Dictator For Life” Hixie, editor for the HTML specification.

I could give you an explanation on how this scenario came to exist, but two Brits who are far more informed than I am (and likely slightly smarter) have made their own summaries. If you like knowing what’s going on (and I do) then go read them. These pair of fine gentlemen, Jeremy Keith and Bruce Lawson, both guest star in today’s comic as the good Doctor thanks to a little spot of regeneration, where they’re fighting the good fight against Hixie’s <data>leks.

Virtually every problem I have with a single person wielding so much power over such a fundamentally important pillar of the web as HTML can be summed up in this incident. <Time> is officially out, despite the lack of merit or consensus in that decision. And it took just one man to make that happen. Either through a lack of awareness or a genuine disregard for what authors are already doing, Ian has claimed incorrectly that <time> isn’t seeing adoption, isn’t useful, and should be canned. And because the only balance to his power is a rather tedious process to oust him, there’s no official remedy to bringing <time> back into the HTML fold than trying to convince him that its existence is a good thing.

From what I understand, it’s easier to keep red shirts alive on away missions than it is to change Ian’s opinion on something.

Fortunately, there’s a big difference between having no official remedy and having no remedy whatsoever.

As “authors”, we are the 99% of HTML5. We can follow Jeremy Keith’s sage advice:

We can make a stand and simply carry on using the time element in our web pages. If we do, then we’ll see more parsers and browsers implementing support for the time element. The fact that our documentation has been ripped away makes this trickier but it’s such a demonstrably useful addition to HTML that we cannot afford to throw it away based on the faulty logic of one person.

So as I said, <time> hasn’t disappeared from HTML. It’s still there on millions of sites already. And nothing is stopping us from putting it on millions more. It’s our chance to send those <data>leks packing. As soon as this post is finished I’m going to edit my site’s theme to make use of <time>. Hixie can go stuff it.

Occupy HTML5.

In the past I’ve made it fairly clear that I disagree with a lot of the decisions that HTML5 editor Ian Hickson has made in the past, such as the movement of the WHATWG version of HTML5 into Last Call (well before the W3C has done so, creating an oddball situation where arguably the spec exists in two different states). I felt that he was making a decision to move the spec forward to meet an arbitrary timetable, and not because it was mature enough to deserve that state.

Now that the WHATWG has gone onto its version-free HTML Utopia, leaving the W3C to make sure there’s a benchmark for browser vendors to compare against with what us mere mortals are still calling HTML5, I had hoped that at the very minimum we could rely on a standard that would properly address all the issues before declaring itself an adult.

I was wrong.

Accessibility is an issue that gets me worked up at times. While observing the various battles in the mailing lists of the W3C, it becomes clear that often those most aware of good practices for accessibility are given the least amount of attention by decision makers. Right now we’re witnessing the W3C’s chairs pushing for HTML5 to move to Last Call while ignoring a massive lump of requested data about an accessibility issue.

AKA: They’re moving the spec forward without addressing existing, outstanding issues.

Today’s comic highlights my opinions on that.

It seems that as a result we’re going to end up with a standard that will only address best practice for accessibility as some sort of later patch. This is a load of crap.

For some reason, several smart people think the longdesc attribute is hard to use. So hard to use that we’d best not even bother keeping it in HTML5 as a means to provide alternate text for images to sight-challenged web users.

I’m going to tell you how to do it in a detailed fashion, and you can decide if it’s hard: 1. Put a longdesc attribute on your image with a value that points to a url of a page with a detailed description of the image. 2. At that destination, write the description.

Pretty hard stuff, right? I don’t know if you can remember all that.

This culminated last August as Issue 30, where the working group chairs decided to leave longdesc out due to a lack of data, and they encouraged people to feel free to get more data and approach them again.

In fact, I quote:

This issue can be reopened if new information come up. Examples of possible relevant new information include: use cases that specifically require longdesc, evidence that correct usage is growing rapidly and that that growth is expected to continue, or widespread interoperable implementation.

Laura Carlson took them at their word, creating a research document with over 150 examples harvested from the “wild” and compiled into several use cases, along with relevant local laws and policies from governmental and corporate entities using the attribute.

Armed with a treasure trove of the requested data, she asked the chairs to re-0pen the issue to consider it before Last Call.

Sam Ruby, W3C HTML5 Co-Chair, says “Thanks for all the data. I know I asked for it. But no. Focus on other important stuff instead. Ha ha.” (That might be a bit flavored of a paraphrasing…)

I couldn’t help but read into that an unspoken “Addressing the needs of blind people should take a back seat to getting the spec out the door.”

Class act, guys.

Today the W3C unveiled its new logo for HTML5. As you might notice, it’s quite fancy.

The site’s pretty slick, as well.

Today’s comic relates to this new logo, in a roundabout way, featuring Jeremy Keith, Bruce Lawson (or perhaps it’s Super Bruce) and Remy Sharp (Or is it SuperHTML5Rem?) in their guises as HTML5 Super Friends, attempting to save the web from itself. It also refers to a slippery terminology slope.

The FAQ page for the new logo (yes, it gets its own FAQ) includes a little mention about what the logo represents. Which is obvious: HTML5, right? Well, apparently HTML5 doesn’t stand for Hyper Text Markup Language anymore. But apparently its all for “a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.”

Say what? I’m with Jeremy and Bruce on this one. The logo is pretty, but the intentional use of HTML5 as a blanket term for other modern web technologies is a crock. Newspapers making merry with the term is one thing, but a web standards organization? We rely on these groups to keep our handy developer toys in nice, cleanly demarcated buckets so that we can easily educate ourselves and the next generation of developers on what toy is used for what job and how.

I could rant on this for hours. But I recommend reading at minimum Jeremy’s bit on the topic. He manages to be far more eloquent with his words and has earned his place as a bit of an authority on the topic. So maybe you’ll value his two cents more highly. All I know is that when I used to say “HTML5″ people knew what I meant. At least in my own community of website creators. But now it’s as meaningless as “doohicky.” As in, “Are you talking about the doohicky that I style pages with or the doohicky that I make the structure with?”

TL;DR Version: Love the logo, hate the term-squishing.

As a parting shot, I object to Karl Dubost’s characterization of term-blurring opponents’ commentary as “vapid“. I’m sure Jeremy Keith is capable of a lot of things when writing, but even if you disagree with his viewpoint on the topic, his well reasoned rhetoric doesn’t merit such a label. Shame on you, Karl.