Semantic Markup: a good place to start.

5 years ago in September ’07, I started a blog with this post.  I’m now reposting this excited first-time-at-An-Event-Apart post because I like it, and because it’s a really lazy way to start a new blog….

The most important thing I learned at An Event Apart is something I already knew to do: write clean HTML, CSS, & JS, and separate presentation from the page’s structure. But now I can finally articulate why, as well as delving way deeper into the how.

Last night, at bedtime, I started lecturing my non-web-designer boyfriend about the beauty of semantic markup. At some point, he left the room to brush his teeth. I kept talking. From the bathroom, Ari finally interrupted me to ask, “Why would you want to do this?”

Knocked down from my pulpit, I didn’t know what to say. I could come up with reasons, but they seemed trivial, given my fervor; I ended up citing the Episcopal service to defend the importance of clean, semantic markup.

Why write semantic markup?
It is meet and right so to do.

Embarrassed, I resolved to remember the right reasons (or excuses) to write good code, and searched my notes from An Event Apart to help me.

In his “Secrets of a CSS Jedi” talk, Eric Meyer threw out habit and common sense, and started with the content. How does one render quarterly earnings in HTML? With a table. How does one turn that presentation into a bar graph? With CSS. Most of us had labored with divs & spans, assuming that tables couldn’t be sufficiently bent to our will… but we were wrong. Eric demonstrated that we can use CSS to repurpose any HTML element (he even went so far as to give <html> borders and padding). The bar graph wasn’t flawless, but it was so much better than the usual; divs & spans degrade to garble without CSS, while his bar graph degraded to a clear and usable table. Eric wrote his HTML to reflect the structure of content, and then let CSS take care of the display. Duh – it’s what I’ve been doing for years. And yet… wow – it’s totally new!

I now skip over several excellent talks to Jeremy Keith’s, the next morning: “Be Pure. Be Vigilant. Behave.” He preached the message of “progressive enhancement”, which breaks down the page creation process into these steps:

  1. Look at your content.
  2. Write semantic markup – meaningful, and based on the structure of your content. (e.g., Here’s a primary header, a secondary header, then we have a list with some links in it.)
  3. Write CSS to modify the presentation of the HTML.
  4. Use JS & the DOM to modify the behavior of the HTML.

Each of these steps enhances the previous, and the CSS & JS are optional; without them, the content is well-structured and clear.

At first, I was nodding fervently in agreement – however, the devil is in the details, and Jeremy’s plea that we all stop using <a href=”javascript:foo()”> and <a href=”#” onClick=”foo()”> had me feeling a bit guilty. His reasoning was irrefutable: <a> indicates a hypertext link. A JavaScript behavior is not a hypertext link, and since it can be attached to any element, don’t use the wrong one.

One of my favorite CSS stand-bys doesn’t hold up to this rigorous approach to making web pages, at least not in the way I’d just used. Eager to hear Jeremy’s take on this, I asked him about the preloaded rollover trick that uses a composite image and CSS background-positioning… you know the one. It’s typically used for rollover effects on graphical links, which is semantically sound: if the user doesn’t have CSS, the HTML structure still offers a link.

However, I was using this in a case where there was no link, and the goal of clicking on the element was to call a JS behavior. It was clear to Jeremy that the element here should be <img> rather than <a>. Semantically, that’s true – I wanted images that did some cool stuff when you clicked on them, in addition to having a hover state. The reason I used anchor tags, however, is because the only element that has solid browser support for the “hover” pseudo class is <a>. Jeremy pointed out that hovering is a behavior, and thus should be done in JS rather than CSS. Fair enough – but I couldn’t keep myself from asking if he always used JS instead of the hover class, even for links. I was just being obnoxious, though – there’s clearly a big difference between using a:hover to get an effect on links as opposed to using it when the thing being hovered isn’t a link at all.

My question and luck won me Jeremy Keith’s Bulletproof Ajax, a guide to modern JS for the web designer. Some of it’s rehash for me, but I don’t mind, since the prose is lovely to read; the book has replaced the O’Reilly Rhino as my bedtime reading.

Two other talks at An Event Apart have been on my mind as I think about semantic markup:

Derek Featherstone came along and nearly made me weep with his demonstration of a screenreader choking on abundant AJAX. If the developer had written semantic markup and viewed JS as a progressive enhancement, the page would have been much better. Good structure & standards-compliant code aren’t a substitute for accessibility testing, but they go a long way.

Dan Cederholm also gave an excellent talk, which finally clarified microformats for me. As I understand it, the purpose of microformats is to expand upon our limited semantic markup vocabulary (this is an image, this is a link), and add some specifics (this is a contact name, this is a calendar date), by means of changing mark up with agreed-upon standard class names and the like. To restate: if everyone uses the same markup to mean something, it will begin to mean something universally.

I had a blast at An Event Apart – I felt like I was meeting long-lost colleagues. Most of the attendees I met worked for a company, but I found the conference especially useful as an independent contractor, to connect me to the well-populated world of web design with integrity.

Here endeth the lesson.

Leave a Reply

Your email address will not be published. Required fields are marked *