[whatwg] [WA1] Markup for vCalendar and vCard

[Matthew Raymond]

Brad Neuberg wrote:
> Have you seen Tantek's work with hCalendar, which is basicly the iCal 
> standard translated into XHTML? It's very clean and seems like a nice 
> ancillary standard that could be included with WA:
> 
> http://developers.technorati.com/wiki/hCalendar
[Snip!]
> At 05:07 AM 2/18/2005, Matthew Raymond wrote:
[Snip!]
>>(http://developers.technorati.com/wiki/hCalendar):

    So, as you can see above, the answer to that question would be yes.

    There are several problems with hCalendar (and in turn, vCard):

1) There is no way for some reading the markup to tell if a class name
is the name of an attribute or simply the name of a class used for styling.

2) As a result of the above, user agents would not be able to reliably
allow users to access extension properties such as
"x-mozilla-alarm-default-length" (which is an actual extension used in
Sunbird).

3) Other than Ian's <calendar> addition, there's no actual semantic
markup for calendars or business cards.

4) What happens if I use a class inside <calendar> when I don't want the
element I use it on to be a property of the calendar? What happens if
the class is used both inside and outside <calendar>?

5) What do I do if I want to add styling to a group of calendar events,
especially if the calendar contains dynamic content? Styling a long list
of IDs through the use of dynamically generated CSS doesn't sound all
that appealing.

6) What do you do if you don't want the calendar or card to show up on
legacy user agents, or what if you don't want specific properties to
show up? hCalendar and hCard require you to use CSS to hide markup in
legacy user agents.

7) The use of <abbr> for dates is incorrect. "August 5th, 2004" is not
the abbreviation of 2004-09-05. In fact, the opposite is closer to the
truth. So, what would be a semantically correct method for storing
separate values for legacy UAs and WA1 UAs?

8) If we're going to use title for separation of content for differing
user agents, what happens when we want tooltips on certain items for
legacy user agents? For that matter, how do we use those tooltips on WA1
user agents?

9) What element is most appropriate in specific circumstances? Would the
use of <acronym> for DTSTART be just as good as <abbr>??? What happens
if a browser doesn't support either <acronym> or <abbr> with respect to
calendars?

    So, effectively, for hCard and hCalendar, you have to create a
complex set of rules for all possible uses of legacy markup within
<calendar> which can easily be implemented incorrectly, and even then
you still have styling and tooltip issues that are unresolved. By
contrast, my system had a clear separation between legacy markup and WA1
markup. My system also works on a simple set of rules that don't change
or overload any existing elements, and it does so without adding
complicated markup. Compare the following:

| <calendar>
|  <span class="vevent">
|   <a class="url" href="http://www.web2con.com/">
|    <abbr class="dtstart" title="20041005">October 5</abbr>-
|    <abbr class="dtend" title="20041007">7</abbr>
|    <span class="summary">Web 2.0 Conference</span>
|   </a>
|  </span>
| </calendar>

| <vcalendar>
|  <vevent>
|   <a href="http://www.web2con.com/">
|    <vattr name="url" value="http://www.web2con.com/"></vattr>
|    <vattr name="dtstart" value="20041005">October 5</vattr>-
|    <vattr name="dtend" value="20041007">7</vattr>
|    <vattr name="summary">Web 2.0 Conference</vattr>
|   </a>
|  </vevent>
| </vcalendar>

    They're very similar, but only the first overloads |class| and
|title|. Only the hCalendar example uses multiple elements to define
calendar properties. Granted, you save an element, but at the cost of
diluting the meaning of <a>.

    Not that I don't see the advantage and flexibility of the
hCard/hCalendar system. You can use multiple class names to declare
redundant attributes in a single element. You can also nest
calendar/card attributes. (Then again, you could theoretically do the
same with <vattr>.)

    The problem is that, for all the creative ways you can use
hCalendar/hCard, it's more complicated for webmasters to read and
understand and more complicated for developers to implement. 
Furthermore, I dislike the entire system of using class names as markup. 
Class names should be reserved for user-defined semantics.