[uf-new] hAudio/table incompatibility

[Manu Sporny]

Scott Reynen wrote:
>> The only reason I mention that order is important in the attribute list
>> is because we might have 'track hvideo' in the future for DVD chapters,
>> television episodes or other track-like items.
> 
> I'm not sure l understand that reason.  If you're saying that a
> class="track haudio" should carry the same meaning as a class="haudio"
> inside a class="track", I think that's a bad idea.  It discards useful
> HTML container semantics and introduces container semantics to the class
> attribute where none have existed previously.
> 
> But I also don't understand why we were ever treating those as separate
> elements.  It seems to me we're not talking about a track that
> *contains* audio, but rather a track that *is* audio.  If that's the
> case, why wouldn't they belong in the same element?  

Yes, I agree. We are talking about a track that *is* audio. Based on
that suggestion, perhaps we can change the rules for processing TRACK to
be even more publisher-friendly.

PROPOSAL:

TRACK can be either plain text or marked up using HAUDIO.

This approach would make the following markup valid:

<div class="haudio">
...
  <span class="album">Album Title</span>
...
  <span class="track">Song Name</span>
...
</div>

the following would also be valid:

<div class="haudio">
...
   <table>
    <tr><th>#</th><th>Track</th><th>Length</th></tr>
    <tr class="track haudio">
        <td>1.</td>
        <td class="recording">Sanity</td>
        <td><abbr class="duration" title="P348S">5:48</abbr></td>
    </tr>
    <tr class="haudio track">
        <td>2.</td>
        <td class="recording">Highway To Hell</td>
        <td><abbr class="duration" title="P219S">3:39</abbr></td>
    </tr>
   </table>
...
</div>

These issues have been noted in hAudio ISSUE #11 and ISSUE #12:

http://microformats.org/wiki/audio-info-issues#Problem:_TRACK_does_not_work_in_tables

http://microformats.org/wiki/audio-info-issues#Problem:_CONTRIBUTOR_and_TRACK_are_not_publisher_friendly

> On a similar topic,
> why does the contributor description say "The contents of the element
> must *include* a valid hCard Microformat" rather than "The element must
> *be* a valid hCard Microformat" (emphasis added)?  In hCalender [1] we
> say "ATTENDEE, CONTACT, and ORGANIZER in iCalendar may be represented by
> an hCard in hCalendar."  So we use class="organizer hcard" (or
> class="hcard organizer") because the organizer is exactly the same
> entity as the hcard.  Why should contributor work differently?

It shouldn't work differently from hCalendar, and I agree again. We
should bring hAudio more in line with hCalendar. Do the following two
examples work for everybody?

This would be valid:

   <span class="contributor vcard">
         <span class="fn org">Phish</span>
   </span>

and so would this:

   <span class="contributor">Phish</span>

This has been noted in hAudio ISSUE #12:

http://microformats.org/wiki/audio-info-issues#Problem:_CONTRIBUTOR_and_TRACK_are_not_publisher_friendly

-- manu