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
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
