<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.
_______________________________________________
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
