[uf-discuss] Authoritative hCards [was RE: Canonical hCards

[Derrick Lyndon Pallas]

John Allsopp wrote:
>
> I wonder whether that makes sense more generally - things apply at the 
> finest level of granularity at which it mkes sense - so rel="bookmark 
> self" applies to the microformatted content it is most directly 
> descended from.
> Are there reasons people think this is a bad idea?
>
> "where a feature of microformats may apply to more than one element in 
> a descendent tree, it is associated with the element which most 
> directly contains it ."

Personally, I think this is a bad idea; I was actually talking with Ben 
West at work today about this very issue. For the sake of argument, say 
hFoo --- which I decide to implement --- can contain rel-tag without 
marking it in any other way. Now a new format, hBar, comes along and it 
may contain rel-tag without marking it in any way; maybe I don't know 
about hBar, don't care about hBar, or don't want to implement hBar. What 
if my hFoo contains an hBar? In that case,

  <div class="hFoo">
    <span class="hBar">
      <a href="http://examples.com/tag/myTag" rel="tag">Text</a>
    </span>
  </div>

causes a problem (given the suggestion above) because the rel-tag should 
only apply to hBar but without the hFoo parser knowing about hBar (which 
may be unreasonable) it will grab the rel-tag as well. A better solution 
is what hCard does; from what I understand, using rel-tag with category 
still requires you to say @class="category". This, incidentally, can 
cause a name-space problem: it means that to keep hBar and hFoo 
unambiguous, one needs to define slightly different rel-tag properties 
for each.

There are two simple solutions: make features only apply to the element 
in which they exist (which makes them non-features) or let features 
apply to any format that can grok the feature, ignoring containers. 
There are three complex solutions: use name-spaces for disambiguation, 
use other naming triks to figure out which feature apply to which 
container (this could get messy quickly), or require parsers for one 
format to know about all other top level containers (which seems bad for 
compatibility).

~D