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</ab
br>
> | 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. ‘bond’ 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
microformats-discuss microformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss
|
