Hello Scott I have been thinking recently that it is perhaps best
to use
something that everyone is familiar with *FN* but I thought that it
would be simpler just to use *track* to imply type and title I also
don't think it is best practice to embed haudios *inside* haudio, I
think of it like a hfeed element in hAtom or the Channel element in
RSS,
also would you embed hfeed's inside other hfeed's?
David Janes made some good proposal back in November about a hTing uF
http://microformats.org/discuss/mail/microformats-discuss/2006-
November/007139.html
which eventually turned into a hItem design pattern/uF proposed by
Andy
Mabbett
http://microformats.org/discuss/mail/microformats-discuss/2006-
November/007281.html
there is a brainstorm about the hItem uf/item design pattern
http://microformats.org/wiki/items-brainstorming
So I thought simple solution
<div class="haudio">
<span class="album">Best Before 1984</span>
<span class="contributor">Crass</span>
<div class="item">
<span class="track">Nagasaki Nightmare</span>
<abbr class="duration" title="P268T">4:46</abbr>
</div>
<div class="item">
<span class="track">Big A, Little A </span>
<abbr class="duration" title="P368T"> 6:13</abbr>
</div>
</div>
</div>
Elegant I would say?
It solves the problem of do we use FN audio-title, whatever...
We have established that we cant use FN because want to describe
something MORE specific
http://microformats.org/discuss/mail/microformats-new/2007-May/
000355.html
http://microformats.org/discuss/mail/microformats-new/2007-May/
000357.html
I understand Tantek’s position to be in favour of using ‘fn’ and
against inventing a new property. Also, I talked to him a couple of
days ago and he made that point again. I myself kinda thought fn was
more or less specific to people and meant ‘full name’ instead of
‘formatted name’.[1] Shame on me.
Specific to the hAudio microformat, I’d still love to use audio-title
and album-title or similar names as they make for mark-up that is
wonderfully readable by anyone. Yet, in the greater scheme of things,
I guess it’s better to be pragmatic and re-use as many properties
from other microformats as possible. He really has a point there.
And also we dont need to use either FN or audio-title because
track I understand has to have the exact semantic value as album
The example above shows how to clearly define both track and album
In the example above, I’d use fn in the item instead of track.
Anyhow, I’m more in favour of Scott’s approach. I wonder though if we
could maybe use item instead of track somehow, as it is used in other
microformats already (mentioned here: http://microformats.org/wiki/
item#3._As_a_composite). Works great for
Album with a couple of tracks, more detailed:
<span class="haudio">
<span class="fn album">Best Before 1984</span>
<span class="contributor">Crass</span>
<span class="item haudio"><span class="fn">Nagasaki Nightmare</
span> – <abbr class="duration" title="P268T">4:46</abbr></span>
<span class="item haudio"><span class="fn">Nagasaki Nightmare</
span> – <abbr class="duration" title="P268T">4:46</abbr></span>
<span class="item haudio"><span class="fn">Nagasaki Nightmare</
span> – <abbr class="duration" title="P268T">4:46</abbr></span>
</span>
The problem with that obviously is the missing possibility of the
‘album with a couple of tracks, simple example’ variant:
<span class="haudio">
<span class="fn album">Best Before 1984</span>
<span class="contributor">Crass</span>
<span class="item">Nagasaki Nightmare</span>
<span class="item">Nagasaki Nightmare</span>
<span class="item">Nagasaki Nightmare</span>
</span>
That looks a bit wrong. The question really is if we need this. I’d
very much like to have that possibility. Maybe someone has an idea
about how to deal with it?
[1] That’s mentioned neither in the cheatsheet nor on the main hcard
page nor on the singular properties page. Found it in the FAQ,
eventually. I think it should be mentioned in the explanation of the
property as well, though. Anyone opposed to adding it there: http://
microformats.org/wiki/hcard-singular-properties#fn ?
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
