3.12.8 dfn automatic cross-referencing

There is an algorithm proposed for automatically cross-referencing dfn
from other elements:
http://dev.w3.org/html5/spec/Overview.html#dfn

I would find this useful, however it will not work with the typical
way I handle abbreviations. I'm not alone, I went searching for some
more information and found this interesting thread that discusses many
use cases and alternative solutions for abbreviations in HTML:
http://www.webaim.org/discussion/mail_thread.php?thread=3359

I have altered the example from the spec to match how I would
currently author the abbreviation. (Habits can be changed, if there is
a compelling reason to do so.)

<p>The <dfn>Garage Door Opener (<abbr>GDO</abbr>)</dfn>
is a device that allows off-world teams to open the iris.</p>
<!-- ... later in the document: -->
<p>Teal'c activated his <abbr>GDO</abbr>
and so Hammond ordered the iris to be opened.</p>

Key differences: I would expand the acronym in the surrounding text
(not the title attribute). I would prefer to surround the expansion
and abbreviation with the <dfn> tags (that may just be a quirk of how
I interpret the semantics, but it is the same context as dfn@title). I
would not want to repeat the expansion again (not even in title
attributes) within the same document.

This is not going to work with the automatic cross referencing
algorithm. If anyone else thinks it's worth pursuing, perhaps we could
look at broadening the algorithm. I offer two suggestions:

SUGGESTION 1:
a. for any abbr (maybe other prose elements), if it is contained
within a dfn ancestor than that dfn comprises the definition
b. for any abbr (etc.) not contained within a dfn, find a matching
element (same tagName, same textContent) that is contained within a
dfn ancestor - let that be the definition.
(n.b. a @title attribute would take precedence over these steps).

This is fairly similar to the existing algorithm and will work with
the example. It is not the same though (the current algorithm would
find a matching dfn element without a nested abbr element).

-------------------------

SUGGESTION 2:
Another option I'd support (which has been proposed before) would be
using an idref relationship.

<p>The <dfn id="GDO">Garage Door Opener (<abbr>GDO</abbr>)</dfn>
is a device that allows off-world teams to open the iris.</p>
<!-- ... later in the document: -->
<p>Teal'c activated his <abbr idref="GDO">GDO</abbr>
and so Hammond ordered the iris to be opened.</p>

I've used @idref as an abstract name to illustrate the concept. I
would not mind @for if that isn't too much overloading.

-------------------------

Also note that the expansion may not be the first instance in the
document. Editorial discretion might be exercised to move "unsightly"
expansions from a heading to the following paragraph, for example.
(Let's not talk about the unfortunate situation when the abbreviation
occurs in the <title> element!) Just a point to note as it may affect
the complexity of implementing that algorithm (it may need to look
ahead for the definition).


I'd consider this a low priority, and that there are many other
possible techniques (see link at start of email). I'm pretty happy
with the idea of ignoring markup for abbreviations in most cases. UAs
have been getting better at providing options to lookup selected text
(it was never that hard to copy and paste into a search engine in the
first place).

I do think it would be useful for localised jargon though (where a
lookup to dictionary.com or wikipedia might lead you to the wrong
definition). Arguably it's better not to include that kind of jargon,
but it does crop up and anything that helps the user find a definition
existing within the same page would be excellent - I'd be keen to use
it in those scenarios. I think they are possibly the only
abbreviations I should attempt to explain anyway - far better to
lookup "HTML" online than read my paltry summary I'm certain!

If we're feeling courageous, some guidance on which abbreviations are
worth the markup would be great. Like the advice given on meaningful
titles (good precedent that!)

Received on Tuesday, 31 July 2007 14:25:18 UTC