[uf-new] Proposal: change haudio title to htitle.
martin at weborganics.co.uk
Thu Aug 14 04:22:07 PDT 2008
Hello Scott, Toby...
Scott Reynen wrote:
> On [Aug 13], at [ Aug 13] 2:19 , Toby A Inkster wrote:
>> In my experience, from a practical point of view, it's not really
>> needed - even if no microformats had any property names in common,
>> parsers still need to take care over microformat opacity due to
>> situations like:
>> <div class="vcard">
>> <div class="agent vcard">
> I don't think that's a similar situation at all. hCard parsers must
> know how to handle embedded agent hCards, because it's part of the
> hCard spec. On the other hand, hCard parsers not only don't need to
> know how to handle embedded hAudio, but in many cases they couldn't
> possibly know because they were written before hAudio even existed.
>> And it doesn't seem to have proved a problem for 'url', which is
>> defined fairly differently in RFC 2426 (vCard) and RFC 2445 (iCalendar).
> Untrue. Here are two documented real world examples (or rather two
> sites with thousands of examples) of exactly this problem:
>> This seems to be a solution to a problem which doesn't exist.
> Again, untrue. There are more examples on the MFO page. If it's a
> rare problem, that's because it only comes up when microformats are
> used in high density. Rather than being edge cases, these cases are
> the core of what we're trying to do with microformats. We're trying
> to encourage descriptive markup, and it's the sites with the most
> descriptive markup where existing parsing rules leave ambiguity.
Is the "item" property in haudio MFO?
*The element /MUST/ be processed opaquely. No sub-elements should be
read from any hAudio contained in a track element.
... or am I misunderstanding the "microformat object(opaque)" problem.
> Scott Reynen
> microformats-new mailing list
> microformats-new at microformats.org
More information about the microformats-new