Chapter 11. Speed Round
Over the past nine chapters, I’ve detailed the ins and outs of 16 microformats, giving you the fundamentals, as well as exploring various POSH implementations.
You’re welcome.
It is now time to put that fundamental knowledge to the test. In this chapter, I’m going to cover the last four draft microformats: hAudio, hRecipe, hProduct, and hMedia. But unlike in previous chapters, I’m just going to give you the basics for each.
Why? Well, for one reason, these four drafts are newer than the other draft microformats we’ve discussed. Their specifications are far less stable, with a fair amount of experimental properties and subproperties (meaning they may change or be removed entirely). As such, there is just less to cover.
Another reason is that I’d like you to consider this speed round as an opportunity to learn the basics of a microformat, and then see where you can take it on your own.
Without further ado, let’s get started!
hAudio: Defining Audio Recordings
hAudio is a draft microformat that adds metadata (semantics FTW!) to audio recordings. The added semantic context hAudio provides is intended to encourage sharing, distribution, syndication, and aggregation of audio content on the web.
As a music lover (addict is more accurate), I initially think of audio recordings as music. But hAudio isn’t just for music. It is for any and all audio on the web, including the following:
• Speeches
• Audio books
• Podcasts
• Sound effects
Profile
As with all the microformats, I recommend you add the profile to your document <head>:
<head profile="http://microformats.org/profile/haudio">
And if you are using hAudio with other microformats in your document, just include the profiles for those microformats along with that for hAudio, making sure to separate each with a single space.
Syntax
Now let’s take a look at the properties and subproperties for hAudio:
• haudio, the required root property of hAudio, must be assigned to the element that contains all of the content about the audio recording.
• To define the name or title of the audio recording, you can use either the fn (for a single recording) or the album (for a collection of recordings) property. Your hAudio implementation must have at least one of these values and can have both, if contextually relevant.
• The optional item property indicates a part of the main hAudio, such as a track or song of an album or a section of a podcast. In a way, it is a more discrete hAudio element contained by the parent hAudio. However, you do not need to specify the root haudio element for items. You can, though, indicate the name/title of the item using an fn subproperty. And item can be used multiple times within the root haudio.
• position is an optional subproperty of item that indicates the position of an item in a list, such as a track number for an album, a position in a playlist, or a chapter of a podcast. There can be only one position per item, and the inner content of an element assigned position must be a number or sequential identifier.
• The optional contributor property indicates any person involved in the creation of the audio recording, such as artist, producer, or composer. You can use contributor as many times as your content dictates. The specification also recommends (but doesn’t require) that you mark up instances of contributor with hCard.
• The optional published property specifies the published date of the recording, such as the day a speech was given or the day an album went on sale. While not required, the date information should also include the ISO 8601 machine data, so you would use the value class pattern for this property.
• The category property is used to indicate keywords that describe the genre or style of the audio recording. These keywords can also be considered tags, so you can also apply rel-tag. category can be used as many times as needed.
• You apply the optional sample property to an <a> element with an href destination that is the URI for an excerpt of the recording. You use the rel design pattern for this property, applying rel="sample" to the <a> element. hAudio can have multiple instances of sample.
• You can use the optional enclosure property to indicate the URI for the full recording, again with the rel design pattern where the <a> is assigned rel="enclosure". You can have multiple instances of enclosure per hAudio.
• The optional payment property indicates a URI where the recording may be purchased. Once again, you use the rel design pattern, assigning rel="payment" to the <a> element. You can use payment multiple times within hAudio.
• If you have one or more images associated with your audio recording—album cover, photo of a speaker, picture from a concert—you can use the optional photo property assigned to the <img /> elements.
• You use the optional duration property to specify the length of the audio recording. This property has three optional subproperties to indicate hours (h), minutes (min), and seconds (s). If you don’t care to use these subproperties, you can specify the duration information with ISO 8601 data in the value class pattern.
• The optional price property specifies the currency amount to purchase the audio recording. You can use price multiple times within hAudio, and it can include the optional subproperties currency (assigned to the currency symbol with an ISO 4217 title value, such as USD) and amount (assigned to a numerical value of the amount of currency).
• You assign the optional description property to content that provides a description of the hAudio content, such as a description of a sound effect or the meaning of a song. You can use description multiple times within an hAudio and, in such cases, machines concatenate all instances into a single description.
Practical markup
To say that I liked Def Leppard while growing up would be an understatement. I was obsessed. I burned out my record player (yes, I’m that old) on all of their albums, in particular Pyromania. So, let’s use that as an example for our hAudio markup, which includes the required root haudio property and the required album property:
The rest of the properties and subproperties I used in this example are optional. But the content is there, so why not add the extra semantic goodness. Think of it as frosting for your content cake. Cake is so much better with frosting, no?
Adding hCard
As I mentioned for the contributor property, the hAudio specification recommends that it also be an hCard, so let’s do that for my favorite member of Def Leppard (I wonder if he ever got my fan club letter . . .):
<dd class="contributor vcard"><a href="http://defleppard.
com/band/joe.asp" class="fn url" rel="crush">Joe Elliot</a>,
<span class="role">vocals</span></dd>
Note that I added XFN to this example with the rel attribute (and the crush value) because XFN is appropriate for this person’s hCard url. And because a 12-year-old girl’s rock-star crush never truly dies.
Combining microformats
With the addition of hCard and XFN above, you can see that hAudio demonstrates one of my favorite things about microformats: they can be used together. But beyond hCard, think about some other opportunities for combining hAudio with other microformats.
For my Pyromania example, I could easily include a review of the album (five stars, of course). That makes it a great candidate for adding hReview. If you were using hAudio to mark up a podcast, what about using hAtom too? What if your content is a schedule of events, each of which has an associated audio recording of a speech? You could embed hAudio within hCalendar.
Just remember that whenever you are publishing a microformat, pay close attention to your content to see if there are other microformats you could include. You want your content to be rich and powerful, don’t you?
hRecipe: Defining Food and Beverage Recipes
I love food. Cooking it, eating it, experimenting with it. Same with drinks, especially those of the “happy hour” persuasion. And I love sharing my recipes.
The web is full of folks like me. Folks who publish their favorite recipes on their blogs. Entire sites devoted to food and beverage recipes. It is for these folks—or more specifically, their content—that hRecipe was developed.
hRecipe is a draft microformat for adding semantic richness to food and beverage recipe web content, which, in turn, helps make that content more distributable.
Profile
As of this writing, there isn’t yet a profile URI for hRecipe. However, you can find the XMDP profile on the Microformats Wiki: http://microformats.org/wiki/hrecipe. Be sure to reference the specification when you are publishing hRecipe.
Syntax
The properties and subproperties of hRecipe were developed based on content most commonly found in recipes:
• The root hrecipe property is required and must be assigned to the element that contains all of the recipe content.
• The required fn property is assigned to content that is the name or short description of the recipe.
• You use the required ingredient property to specify the ingredients in a recipe. You can use ingredient as many times as necessary within an hRecipe, but there must be at least one. The ingredient property also has two optional subproperties: value, to indicate the amount of an ingredient, and type, to indicate the unit of measurement for the value.
• yield is an optional property that specifies the quantity of a recipe, such as serves four people or makes ten cupcakes.
• The optional instructions property is assigned to the actual instructions or method for making the recipe.
• The optional duration property specifies—via the value class pattern—how much time it takes to prepare the recipe.
• If you have a photo for the recipe, such as a picture of the final preparation, you can optionally assign the photo property to the <img /> element. hRecipe can include as many instances of photo as your content dictates.
• The optional summary property can be applied to a short introduction or statement about the recipe.
• Use the optional author property if the recipe has an author. The hRecipe specification recommends that you mark up author with hCard. You may use author as many times as necessary for your hRecipe.
• The optional published property indicates when the recipe was published and should include the ISO 8601 machine date-time information via the value class pattern.
• You can use the optional nutrition property for nutritional information about the recipe (such as calories, fat content, and so on). You can use this property multiple times within hRecipe. It also has two subproperties: value, for the amount of a given nutrition item, and type, for the nutrition unit of measurement.
• If the recipe contains keywords or phrases, you have the option of turning those into links (<a>) assigned rel-tag. Remember, links that are “tags” must have an href value that is a tag space.
Practical markup
Thanks to my mother and paternal grandmother—both of whom cooked amazing food and spent hours teaching me their recipes—I’m a pretty decent cook. Lately I’ve been experimenting with game hens, and I finally got the recipe perfected. Lucky you, I’m sharing it with you in the name of microformats:
Combining microformats
Since the specification recommends that author also be marked up with hCard, let’s add it:
<li class="author vcard">Created by <a href="http://
ablognotlimited.com" class="fn url">Emily Lewis</a></li>
What other microformats could come into play with hRecipe? What about hReview? Yep, that would work.
hProduct: Defining Consumer Products
One of the biggest parts of today’s web is its consumer marketplace. Selling, buying, trading. All online. It can be difficult to sort through it all, especially when you are looking for a particular product and want to compare information from different sites.
hProduct was developed to help address this challenge—to add semantics to consumer product information, making it easier to share, distribute, and aggregate that information.
Profile
Like hRecipe, there isn’t yet a profile URI for hProduct. The XMDP profile, however, can be found on the Microformats Wiki: http://microformats.org/wiki/hproduct. Please be sure to reference the online specification before publishing hProduct.
Syntax
hProduct properties and subproperties were developed based on common information among today’s consumer products, while still allowing for a wide variety of product-specific details:
• All of your product content must be contained by an element assigned the required root hproduct property.
• For the product name, use the required fn property once.
• The optional brand property indicates the brand of the product. In some cases, this may be the manufacturer and would also be marked up with hCard.
• To specify the product category (such as car or T-shirt), use the optional category property, which you can use multiple times within hProduct. You can also turn category content into tags by creating links for each and assigning rel="tag" to the <a>s.
• The optional price property specifies how much it costs to purchase the product. The inner content of the element assigned class="price" can appear in currency format.
• Use the optional description property for the content that describes the product.
• You can assign the optional photo property to any images or links to images within your product content. You can use photo as many times as needed.
• The optional url property is assigned to a link that directs to a web page containing further product details.
• You can use the optional review property if your content includes a review of the product. The hProduct specification also recommends that review be marked up with hReview.
• You can use the optional listing property if your content also includes listing details for the product (such as those for listing services like Craigslist and eBay). The specification recommends that listing be marked up with hListing (http://microformats.org/wiki/hlisting). However, hListing hasn’t made it beyond the proposal stage yet, so I would recommend implementing it with some caution.
• The optional identifier property is assigned to unique, identifying information about the product. You can have multiple instances of identifier within hProduct. identifier also has two subproperties: type and value. type indicates the specific identifier, such as model, MPN, UPC, ISBN, ISSN, EAN, JAN, VIN, SKU, and sn. And yep, those examples are valid types. The second subproperty, value, is the corresponding value of the type—for example, the numbers that make up a car’s Vehicle Identification Number (VIN).
Practical markup
Since I just mentioned a car in the last section, why don’t we use a car for our hProduct example? And let’s get all Earth-friendly with it:
Combining microformats
Let’s go ahead and add hCard to our brand content (as the specification recommends), since the brand in this example is a manufacturer:
<p class="description">Mid-size, electric <a href="/tags/
hybrid-car" class="category" rel="tag">hybrid car</a>
from <span class="brand vcard"><a href="http://toyota.
com" class="org fn url">Toyota</a></span> starting at
<span class="price">$22,000</span>. For more information,
visit the <a href="http://www.toyota.com/prius-hybrid/"
class="url">Prius site</a>.</p>
Other than hCard, what other microformats would work here?
If you have a retail site and you publish your product information with hProduct, what additional value could you add to encourage sales? Do you have product reviews? Then add hReview to your hProduct.
Do you have “deals of the day?” Maybe hCalendar would be appropriate.
Are you listing your product for sale or trade on a listing site like Craigslist? You could experiment with adding the proposed (not yet at draft stage) hListing to your hProduct.
As long as you focus on your content and what you want it to do, figuring out the appropriate microformats is easy.
hMedia: Defining Media Files
Throughout this book, we’ve focused on content—most often from the high-level perspective of a large block of content. From a narrower perspective, content is made up of individual bits of content: the text, images, audio, and video.
hMedia was developed to add semantic richness to those individual bits of content that are media files—the images, audio, and video.
Profile
Once again, there’s no profile URI for hMedia, but the XMDP profile can be found at http://microformats.org/wiki/hmedia. And once again, be sure to reference the online specification before publishing hMedia.
Syntax
The properties for hMedia are intentionally simple and minimal (as are all microformats) in order to provide a means to describe the information common to a range of media files:
• The root hmedia property is required and must contain all of the content about the media file.
• The required fn property can be used once within hMedia and indicates the name of the media file.
• Use the optional contributor property to specify any people or organizations that contributed to the creation of the media file. And, while it isn’t required, you should mark up any instances of contributor with hCard, as well.
• You can apply the optional photo property to any images about or related to your media file.
• If the media content is an embedded file (such as a video or movie), you assign the optional player property to the element (often <object>) that references the embedded file. You can use player only once within hMedia.
• If the media content is a link to a downloadable file, use the optional enclosure property by assigning rel="enclosure" to the <a>. Additionally, the <a> should have a specified type value, such as type="image/png".
Practical markup
For Webuquerque, the community group I co-manage, we record our presentations and post the videos to my blog. A video is exactly what hMedia is meant for, so let’s use one of our videos for this example (and yes, a bit of blatant promotion):
Combining microformats
The hMedia spec recommends marking up instances of contributor with hCard, so let’s be good microformat monkeys and do it:
<p><span class="contributor vcard"><a href="http://
webuquerque.com" class="fn org url">Webuquerque</a></span>'s
August event, presented by <span class="contributor vcard">
<a href="http://www.markiesinter.net/" class="fn url">Mark
Casias</a></span>, was a review of tools for creating killer
web applications.</p>
What other microformats could you include? Using hMedia for a podcast or vodcast? Then use hAtom too. Want to give the thumbs down for a video? Add hReview. Is an image associated with an event? Don’t forget hCalendar.
What about hAudio?
By this point, you may be wondering why audio files are included in hMedia, since we already have hAudio. The distinction is that hMedia provides a simple and minimal description of the audio file itself, while hAudio allows for more detail about the audio recording, including price, description, and summary.
But why not use the two together? In fact, like many microformats, they share property and subproperty names, so it is only a matter of adding a few others. Let’s see that in action with one of the songs from my hAudio example:
<li class="item hmedia"><a href="/samples/RockRock.mp3"
class="fn" rel="sample enclosure" type="audio/mpeg">Rock!
Rock! (Till You Drop)</a></li>
hMedia tools
Media on the web is hawt, and tools are already available that help process and beautifully present hMedia on your pages:
• Oomph’s plug-in for Internet Explorer supports browsing hMedia audio, video, and photos. Oomph also offers a jQuery extension that any web author can include on their web pages to provide a nice user interface for their hMedia (http://microformats.org/wiki/oomph).
• The Transformr web-service (http://transformr.co.uk) extracts hMedia and hAtom to produce MediaRSS.
• For more hMedia tools, see http://microformats.org/wiki/hmedia-implementations
Finish Line
Whew! You made it to the end of the speed round. I knew you would.
You’ve also made it to the end of our journey into the beauty that is microformats. You’ve learned about the benefits, the details of each specification, and various implementations for publishing.
But lest you be too disappointed, you are not at the end of your journey with this book. In the next chapter, I’ll be talking about CSS and showing you that microformats do not restrict your ability to style your content any way you can imagine.