[uf-new] hAudio/table incompatibility (was: hAudio v0.7 released)

[Scott Reynen]

On Oct 4, 2007, at 7:09 PM, Manu Sporny wrote:

> PROPOSAL:
>
> TRACK and HAUDIO can co-exist in the same CLASS attribute, but they  
> must
> be specified in that order. It is the hAudio parsers job to detect the
> co-existence of these two properties and act accordingly.

[...]

> 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?  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?

[1] http://microformats.org/wiki/hcalendar#More_Semantic_Equivalents

--
Scott Reynen
MakeDataMakeSense.com