A Semantic HTML Resume

A resume is an interesting piece of content, rife with opportunities to apply semantic markup & some more advanced features like COinS (at least in academic resumes). I recently revisited my resume web page, bringing it up to date but also redoing the markup for great justice. I'm going to divide this topic into two posts, because it's not the most exciting & I'm really going to drone on about citations in the second part. Aren't you excited?

High Level Overview

A resume is a perfect use case for the new <section> element, since it's divided into multiple independent pieces each with its own header. Therefore, instead of the standard, a-semantic <div> markup that my previous page used, I decided to give <section> the job of demarcating my work experience, education, et cetera. Each section has a header that describes its content. I chose the <h3> element for my headers, because the <h1> is used for the title of my website, the <h2> is used for the title of the page (e.g. resume in this case), thus <h3> makes sense as its the next step down in the hierarchy. Indeed, looking at my resume page in the HTML5 Outliner, it is structured in the most logical manner. Unfortunately, my Drupal theme wraps the main content of a page in an <article> tag, which is inappropriate in this case & throws off the outline, but other than that I'm good.

Within each <section>, however, I was uncertain about how to proceed. My previous page used HTML's definition list (<dl> being the root element, followed by a <dt> for a term and a <dd> for a definition) & I stuck with that, albeit after some hesitation. Is a list of previous & current employers really a set of definitions? So I went to my go-to source for HTML5 semantics: the HTML5 Doctor. &, lo & behold, HTML5 has repurposed <dl>, turning it from a "definition list" to a "description list" in a way that better suits my usage.

Schema.org

What really incited me to redo my resume was listening to a podcast on Schema.org & microformats, as well as reading the recent Code4Lib article on implementing Schema.org in a cultural heritage context. I wanted to try out this new means of smuggling metadata into Plain Ol' Semantic HTML (POSH, for those in the know ;). The hResume microformat would have been another choice & I don't mean to advocate for one approach to the exclusion of the other. For my purposes, the Person schema was obviously the best choice & it provides several fields that would be present in most any resume or CV.

Unlike Microformats, which operate by placing structured metadata inside HTML class attributes, Schema.org's microdata approach utilizes a couple new attributes. First off, your root element that contains all text being described by the schema will have a boolean itemscope attribute as well as an itemtype attribute with a value pointing to the URI of its schema. Then, beneath that root element, one adds itemprop attributes to the various pieces text that fall under a property of the chosen schema. So, for instance, the <dt>University of Illinois</dt> in my Education section becomes <dt itemtype="alumniOf">University of Illinois</dt>. Some of the Person properties I used include name, worksFor, jobTitle, alumniOf, memberOf (for professional organizations), & url. That's a lot of additional information exposed to machines. While I can imagine many more properties, perhaps the one glaring weakness in the schema is the lack of a "creatorOf" property. There's "performerIn" but not "creatorOf", which is silly. The fact that other Schema.org items such as books, movies, & music all have "author" or "creator" properties only highlights this myopia.

Once I marked up my resume in the Person schema, I could view the results of the invisible metadata in a few ways. For one, Google has a Rich Snippets feature in their webmaster tools that shows what data the Googlebot sees, including what can be exposed to a Custom Search Engine. You can also see previews of what your page might appear like in a search result, though there's no guarantee that Google will use the rich snippet. There's also the Live Microdata site which validates your microdata & can show you what it looks like as JSON. Right now, the big selling point—that I'll get a customized search result—isn't panning out. It's actually a super ugly result for me when I'm signed into Google, with a citation as preview text & some Google+ spam below. But there are other reasons to embed metadata in HTML & I had a pleasant learning experience.