[uf-new] hAudio ISSUE #4: Display values for rel-patterns

[Brian Suda]

On 8/17/07, Martin McEvoy <martin at weborganics.co.uk> wrote:
> >    <a rel="purchase" href="/buy/song/3742827384"
> >       title="Buy The Song">
> >      <img src="/images/buy_song.png" alt="Buy Song Image" />
> >    </a>
> >
> > What value do you use for displaying the previous markup?
> >
> > - Buy The Song
> > - Buy Song Image
> > - or the image, /images/buy_song.png
> >

none of the above.

I would let the parsing application choose the value it best things
fit. We are discussing accessibility alot. If we force parsers to use
the @title or @alt, then you could run into the problem of accessility
of many ´a´ elements that say ´read more´ 25 times on a page, you will
have ´buy now´ 25 time... buy what?

I agree with Scott, let the parser choose. In some situations, if you
have drilled down through a track, it might just want to say ´buy
this´ or ´buy now´ but if you get just a list of links, then it makes
more sense to say ´buy the album called 123xyz for $9.99´ (which might
not be the @title at all, but a combination of various properties).
Not to mention the ability localize the ´buy now´ string to various
languages, but forcing a parser to use something specific in all cases
IMHO is a bad idea. This also allows parses to choose text in a
scenario when NO values could be extracted. The spec doesn´t need to
address every last possible edge case - if it did it would NEVER be
finished. We just need to attiquitely demonstrate that there is enough
information that parsers can act on and give them guidance to make
their own logical decisions.

If we want a ´best practices section´ i would rather it called
´examples´ and show various possible scenarios. What we think is a
best practice today, we might find in 6 months is completely
incorrect. We can always add more/less examples as times change.

We should NOT let GUI design make the choices about data formats. GUIs
come and go, designing for something specific NOW might not be what is
used tomorrow.

> > Use TITLE for display values for rel-patterns, which is backed up by
 the following: http://microformats.org/wiki/rel-payment#RelPayment

The danger here, is that RelPayment is nothing more than a draft that
has not seen a proper edit since November 5th 2006, to cite it as fact
is premature. I would argue that it is actually incorrect. For many of
the same reasons i believe it is incorrect for this spec to specify
exactly how to extract semantics of a TITLE based on the REL which has
nothing to do with TITLEs.

I say, that the spec does NOT need to say anything explicitly. Leave
it up to parsers to decide how to extract the label and add a variety
of different examples to the wiki to demonstrate all the different
options. I would image there is no 1 best way to actually recommend a
title, it will all be about content in the GUI, which is something we
can not and should not control.

This should be for ALL microformats using REL values. XFN has been in
existence for several years now, and no one has complained, asked or
worried about these things. I would say that demonstrates that the
converting applications are confident enough to figure it out simply
through the use of a few examples, how to extract a title if needed.
The spec can (and in existing cases, does) remain silent on this
issue.

-brian

-- 
brian suda
http://suda.co.uk