[whatwg] microformats incompatible with WebApps 1.0 ?

Mon Dec 11 18:53:53 PST 2006

On Dec 11, 2006, at 6:25 PM, Ian Hickson wrote:
> On Mon, 11 Dec 2006, Michel Fortin wrote:
>> And since profiles can now be applied on individual elements,  
>> there's no
>> real need to keep the redundant "vcard" class name since it could  
>> easily
>> be implied by the profile being specified on that element:
>>
>>     <div profile="hcard">
>>      <a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
>>      <div class="org">Technorati</div>
>>     </div>
>>
>> How is that?
>
> It's one step away from:
>
>      <div class="vcard">
>       <a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
>       <div class="org">Technorati</div>
>      </div>
>
> ...which would work just as well, and has the added advantage that  
> it is
> compatible with how hCard is used today.

Indeed. Michel's proposal is equivalent to your example, Ian.

I think there's a middle way here that would work and maps to current  
practice. In our design of microformats, we make sure to do 2 things:

1. Use the same class name to mean the same thing, no matter what  
context. So, 'fn' is always a 'formatted name', no matter what  
microformat you're working with.

2. In the case of structured microformats (more than one value), we  
use a very rare term as a root class name. In the case of hCard, the  
root class name is 'vcard', which is rarely used in the wild for  
anything other than hCard. This greatly reduces the probability of  
collisions.

Now, if I were to register the class name 'vcard' for use with hCard,  
would I really need to register all of it's child properties, like  
'given-name' or 'family-name'? I don't think I should, because those  
only make sense when contained within an element with a class name of  
'vcard'. We have a flat namespace, but it's disambiguated by context.

So, here's a possible middle way:

Keep profiles, but ditch the profile attribute. Instead of  
registering class names, register *root* class names and map them to  
XMDP profile URLs and documents[1]. I believe this is essentially  
equivalent to today's practice, though better organized.

This means that community efforts like microformats.org can go ahead  
without interruption and that individual publishers can register  
their own root class names. For example, yahoo could register 'yahoo- 
com' then use this on all of their pages:

The first question is likely, "what if yahoo wants to use hCard?"  
Well, there's already plans to add the ability for one XMDP document  
to refer to another (this reminds me that I need to bug Tantek about  
that :D). So, Yahoo's XMDP document could point at the hCard XMDP  
document in order to make use of it on their website.

-ryan

1. http://www.gmpg.org/xmdp/