[uf-new] hAudio/table incompatibility

[Julian Stahnke]

> <div class="haudio">
>     <h3 class="album">my album title</h3>
>     by <strong class="contributor">the artist</strong>
>     <ol>
>         <li class="track">my track title</li>
>         <li class="track">my track title</li>
>         <li class="track">my track title</li>
>     </ol>
> </div>
>
> <div class="haudio">
>     <h3 class="album">3 live bands at my local venue</h3>
>     by <strong class="contributor">various artists</strong>
>     <ol>
>         <li class="track">
>            <span class="recording">first track title</a> by
>            <span class="contributor">first artist</span>
>         </li>
>         <li class="track">
>            <span class="recording">second track title</a> by
>            <span class="contributor">second artist</span>
>         </li>
>         <li class="track">
>            <span class="recording">third track title</a> by
>            <span class="contributor">third artist</span>
>         </li>
>     </ol>
> </div>

I think that, if you want to use hAudio properties inside a track, it  
actually must be an hAudio element. It must not be an hAudio element  
if you *only* want to use plain-text. Same for contributor with  
regards to hCard. Would seem most sensible to me.

>> Even though the tracks aren’t marked up as hAudio element and hence
>> have no ‘position’ attribute, should ‘position’ be implied by the
>> position of the track in the <ol>?
>
> My thoughts are that it should be... but with the ability to override
> the <li> numbering scheme. What happens if somebody only wants to  
> list 3
> of the items in the album... song 3, 5, and 8?

In that case, one would either use an unordered list (and have no  
numbering) or just use a full-blown haudio element and specify the  
position via the position property as that would *always* override  
any implied formatting. Implied formatting should accommodate for the  
most common use cases and be kept simple, I think.

It’s the same with implied fn formatting. It works fine in most  
cases, and if one wants something more fancy, one just uses given- 
name and family-name etc.

Note the use of haudio on the <li>s, I’m using properties of haudio  
instead of plain-text, so a new nested haudio element should be  
required imho.

That would result in the following mark-up:

<div class="haudio">
     <h3 class="album">3 live bands at my local venue</h3>
     by <strong class="contributor">various artists</strong>
     <ul>
         <li class="track haudio">
            <span class="position">1</span>
            <span class="recording">first track title</a> by
            <span class="contributor">first artist</span>
         </li>
         <li class="track haudio">
            <span class="position">4</span>
            <span class="recording">second track title</a> by
            <span class="contributor">second artist</span>
         </li>
         <li class="track haudio">
            <span class="position">8</span>
            <span class="recording">third track title</a> by
            <span class="contributor">third artist</span>
         </li>
     </ul>
</div>

Your example brings up something new; the various artist album case.  
 From common sense I’d say one should be able to omit the contributor  
in that case. The parser then should assume it is a various artist  
album and either say ‘various artists’ (less colloquial,  
obviously ;)) and/or, if available, construct it from the  
contributors in the ‘track haudio’ elements. The decision about what  
to do/display would then be in the hands of the person using the  
parser for his specific project.

I’m aware though that this leads to a dangerous path of assumptions  
and implications. It may be common sense and thus not very  
complicated for *me*—but someone else may think differently. Then  
again, it *really* makes sense to me. But I think we really need some  
more opinions on this case.

>> PODCAST is disputed by Martin and since I'm the only person that is
>> backing it based on the examples, it will probably be dropped unless
>> somebody else wants to see the ability to mark up PODCASTs via  
>> hAudio.
>
> That's assuming those who don't want a podcast class don't want to  
> be able to markup podcasts, which in my case is a false  
> assumption.  I don't want a podcast class because I think we can  
> markup podcasts without it.  Specifically, hAtom + hAudio = a  
> podcast.  If you see something missing there, please clarify what  
> exactly.

I haven’t given that case a lot of thinking, but I really like that  
solution. It even mirrors the technical definition of a podcast and  
makes it digestible by the whole toolchain I image one would want to  
use on it.