On Nov 3, 2007, at 10:14 PM, Martin McEvoy wrote:
You were a solid supporter of using "audio-title" and helped make the
decision NOT to use FN
That's not true. I think you have the order of events confused.
"...We can't both re-use property names and ignore
the context of those property names. My dog's FN is not my FN, and
if the only way for me to make that clear is to use class="pet-name"
instead of FN, that's what will happen."
http://microformats.org/discuss/mail/microformats-new/2007-June/000581.html
?
What changed your mind ?, this was the statement that made us
support the use of "audio-title"
Nothing changed my mind. I was not at all arguing against FN there,
rather for the awareness of context that is necessary to use FN with
embedded microformats. And I was arguing for that *after* FN was
already discarded, because I thought it was unfortunate we had
discarded FN rather than solving the context problem.
Right now the necessary context is explicitly written into hAudio ITEM
("The element must be processed opaquely"). It still doesn't exist in
other microformats, but the general consensus (arrived at on the -dev
list despite my protest that it's more than a parsing issue) was that
we shouldn't address this until it becomes a more widespread (and thus
better documented) problem. Maybe it will never become a bigger
problem, or maybe hAudio will force the issue. Either way, I'm for
solving this problem with more explicit context rather than inventing
new synonymous class names (e.g. audio-title) as a means of working
around it.
--
Scott Reynen
MakeDataMakeSense.com
_______________________________________________
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
