Chapter 7. Defining Events: hCalendar
Information about events is another one of the more common types of web content. It’s everywhere. People publish details about their events to share information, encourage attendance, and even prompt users to save the event specifics to their calendars.
And the hCalendar microformat was developed for just such content. Concerts, parties, and conferences, oh my!
What Is hCalendar?
hCalendar is a formal microformat used to mark up content about events. Specifically, the type of event information you would find on a calendar, such as the following:
• Name/summary
• Location
• Start and end dates and times
• Longer description (than summary)
• Type of event
Electronic calendars
iCalendar, a standard for calendar data, is commonly used to share calendar information electronically, such as via email. iCalendar files with the universal calendar extension .ics can be added to users’ electronic calendars such as Apple iCal.
hCalendar was developed based on a 1:1 representation of iCalendar properties, so that content authors can provide event information on their websites that users can then download (as .ics files) and save to their preferred electronic calendar application.
It functions much like the hCard-to-vCard conversion. Content marked up with hCalendar can be extracted from web pages and transformed into an .ics file (machines to the rescue, once again). This frees users from having to manually add event details to their electronic calendars. They just import the .ics file.
And, of course, there are tools available that handle this conversion. Let’s start with Technorati’s Events Feed Service. Users simply enter a URL for a web page containing microformats (Figure 7.1), and the service generates a downloadable .ics file (Figure 7.2). Users can also use this service to subscribe to a feed of all hCalendar events from the submitted URL.
Figure 7.1 Technorati’s Events Feed Service
Figure 7.2 Technorati’s Events Feed Service generates an .ics file users can import into their electronic calendars.
You can also let users bypass the need to go to the Events Feed Service page by offering the hCalendar conversion directly on your site. Just provide a link to your page containing hCalendar events that has an href value prepended with the Technorati Events Feed Service URL:
<a href="http://technorati.com/events/http://www.
ablognotlimited.com/" title="Download iCalendar">Add to
Calendar</a>
And if your page contains more than one event marked up with hCalendar, all events are extracted and transformed.
You can also extract the electronic calendar files from your hCalendar events using browser-based tools. The Tails Export add-on for Mozilla Firefox identifies hCalendar events and provides options for viewing the containing HTML and exporting the .ics file (Figure 7.3).
Figure 7.3 The Tails Export 0.3.5 Firefox add-on extracts and exports hCalendar events.
The Operator Firefox add-on provides the same functionality, transforming hCalendar into an .ics export. Operator also provides automatic functionality to import the .ics into several calendar applications, including 30 Boxes, Yahoo! Calendar, and Google Calendar (Figure 7.4).
Figure 7.4 The Operator 0.9.3 Firefox add-on provides automatic import into popular web-based calendars.
Left Logic’s microformats bookmarklet also allows users to import .ics files of hCalendar events, but it isn’t restricted to Firefox. If a user drags the bookmarklet to their browser bookmark toolbar (in Apple Safari, Camino, Firefox, and Microsoft Internet Explorer 6 and 7), they can then select that bookmarklet while on a page containing hCalendar and are prompted to download the .ics file (Figure 7.5).
Figure 7.5 Left Logic’s microformats bookmarklet provides a modal overlay displaying hCalendar information and an option to export the resulting .ics file.
I mentioned the Oomph Microformats Toolkit in the previous chapter on hCard, but it is also useful for hCalendar. By adding the jQuery functionality of Oomph to your site, you provide a browser-independent means for your users to easily see and export hCalendar from your pages.
When Oomph detects hCalendar on a page, an icon (Gleam) appears in the upper left-hand corner (Figure 7.6). When users select the icon, a jQuery overlay on the page provides details about the event, as well as a number of export options (Figure 7.7).
Figure 7.6 The Oomph Microformats Toolkit Gleam icon
Figure 7.7 The Oomph overlay displays hCalendar details and options to export to Microsoft Outlook, Windows Live, Google Calendar, 30 Boxes, and Yahoo! Calendar.
Once again, I’ll mention that Oomph is one of the first tools that broadens microformats consumption for everyday users. Folks don’t need to have a special application or browser. They don’t even need to know what microformats are. They just see the icon and can get all the goodness of hCalendar in a single click.
hCalendar, it’s the new black
Like hCard, hCalendar is one of the more popular microformats. Content authors all over the web are using hCalendar to publish information such as the following:
• Yahoo! Upcoming and Local events
• MapQuest Local events
• TripIt itineraries
• Facebook events
And these are just some of the “big” names. Hundreds of corporate, personal, and nonprofit sites are publishing their events with hCalendar.
Search implications
Aside from the electronic calendar feature of hCalendar (which no doubt enhances the user experience), I believe a big reason hCalendar enjoys its popularity is search.
There isn’t much that hCalendar does for search today. There is Technorati’s Microformats Search, which indexes and provides search results about hCalendar events. And Yahoo! Search-Monkey also provides the ability to search hCalendar events on the web.
The future implications of hCalendar (and other microformats) on search are potentially huge. The major search engines (Google, Yahoo!) are encouraging authors to publish structured content using microformats: just look at Google’s Rich Snippets and Yahoo! SearchMonkey. These are relatively new developments in the search world that utilize microformats, and more could be coming.
Personally, I’d rather take the time now to implement microformats than rush to get them in place once some new search technology is unveiled.
Profile
Since I know you are just itching to be like the cool kids and implement hCalendar, let’s get started with the recommended profile:
<head profile="http://microformats.org/profile/hcalendar">
If you are using more than one formal microformat in your content, such as hCalendar and hCard, you can add the relevant profiles together, separated by a space:
<head profile="http://microformats.org/profile/hcalendar
http://microformats.org/profile/hcard">
And once the combined profile I’ve mentioned is ready, you can use that for all formal microformats.
Syntax
As a compound microformat, hCalendar has a number of properties and subproperties, each of which correlates to an iCalendar field thanks to hCalendar’s 1:1 representation with iCalendar.
The root property of hCalendar is vcalendar. It is unique from other microformats’ root properties in that it is optional; vcalendar is required only on pages that contain more than one calendar of events. For pages that contain just one calendar of events, you can certainly use it, but it isn’t required.
What’s the difference? A “calendar of events” can be considered a grouping of events—by date, by topic, or however you may choose to group your events. For example, perhaps you want to provide a calendar of events for your organization and you want to group events by month. If you have a page that lists an entire year of events, you could contain each month’s calendar with vcalendar, indicating that each month is a unique and separate calendar of events.
Conversely, if your page only listed a single month, you could skip the vcalendar property because it is assumed on the page itself. Similarly, if you don’t care to group multiple events in any fashion or if you are only listing a single event, you can omit the vcalendar property.
Required properties
So, if you are listing a single event or a single calendar of events, the only required properties for hCalendar are these:
• vevent applies to the element containing all of a single event’s information. In the case of multiple events on a page, each event must be contained by vevent.
• summary provides a short description of the event, but is commonly used to contain the name or title of the event.
• dtstart contains start date and/or time information for the event.
Once again, if you are providing multiple calendars of events on a single page, you must use the root vcalendar property to contain each calendar on the page.
Optional properties
The remaining properties and subproperties are optional. Use them if you have the content. Don’t sweat it if you don’t.
• dtend designates end date and/or time information.
• duration indicates the length of time an event spans. This can be seconds, minutes, hours, days—even weeks, months, and years.
We’ve discussed the datetime design pattern used for indicating date-time information in microformats via <abbr>, but this pattern is deprecated. So, for the examples in this chapter, I detail the more accessible and usable options for this type of information with the value class pattern.
In context with duration, you indicate the machine-readable data via the title attribute of the element, using the following syntax, where the ? is a digit representing time:
• P?Y indicates years, so P3Y = 3 years.
• P?M indicates months, so P5M = 5 months.
• P?W indicates weeks, so P1W = 1 week.
• P?D indicates days, so P2D = 2 days.
• PT?H indicates hours, so PT6H = 6 hours.
• PT?M indicates minutes, so PT55M = 55 minutes.
• PT?S indicates seconds, so PT30S = 30 seconds.
Note that once I get into hours, minutes, and seconds, the new T delimiter (for time) enters the picture. It always precedes hours, minutes, and seconds.
You can combine these duration values for more specific date-time information:
• P2DT4H = 2 days, 4 hours
• P1W2DT3H = 1 week, 2 days, 3 hours
Now, let’s get back to the rest of the optional hCalendar properties:
• url specifies a link for the event.
• location indicates where the event is held.
• category defines what type of event it is. The type is up to you; there are no specified category values that you must use. However, some commonly used values are meeting, expo, conference, and appointment. But you can certainly use party, concert, workshop, or whatever category you think is appropriate for your event. And your event can belong to more than one category. As such, it can be used multiple times within a vevent.
• description is a longer (than the summary) description of the event and can be as long and detailed as your heart desires.
• dtstamp can be used to indicate the date and/or time the page containing the event was created.
• last-modified indicates the date and/or time the event information was last updated.
• status specifies whether an event is cancelled, confirmed, or tentative. And, yes, you smart little monkey, those are the three status values you can use.
• class is assigned to the access classification of the event, either public, private, or confidential. In practice this property is little used, as there are better methods of providing access restrictions on the web.
• uid specifies a unique global identifier for the contact, typically an IANA format. In practice, publishers have used uid to specify which url of an hCalendar is the primary or uniquely identifying URL.
• geo can be included to indicate the global position of the event in latitude and longitude.
Recurring events
Sometimes events are recurring. And there are a few optional hCalendar properties you can include for such events.
rrule indicates regular recurrence of an event. If you use rrule, you must also use its subproperty, freq, which indicates the frequency of occurrence.
When would you use this? What about for a meeting that occurs on the first of every month? In this example, you first apply rrule to the content indicating recurrence:
<p class="vevent">Our meetings are <span
class="rrule">monthly</span>.</p>
Next you indicate the frequency (monthly) by containing that content with the freq subproperty:
<p class="vevent">Our meetings are <span class="rrule"><span
class="freq">monthly</span></span>.</p>
Another approach for expressing the frequency of recurring events uses <abbr>:
<p class="vevent">Our meetings are <abbr class="rrule"
title="freq=monthly">monthly</abbr>.</p>
This method, however, results in a title value that is, arguably, not that human readable: freq=monthly. So, you can instead use the empty <span> value-title method of the value-class-pattern, which is useful when the title date-time information is only machine readable:
<p class="vevent">Our meetings are <span class="rrule"><span
class="value-title" title="freq=monthly"> </span>monthly
</span>.</p>
The standard values you can use for freq are as follows:
• secondly
• minutely
• hourly
• daily
• monthly
• yearly
You can further clarify your freq values with the interval, count, and until qualifiers:
• interval indicates the interval of frequency, such as every two weeks.
• count indicates how many events occur within the range of recurrence.
• until indicates the end date for the range of recurrence.
The count and until qualifiers are mutually exclusive. You can use one or the other, not both.
To specify these qualifiers, use the value class pattern empty <span> value-title method for rrule, and include the qualifier and value in the title, along with freq:
<p class="vevent">Our meetings are <span class="rrule">
<span class="value-title" title="freq=weekly;interval=2">
</span>every other week</span>.</p>
In English, the machine data contained in the title of this example says the event is every other week. I could be even more specific and indicate there will be, for example, nine events in this range of recurrence:
<p class="vevent">Our meetings are <span class="rrule"><span
class="value-title" title="freq=weekly;interval=2;count=9">
</span>every other week</span>.</p>
Or, instead of a specific count, I can indicate the end date of the recurrence:
<p class="vevent">Our meetings are <span class="rrule"><span
class="value-title" title="freq=weekly;interval=2;until
=2009-12-05"> </span>every other week</span>.</p>
Note that when using multiple qualifiers, each has a value preceded by an equal sign, and each is separated from the others by a semicolon.
And yet there are even more freq qualifiers you can use to get even more specific, each of which has a range of values (listed in parentheses below) you can assign:
• bysecond (0–59)
• byminute (0–59)
• byhour (0–23)
• bymonthday (1–31)
• byyearday (1–366, to account for leap years)
• byweekno (1–53)
• bymonth (1–23)
• byday (SU, MO, TU, WE, TH, FR, and SA are case insensitive)
You treat these freq qualifiers the same as interval, count, and until: apply the qualifier and its value to the title, separating it from other qualifiers with a semicolon.
So, here’s what I would do if I wanted to indicate that an event recurs monthly, on the first Wednesday of the month:
<p class="vevent">Our meetings are <span class="rrule"><span
class="value-title" title="freq=monthly;byweekno=1;byday=w
e"> </span>on the first Wednesday of every month</span>.</p>
Of course, there are also those types of events that recur irregularly. For these, you can specify the rdate property, which allows you to enumerate the specific dates of recurrence in a comma-separated list of ISO 8601 dates.
<p class="vevent">Our meetings are <span class="rdate"><span
class="value-title" title="2009-02-04,2009-03-04,2009-04-
01,2009-05-05"> </span>on the first Wednesday of every
month</span>.</p>
Once again, you use the value class pattern empty <span> value-title method to contain the machine data in the title of <span class="value-title"> immediately inside <span class="rdate">.
Practical Markup
Now that you know your property and subproperty options for hCalendar, let’s see what some of your POSH options are.
Single-event listing
For this example, I want to demonstrate the markup I would use to detail a single event. Let’s use one of my favorite events: SXSWi—the conference as a whole, in this case, not all of its sessions:
Optional root property: vcalendar
This example includes just one event. As such, I can omit the vcalendar root property because it is assumed on the page.
Required property: vevent
I do, however, need to add the vevent property to all event information. Because there is no containing element for all of the event details in this example, I add a <div>:
Required property: summary
Since summary is most commonly the event name, I add that required property to the <a> element containing the name:
Optional property: url
Indeed, this example contains a link to the event’s website, so I can add the url property:
Required property: dtstart
I add the other required property, dtstart, to the date information using the value-title subset of value class pattern:
I could also use the empty <span> technique of the value-title subset for dtstart:
<li><span class="dtstart"><span class="value-title" title=
"2010-03-12"> </span>March 12</span>–16, 2010</li>
Or I could use <abbr> with the value class pattern, since I’m only specifying a date ISO 8601 value, rather than a date-time value:
<li><span class="dtstart"><abbr class="value" title="2010
-03-12">March 12</abbr></span>-16, 2010</li>
Just pick your preferred poison, taking into account your audience. Will browser tooltips of the ISO 8601 date confuse them? Do you have screen-reader users who will be confused by the expanded <abbr>? Or do you have world-wide readers for whom the ISO 8601 date may make sense in a tooltip or screen-reader expansion?
Optional property: dtend
The dtend property, for specifying the event’s end date, is treated the same way as dtstart, using the value-title subset of the value class pattern:
But again, you can use any of the methods I detailed for dtstart. Just be consistent and use the same method for both properties.
Optional property: location
As this example includes the location, the location property is added:
Optional property: description
This example includes a somewhat detailed description of the event, so I can include that property:
Optional property: category
The content in my description includes the category to which I would like this event to be assigned:
Optional property: duration
Finally, my description content also mentions the duration of the conference:
Once again, because I’m dealing with date-time information, I’m using the value-title subset of the value class pattern for duration. And, once again, because the date-time information for duration is only machine readable, I’m using the empty <span> value-title technique.
The end result
Here’s the complete code example, fully marked up with hCalendar:
The logic behind the markup
I chose a bunch of different elements for my event content in this example. The <h3> potentially offers some SEO for my event name, as many search engines give content contained by heading elements additional importance.
The date-time and location information, meanwhile, makes sense as a list. In fact, this could even be a <dl>, with <dt>s “introducing” the content:
And finally, the description is most definitely a paragraph, so it makes sense to use <p>.
Single event using <dl>
The previous example required the addition of a nonsemantic <div> container, which isn’t a bad thing (remember, reality over purity). But I could’ve also contained all of my event information in a definition list:
Required property: vevent
Note that since I’ve assigned vevent to the <dl>, I cannot include other events within this definition list. And I can’t assign vevent to the <dt>, because it doesn’t contain the <dd>s.
So if you have multiple events on your page, this implementation may not be ideal.
Required property: summary
The summary property is most often used for the event name, so I apply it to the <a> element containing that content:
Optional property: url
I also add the url property to the <a>, since it indicates the website for the event:
Required property: dtstart
For this example, I’ve decided to use the empty <span> method of the value-title subset in order to avoid any confusing browser tooltips or screen-reader expansions.
Optional property: dtend
I use the same empty <span> method to indicate the event end date with dtend:
Optional property: location
Next, I assign the location property to the <dd> containing the city and state where the event takes place:
Optional property: description
The description property is then assigned to the <dd> containing the event description:
Optional property: category
The description content includes a reference to the type of event (conference), so I apply the category property, but first have to create a <span> to contain the content:
Optional property: duration
The description also includes the length of the event, which is ideal for the duration property. Once again, I add a containing <span>, as well as an inner empty <span> to indicate the machine data for duration using the value class pattern:
The end result
After all the relevant hCalendar properties and subproperties are added, the final markup appears as:
The logic behind the markup
Personally, I’m not a huge fan of using list elements for just one item, in this case a single event. However, the <dl> does work nicely to contain all the event information. Further, the event name is contained in the <dt>, while all the related descriptive information is contained in <dd>s—an appropriate use of a definition list.
There is just one minor drawback to this implementation: a <dt> cannot contain block-level elements, so I lose the potential SEO the <h3> element (in the previous example) offers.
The point is, though, your markup options are far greater than you realize. Consider your content, consider semantics, and then experiment.
Multiple events using nested lists
In this next example, we’re dealing with content for a date-based (monthly) calendar that includes multiple events, such as sessions for a two-day conference:
Optional root property: vcalendar
While I am listing multiple events in this example, I consider these events as part of one calendar. As such, I do not need to include the vcalendar root property.
If, however, this example included multiple calendars (such as one per month), then I would include vcalendar and apply it to the relevant elements containing each month (<li>s in this case).
Required property: vevent
If you have more than one event, you need more than one vevent. Add it to the containing element for all of each event’s information, <li>s again in this case:
Because all of the events in this example are essentially the same (name, link, start and end times), I’m going to focus on just one of the events for the rest of the properties. Now it’s for more than the trees—my fingers are tired from typing.
Required property: summary
For each event name, I assign the summary property:
Optional property: url
I also indicate the website for the event by adding the url property to the <a>:
Required property: dtstart
I’m using the empty <span> value-title method of the value class pattern for my date-time information in this example because only time is visible to humans, but I still want the full date-time machine information:
Required property: dtend
And, because I like consistency within an implementation, I’m also using the empty <span> value-title method of the value class pattern for my end date-time:
The end result
A few properties and subproperties later, our code example is completely marked up with hCalendar:
The logic behind the markup
As you can see in this example, the outermost containing element is an ordered list, which contains the months (starting with September in this example). The days of the month are then nested within the <li>s as another ordered list. Can you guess why I used ordered lists? Yep, sequence. Gold star time!
Because each day features multiple events (two sessions each, one in the morning and one in the afternoon), each event is contained in an <li> of a nested <ul>. And because <li>s can contain block elements, I’m aiming for some SEO goodness with <h3>s on the names.
I definitely understand the argument that calendars naturally and semantically fit in an ordered list (due to its inherent sequential nature), which is why I included the last example.
But I also see a calendar as tabular data that would be well suited for a <table>.
Calendar using <table>
I’ll be the first to admit that I’m not a fan of <table>s—for layout.
In fact, I hate, abhor, and despise them almost as much as I hate, abhor, and despise IE 6. And frankly, I don’t think too highly of the “professionals” who choose to use them for layout.
But that is a discussion for a different day. The point is <table>s do have a place in web design—for tabular data like this calendar:
Optional root property: vcalendar
This example is a single month of events, which I consider to be part of a single calendar, so we will exclude the vcalendar root. If I had included multiple months, I would assign vcalendar to each month’s <table>. But I didn’t, so let’s move on.
Required property: vevent
Next we need to assign the required vevent to each event. In the last example, I contained event information in the <li>s of a nested <ul>. But in this example, I don’t really want the list element involved.
So I will drop in some nonsemantic <div>s to contain each event, and then assign vevent to each:
If the day of the month contained only a single event, rather than two, vevent could easily be assigned to the <td>.
As my fingers are tiring and trees everywhere are crying, I’m going to use just a single event to demonstrate the remaining properties.
Required property: summary
The summary property is added to the element containing the event name, in this example, the <a>:
Required property: dtstart
Can you tell which method I used for my dstart date-time information? Take a close look:
Notice the empty <span class="value-title">? Yeah, that’s the value-title subset of the value class pattern using a <span> containing a single space.
Oh, and you may notice I applied the dtstart property to the <dd>, rather than a <span> as I’ve done in previous examples. That’s because (1) dtstart can be applied to any element, and (2) I didn’t have a containing “hook” for the content in previous examples.
Because the <dd> serves as the container for my start time, it is the perfect element to assign dtstart. If you can avoid “spanitis,” please do so.
Optional property: url
I apply the url property to the link for the event’s website:
Optional property: status
I described the status property when I was covering syntax, but this is the first example in which I use it. So, as a reminder, status indicates whether an event is confirmed, cancelled, or tentative:
Because these status values often occur in natural language, they are case insensitive.
Optional property: class
Next, because my content includes the information about whether the event is public, private, or confidential, I add the class property:
The class values private, public, and confidential are also case insensitive.
Optional property: dtend
Lastly, I use the value class pattern with my dtend property:
The end result
And now our hCalendar <table> example is complete:
The logic behind the markup
Aside from the fact that I consider this calendar to be tabular data, another reason I like a <table> for this example is that if I wanted to style (via CSS) this content as a traditional calendar (you know, grid-like), then a <table> gives me a foundation for that structure.
If I were to use the nested <ol>s that I did in the first multiple-events example, there would be much more styling involved to result in a grid-type calendar. So when it comes to two different elements for which you could easily argue the semantic value, consider what may be required on the presentation level. That may help you make a decision.
hCalendar in natural language
While hCalendar is obviously well suited to a chunked presentation, as I’ve demonstrated in the previous examples, it works equally well in natural language. In fact, for my own blog I prefer natural-language hCalendar events. Here’s an example:
<p>Webuquerque's next presentation, <a href="http://
webuquerque.com/Events/Search-Engine-Optimization.php">
Search Engine Optimization</a> is July 1, 2009 from 6:30–
7:30 pm at Uptown Sports Bar and Grill.</p>
Required property: vevent
First I add the vevent property to the root element containing all of my event information—<p> in this example:
<p class="vevent">Webuquerque's next presentation,
<a href="http://webuquerque.com/Events/Search-Engine-
Optimization.php">Search Engine Optimization</a> is July 1,
2009 from 6:30–7:30 pm at Uptown Sports Bar and Grill.</p>
Required property: summary
Next I assign the summary property, which, as I’ve mentioned several times, is often the name of the event:
<p class="vevent">Webuquerque's next presentation,
<a href="http://webuquerque.com/Events/Search-Engine-
Optimization.php" class="summary">Search Engine
Optimization</a> is July 1, 2009 from 6:30–7:30 pm at Uptown
Sports Bar and Grill.</p>
In this example, my name content is contained by a site link, so I use the <a> as the hook for my summary property.
Required property: dtstart
For the event start time, I add the dtstart property and specify the date-time machine data using the value class pattern:
<p class="vevent">Webuquerque's next presentation, <a href=
"http://webuquerque.com/Events/Search-Engine-Optimization.
php" class="summary">Search Engine Optimization</a> is <span
class="dtstart"><span class="value-title" title="2009-07-
01T18:30:00">July 1, 2009 from 6:30</span></span>–7:30 pm at
Uptown Sports Bar and Grill.</p>
If I were concerned about browser tooltips (which display the title value of any element), I could’ve used the empty <span> technique for the value-title subset:
<span class="dtstart"><span class="value-title" title="2009-
07-01T18:30:00"> </span>July 1, 2009 from 6:30</span>
Tooltips not a concern? Or you happen to feel that separate date and time ISO 8601 values are more internationally appropriate? Then use the value class pattern with <abbr> to separately indicate date and time:
<span class="dtstart"><abbr class="value" title="2009-
07-01">July 1, 2009</abbr> from <abbr class="value"
title="18:30:00">6:30</abbr></span>
With this separated date and time information, machines know to combine the two <abbr> title values for the complete date-time information. Meanwhile, the resulting tooltips are much more human friendly.
I know I sound like a broken record, but you should avoid using the value class pattern with <abbr> for combined date-time information (known as the datetime design pattern, now deprecated) such as in this example:
<span class="dtstart"><abbr class="value" title="2009-07-
01T18:30:00">July 1, 2009 from 6:30</abbr></span>
Due to the readability and listenability issues with ISO 8601 date-times in the title attribute of <abbr> elements, such uses are discouraged.
Optional property: url
This example also includes a site link, so I add the url property to the <a>:
<p class="vevent">Webuquerque's next presentation, <a href=
"http://webuquerque.com/Events/Search-Engine-Optimization.
php" class="summary url">Search Engine Optimization</a> is
<span class="dtstart"><span class="value-title" title="2009-
07-01T18:30:00">July 1, 2009 from 6:30</span></span>-7:30 pm
at Uptown Sports Bar and Grill.</p>
Optional property: location
Once again, the location content in this example doesn’t already have an HTML container, so I assign the location property to a <span>.
<p class="vevent">Webuquerque's next presentation, <a href=
"http://webuquerque.com/Events/Search-Engine-Optimization.
php" class="summary url">Search Engine Optimization</a> is
<span class="dtstart"><span class="value-title" title="2009-
07-01T18:30:00">July 1, 2009 from 6:30</span></span>-7:30 pm
at <span class="location">Uptown Sports Bar and Grill
</span>.</p>
The end result
After adding those properties, our example is now an hCalendar:
<p class="vevent">Webuquerque's next presentation, <a href=
"http://webuquerque.com/Events/Search-Engine-Optimization.
php" class="summary url">Search Engine Optimization</a> is
<span class="dtstart"><span class="value-title" title="2009-
07-01T18:30:00">July 1, 2009 from 6:30</span></span>-7:30 pm
at <span class="location">Uptown Sports Bar and Grill
</span>.</p>
Combining hCalendar and hCard
As you may have noticed in these examples and across the web, hCalendar events often reference a location. And more often than not, this is a named place, which means it’s the perfect content for an hCard.
Required root property: vcard
Using the natural-language hCalendar example as a basis, let’s add an hCard for the location, starting with the root vcard property:
<p class="vevent">Webuquerque's next presentation, <a href=
"http://webuquerque.com/Events/Search-Engine-Optimization.
php" class="summary url">Search Engine Optimization</a> is
<span class="dtstart"><span class="value-title" title="2009-
07-01T18:30:00">July 1, 2009 from 6:30</span></span>–7:30
pm at <span class="location vcard">Uptown Sports Bar and
Grill</span>.</p>
My content was already contained by a <span> assigned the hCalendar location property, so I just add vcard to that.
Required properties: fn and org
If you remember, the only required properties for place hCards are fn and org:
<p class="vevent">Webuquerque's next presentation, <a href=
"http://webuquerque.com/Events/Search-Engine-Optimization.
php" class="summary url">Search Engine Optimization</a> is
<span class="dtstart"><span class="value-title" title="2009-
07-01T18:30:00">July 1, 2009 from 6:30</span></span>–7:30 pm
at <span class="location vcard"><span class="fn org">Uptown
Sports Bar and Grill</span></span>.</p>
The end result
With just a few extra elements and some classes, I’m giving my users not only a downloadable event for their calendars, but an electronic business card as well. And I could’ve included even more information for the hCard, without any problems. Content dictates what properties and subproperties you should use.
<p class="vevent">Webuquerque's next presentation, <a href=
"http://webuquerque.com/Events/Search-Engine-Optimization.
php" class="summary url">Search Engine Optimization</a> is
<span class="dtstart"><span class="value-title" title="2009-
07-01T18:30:00">July 1, 2009 from 6:30</span></span>–7:30 pm
at <span class="location vcard"><span class="fn org">Uptown
Sports Bar and Grill</span></span>.</p>
Authoring Tools
Want to be efficient with your hCalendar implementations? Then make use of these tools to help you create and validate hCalendar:
• hCalendar Creator: http://microformats.org/code/hcalendar/creator
• Conference Schedule Creator: http://dmitry.baranovskiy.com/work/csc/
• hCalendar Cheatsheet: http://microformats.org/wiki/hcalendar-cheatsheet
• Optimus Microformats Transformer (for validation): http://microformatique.com/optimus/
• For more hCalendar tools, see http://microformats.org/wiki/hcalendar-implementations
What’s Next?
The next microformat we’ll be covering, hResume, is used for resume/CV (curriculum vitae) content. While, like all microformats, it has its own properties and subproperties, you’ll be pleased to know that it leverages both the hCard and hCalendar microformats.
So not only will you learn a new microformat, you will also be practicing what you’ve already learned. Remember, folks: practice does, indeed, make a close approximation to perfect.