[uf-new] hAudio/table incompatibility (was: hAudio v0.7 released)
scott at makedatamakesense.com
Thu Oct 4 18:41:56 PDT 2007
On Oct 4, 2007, at 7:09 PM, Manu Sporny wrote:
> TRACK and HAUDIO can co-exist in the same CLASS attribute, but they
> 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
> is because we might have 'track hvideo' in the future for DVD
> 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  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?
More information about the microformats-new