Re: abbreviations in canonical HTML (thoughts & concrete suggestions)


 I too, would like to say that your post on "abbreviations in canonical
HTML" was well done. It certainly makes this post look bad in


 My apologies if my response becomes an unwanted tangent on the
subject, but the ideas Gregory expressed could address an issue I have
thoughts about.

 A bit of a prologue: As soon as I heard about microformats I started
reading the Microformats Blog ( After a
long time, I implemented a microformat for the first time, an hcard
example. However, there was something about it that bothered me. There
is a design pattern used by microformats
( called the
Abbr design pattern (
This design pattern sometimes uses the ABBR element to provide machine
readable information about a piece of human readable text. These two
pieces of info may have the same practical meaning, but not the same
literal expression. For example the ABBR element may contain the
longitude and latitude coordinates of a city while the text just
gives the name of the city.

Code Example:

<ABBR class="geo" title="44.7657;-63.6609">Halifax</ABBR>

 This concerned me, so I did some research and discovered that yes
indeed, this approach has accessibility issues. In my above example,
the city name, Halifax would be read as an abbreviation by a
screen reader in some case, while in every case it is just a regular

 An addition to the type (or possibly expressed-as) attribute Gregory
was describing for his proposed IABBR element could help this
situation. Perhaps with a better name, something like an "equivalence"
type could be added to the list of IABBR types. The equivalence type
would be used to indicate something that is the same as what is
described in the title attribute, but expressed differently.  In a way
that is what all acronyms are; "SOund Navigation And Ranging" and SONAR
are the exact same thing, with the same meaning and connotation, just
expressed differently.

 Now, I know you may be asking yourself, why should we add to the list
of possible type attributes, for just one thing (a microformat design
pattern) that bothered just one person (me). Well, I see doing this as
having flexibility and being helpful in many situations. The
abbr-design-pattern lead me to this place in my mind, but is not the
defining reason or need behind it.

 As an example of another usage of this idea of equivalence, imagine a
web page used by aviation professionals describing origins and
destinations. Every airport has a three letter code used to identify it
(four letter codes also exist but my example will use three). The ABBR
or IABBR element with the right attribute could be used to provide the
code in a non-intrusive way.


<P>Flights arriving in <IABBR type="equavilance"
title="HAV">Havana</IABBR> are required to be bug sprayed, even if
arriving from colder climates such as the ones found in <IABBR
type="equavilance" title="HEL">Helsinki</IABBR> and <IABBR
type="equavilance" title="YHZ">Halifax</IABBR>.

 With this example the paragraph is machine readable in a way that
extracts airport codes from the page, something useful for other
aviation systems. Doing the same in reverse could be helpful in some

<P>...this applies to all flights arriving in <IABBR
type="equavilance" expressed-as="characters"

 If a user agent choose to give options on how it
displays/not-displays/allows-access-to the title information from those
examples, it could be even more useful.

 I wish I could think of more concrete examples right now. (As
someone who works at an aiport though, I can assure you that the
above examples could be very helpfull for internal web pages.)
Regardless, I think that the best use of this would be discovered as it
got used in the wild. Embedding information into the source code that
is the factual equivalent of another piece of information, but
expressed differently, could have great potential.

Received on Wednesday, 11 April 2007 00:56:34 UTC