On 14 Dec 2007, at 14:06, Benjamin Hawkes-Lewis wrote:
I think all of the following would be misuses of ABBR and TITLE:
| Combien d'œufs ai-je vendre? J'ai vendu <abbr title="quarante-cinq">
| 45</abbr> aujourd'hui.
| Combien d'œufs ai-je vendre? J'ai vendu <abbr title="45
| œufs">45</abbr> aujourd'hui.
| Combien d'œufs ai-je vendre? J'ai vendu <abbr title="45
| eggs">45</abbr> aujourd'hui.
| Combien d'œufs ai-je vendre? J'ai vendu <abbr title="30+15">
| 45</abbr> aujourd'hui.
| Combien d'œufs ai-je vendre? J'ai vendu <abbr
| title="sales:a464Z37;q45dt2007122007">45</abbr>
| aujourd'hui.
"16:03" could be re-expressed as "3 minutes past 4pm". It's not
obvious that "16:03" is an /abbreviation/ of "3 minutes past 4pm".
For one thing, the 12-hour clock is not an expansion of the 24-hour
clock: they are equivalents. For another thing, I'd say it's more
of a common symbolic representation. "4" wouldn't normally be
called an abbreviation of "four": it's just a symbol. (Some symbols
are also arguably abbreviations, at least in origin, like cm, but
this wouldn't generally be said of 4.)
Agreed. I'll repost something I put into the GEO thread last week.
It's quoting directly from the HTML4 specification. This doesn't
actually need to have any concern with accessibility, or assistive
technology tools. Frankly, the difficulty in getting solid tests from
such tools makes that line of argument less attractive in itself. But
what has to be a fundamental baseline in our implementation of
optimisation patterns in microformats is the HTML specification we
are building on top of. We *do not* have the authority to disobey the
spec. We may interpret it _more strictly_ perhaps, but we may not
_relax_ any of the definitions it provides. Otherwise we have no leg
to stand on regarding the effect our code has on _any_ consuming tool.
I said this:
> “The content of the ABBR and ACRONYM elements specifies the
abbreviated expression itself, as it
> would normally appear in running text. The title attribute of
these elements may be used to provide
> the full or expanded form of the expression.”
For emphasis again:
> “as it would normally appear in running text.”
I know there are lots of concerns about the effect of the ABBR
pattern on assistive technology tools. I know there are reports of
problems and negative impact on user experience. Getting evidence is
proving hard because the sheer number of variables in a real
assistive technology user's configuration is much larger than for
visual desktop browsers. It actually doesn't matter, because the ABBR
pattern is being mis-used at a more fundamental level.
First, some happy news. Here's the ABBR pattern being used validly
and correctly in hCard:
<abbr class="country" title="United Kingdom">UK</abbr>
There is an argument that the ISO timestamp format is an expansion
of a human formatted date (‘Thursday, September 23rd’). I personally
disagree, but it was accepted at the time. But since then, the use of
the pattern has expanded without the same concern for the HTML spec.
‘One hour ago’ is NOT ever an abbreviation of a timestamp. ‘last
week’ IS NOT an abbreviation of a timestamp. ‘London’ IS NOT an
abbreviation of a set of co-ordinates and ‘3:23’ IS NOT an
abbreviation of the string ‘PT3M23S’ (hAudio). In all of those cases
they are ‘alternative representations’, or ‘expansions’ or perhaps
‘precisions’. They ARE NOT abbreviations and they are in clear
conflict with the HTML spec which states the TITLE attribute of ABBR
must be ‘the abbreviated expression itself, as it would normally
appear in running text’. Sorry, but the ball got dropped on this, and
people have been treating the ABBR-pattern as a handy pattern first
and HTML second. That is the wrong way around.
So we have a problem. We now have multiple use cases where it is
necessary for publishers to include precise machine data alongside
human legible descriptions. They are rarely real abbreviations.
I am going to ask that we better define the problem. That we follow
up the demand for a better pattern (regardless of whether your
personal motivation is following the spec or assistive technology).
I'd like to ask that people stop jumping straight in with ideas for
alternative mark-up, ways of kludging the existing practice into
different elements or attributes. Follow the process. We need to
fully define the problem: We need a list of which microformat
properties _require_ the facility for precise representations. They
don't all need it, maybe we just need something that certain
properties may opt into, rather than something that covers all
microformats properties. That's what we need to determine. From
there, we can move on how to integrate the data back into mark-up.
Thank you,
Ben
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
