Posts Tagged ‘semantics’

More On HTML5 Semantics

Monday, November 14th, 2011

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.

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.

The Value of Meaning

Friday, November 11th, 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.

Comic Update: Conversation Sans Semantics

Monday, September 21st, 2009

Today’s comic features Jeremy Keith, HTML5 “DoctorMike Robinson and the squirrel having an innocent conversation about Thai food and emails going where they don’t belong, while the poor Google-bot attempts to understand who is speaking without semantic guidance. I should warn you, a specific body part’s medical term is used a few times. All in good taste, mind you.

The reason that these two fine England-dwelling individuals join the squirrel in the strip is that each of them also had a slight issue with something that I found distasteful over the week: HTML5 documentation giving guidance for using non-semantic markup as a solution for marking conversations in HTML. The markup in question for a short time suggested using the b tag to note a speaker, with the text of the speech being in p tags. A short bit of criticism later and that was dropped, but as you can see here, there’s no replacement suggestions yet for any semantic solution.

Look. It’s 2009. We’re working on HTML5. We know that semantic-free markup (or semantically-confused markup) is something best avoided when possible. A conversation is one of the basic methods of human communication. I’m going to guess 99.999% of all people have at least one conversation daily. At least a portion of these end up on the web. Is there any reason to assume that we wouldn’t want to make this data more accessible for machines and screen-readers to understand?

The proposed dialog element has apparently gone the way of the dodo. I don’t know if this is good or bad. But I’d like some sort of method to markup conversation that isn’t arbitrary and devoid of meaning. And, contrary to the opinion put forth in this W3C mailing list email, I’m going to believe that my opinion on this matter is valid despite my tendency to draw squirrels. Ever since making the commitment to providing transcripts of the comics I create, I’m invested in having some method to mark up conversation. I’m also in the camp that prefers that markup to make sense.

I don’t know all the pros and cons, but I like the proposal put forth by the HTML5 Super Friends in their list of concerns: let’s use cite and q, or at the very least do some research to see how well that one works out. It makes sense, it’s simple, and we don’t have to invent new elements. I for one am going to start using them going forward until something that makes more sense comes along.

But enough with suggesting semantic-free elements for markup. We’ve already got div and span, I don’t really see the need for b and i to keep rearing their ugly heads.