Re: [uf-new] [hAudio] fn _or_ album

[Scott Reynen]

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