[whatwg] microformats incompatible with WebApps 1.0 ?
ryan at theryanking.com
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
>> 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>
>> 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>
> ...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
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. 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.
More information about the whatwg