[uf-new] Closing several hAudio issues

Manu Sporny msporny at digitalbazaar.com
Mon Oct 8 20:33:47 PDT 2007


Julian Stahnke wrote:
>> Martin McEvoy wrote:
>> I think the proposition should simply say
>>
>>       * "hAudio MAY have zero or more tracks"
>>       * "Track titles MAY be defined by using the class name
>>         *audio-title* it is recommended that a hAudio track SHOULD have
>>         an audio-title" *
>>
>> This would enable Greater flexibility when publishing hAudio.
> 
> as long as audio-title is present in the haudio element, it
> would be a track.

This is correct... as long as audio-title is present in the hAudio
element, it is semantically indistinguishable from a "track". The
processing rules have been updated to make this more clear:

http://microformats.org/wiki/audio-info-proposal#More_Semantic_Equivalents

> If only album-title was present, it would be an album.
> 
> If both audio-title and album-title were present, it would be a single
> track from an album.

Also correct.

The benefit with the current hAudio proposal is that you don't need to
specify TRACK to identify the hAudio as a singular item... all you have
to do is specify AUDIO-TITLE. It's easier on publishers because there is
less HTML to write (you don't have to specify TRACK for individual
recordings).

To address your other concern, Martin, we might not have to specify
"track haudio". Instead, we could have:

 <div class="haudio">
  <div class="track">
    <span class="audio-title">Nagasaki Nightmare</span>
    <abbr class="duration" title="P268T">4:46</abbr>
  </div>
  and
  <span class="track">Bloody Revolution</span>
  taken from <span class="album-title">Best Before 1984</span>
  By <span class="contributor">Crass</span>
 </div>

I have to admit, though, that the above mark-up just doesn't sit well
with me. We have to assume that properties inside of TRACK are of type
hAudio and can use any of it's properties. In other words, we are
assuming the type of the contents of TRACK is an hAudio based on the
parent container, which is hAudio.

Perhaps others that have been involved with Microformats for longer than
I have been can point out the benefits or drawbacks of such an approach.

Here are the ones that I can see:

Pros:

* Less mark-up for publishers.
* Less confusing?

Cons:

* The type must be assumed from the parent container type.

-- manu


More information about the microformats-new mailing list