[whatwg] Conformance criteria for hCard and hCalendar

[Matthew Raymond]

Ian Hickson wrote:
> On Mon, 22 May 2006, Matthew Raymond wrote:
>> Will there be a <resume> element for hResume[1]?
>> How about a <review> element for hReview[2]?
> 
> It certainly isn't my intention to add such elements so far, as I've heard 
> nobody asking for them. Do you think they would be useful? They seem a bit 
> specific. HTML just represents documents (for some definition of 
> "document" that includes "application", at this point), it doesn't have 
> the ability natively to say "this is a letter", "this is a resume", "this 
> is a review", etc. I don't think we really want to go there.

   True, these two standards are more oriented to user agents like
search engines and the like, which is what the |class| attribute it
intended for. They're far less useful on a browser.

>> Exactly where does this end?
> 
> Wherever we want it to end. In general we want to aim for the 80% case, I 
> think. Your implied suggestion seems to be that vCard and iCalendar are 
> not in the 80% case. That's certainly possible.

   I'm implying that HTML may eventually be bloated with elements tied
to specific microformats. I'm of the opinion that anything important
enough for HTML markup is important enough for a complete set of
elements. Imagine <table> using a microformat:

| <table>
|   <div class="tr">
|     <div class="th">COL1</div>
|     <div class="th" title="colspan 2">COL2</div>
|   </div>
|   <div class="tr">
|     <div class="td" title="rowspan 2">Cell A1</div>
|     <div class="td" title="colspan 2">Cell A2</div>
|   </div>
| </table>

>> 1) When using XHTML, is there any benefit the <card> and <calendar> 
>> elements plus hCard and hCalendar would give over something like RDF 
>> vCard[3]?
> 
> It's hard to see any benefit that using hCard and hCalendar _wouldn't_ 
> give over using RDF. :-)

   Your comment does little to help me understand problems that arise
from the RDF vCard spec. My impression of the W3C Note is that the
vCard-specific markup could potentially be used separately from the RDF
markup. It's not RDF I'm asking about. It's the use of XML to encode the
card and calendar data when using XHTML. Here's another example:

http://xml.coverpages.org/draft-ietf-calsch-many-xcal-02.txt

>> 2) What standards bodies control hCard and hCalendar?
> 
> microformats.org is the closest to a standards body that currently 
> controls those specs. But I assume you knew that, so I'm not sure what 
> you're really asking here.

   My point is that WHATWG has enough credibility problems as a
standards organization without depending on groups with even less
standards credibility.

>> 3) If we're going to create markup to essentially "bind" microformats, 
>> why not have more general elements for this purpose rather than two 
>> elements that target specific microformats?
> 
> I'm not sure what more general element you would need, given that 
> microformats are doing quite fine without anything more than HTML4 
> provides.

   Well, microformats are so flexible that it would probably be
difficult to work up general elements anyways.

> Note that <card> and <calendar> weren't originally intended to "bind" to 
> microformats, but to whole-sale import the syntax of hCard and hCalendar. 
> It's not clear whether we'll be able to do that, given the quality of the 
> hCard and hCalendar specs right now.

   User agents can simply look for |class="vcard"| and |class="vevent"|
if they want to use these microformats. (There's nothing that says a
browser can't provide functionality based on class names.) Otherwise, if
we need element-level support for this, I would suggest my previously
suggested system:

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003111.html
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html

   As far as I can tell, hCalendar uses "vevent" as a root rather than
"vcalendar", so we may want to just drop the <vcalendar> element if no
one sees a use case. It would be useful for creating groups of events,
but if people need that, they could probably just download an iCalendar
file.

>> 4) It's beginning to look like microformats are just a way of getting 
>> around HTML's own lack of namespace support. Are standardized 
>> microformats really any better than the HTML namespaces Internet 
>> Explorer introduced?
> 
> Namespaces using prefixes as in XMLNS really aren't well understood by 
> authors. I'm not sure adding namespace support would be a good move.

   I'll bet that anyone who knows how to properly use multiple
microformats in the same HTML document can learn namespaces. This is
especially true for people from a .NET and Java development backgrounds,
where you can't get away from namespaces if your life depended on it.

   And, generally, microformats aren't any easier to use than
namespaces, assuming you understand what both conceptually. Consider this:

 * For microformats, you need to include a |profile| attribute on the
   <head> element. For namespaces, you need to define |[abbr]:xmlns| on
   the <html> element.

 * Every element that uses the namespace has to be prefixed by the
   namespace abbreviation. Every element that uses a microformat must
   include a class whose name is unique to all microformats used in
   the page.

 * Microformat that depend on the underlying semantics of HTML elements
   must define how each class interacts with the semantics of each
   possible element in that class. An element in a namespace has its own
   semantics, so dependencies are eliminated.

   I do have to admit that microformats have better fallback on non-IE
browsers, though, and that's something to consider.

> I'm also not sure why you think microformats have anything to do with 
> namespaces.

   They're two different ways of solving the same problem. Microformats
are better for providing simple metadata, but when you have to start
putting in <span title=""> elements to hide the |title| attribute on the
<abbr> element that you used to store the ISO date, you really begin to
wonder if a straight element wouldn't be better. Compare:

Namespace:
| <ical:dtstart value="20041005">October 5, 2004</ical:dtstart>

Microformat:
| <span title="">
|    <abbr class="dstart" title="20041005">October 5, 2004</abbr>
| </span>

> You still need a central authority (or two, or three) to make 
> sure that everyone speaks the same language.

   That's going to be the case for any standard. However, unknown
elements are ignored in HTML, so as long as the namespaces contain
elements that can provide good HTML-based fallback then there isn't a
problem. I understand that there is a risk that people may start using
elements from namespaces without providing needed fallback, but using
XBL you have the exact same dilemma with microformats.

   To be honest, though, I'm not sure I'm happy with the idea of
namespaces in HTML. My concern is that it would result in the
"HTMLization" of XML-based markup and slow or stop migration to XHTML.
For cards and calendar events, I prefer an HTML markup-based solution.