W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2005

[whatwg] web-apps - dfn jumps

From: Matthew Thomas <mpt@myrealbox.com>
Date: Mon, 28 Nov 2005 20:26:29 -0500
Message-ID: <242f6d9ef7b1214f36856debe7565b98@myrealbox.com>
On 7 Nov, 2005, at 11:20 AM, Sander Tekelenburg wrote:
>
> <http://www.whatwg.org/specs/web-apps/current-work/#dfn0>
> ...
> The spec needs to indicate to UA developers that users should easily 
> be able to 'jump' back, instead of just getting lost. This would 
> require too many words. Thus, I propose to scrap the word "jump" 
> entirely. (After all, a possible implementation would be tooltips, in 
> which case there is no jumping at all.)

Tooltips probably wouldn't be a viable implementation, because of a 
long-standing and probably unsolvable problem with <dfn>: there is no 
programmatic way of telling where the definition begins and ends. Is it 
the current clause? The current sentence? (Dotted initialisms make even 
sentences impossible for a computer to demarcate reliably.) Two 
sentences? The whole paragraph? Two paragraphs? In many school 
textbooks you could probably find examples of all of these.

The reason I say the problem is probably unsolvable is that, while a 
<def> or similar ancestor element could be introduced to mark the full 
definition (for example, "<def>the American term for a crotchet is a 
<dfn>quarter note</dfn></def>"), authors wouldn't bother using it 
because they wouldn't get any presentational benefit from it. (The 
benefit of providing accurate tooltip boundaries probably wouldn't be 
obvious enough.)

So I'd expect <dfn> navigation, if it was implemented at all, to work 
just the same as navigation to internal anchors in the same document 
does currently: functioning as a jump, with the Back button returning 
to where you were.

> ...
> Already better would be:
>
> 	[...] should be presented in such a way that the user can easily
> 	access the first dfn element giving the defining instance of that
> 	term.
>
> I'd prefer something even more explicit, like
>
> 	[...] should be presented in such a way that the user can easily
> 	access the first dfn element giving the defining instance of that
> 	term, without risking the user can't find his way back.
>
> but I'm not entirely happy with this phrasing. I'm thinking of 
> something like "[...] easily access within the current view of the 
> document [...]" or "[...] easily access without losing the current 
> position in the document [...]", but given that the sentence already 
> is so long, I don't see how to cram this in :)
> ...

How about this:

     The _dfn_ element allows automatic cross-references. From any
     inline-level element that refers to a _dfn_ element, user agents
     should make it easy to access the definition provided by that
     _dfn_ element without losing one's previous place in the
     document. An inline-level element can be considered to refer to
     a _dfn_ element in the same document if (a) the inline-level
     element has no _dfn_ or interactive elements as ancestors or
     descendants, and (b) either its _title_ is equal to the _term_ of
     the dfn element or it has no _title_ but its _textContent_ is
     equal to the _term_ of the _dfn_ element, and (c) it does not have
     an ancestor element that is already referring to a _dfn_
     element.

This is also slightly shorter and easier to read than the current text, 
and avoids the confusing and unnecessary exclusion of elements like 
<em> (for example, "I said <em>font</em>, not <em>typeface</em> ... [a 
couple of paragraphs later] ... By <dfn>font</dfn> I mean a combination 
of typeface, size, weight, and variant").

One concern I have that is addressed by neither the current text, nor 
my suggested text above, is the "in the same document" bit; 
cross-references to definitions in different documents aren't just not 
automatic, they're not possible at all. It almost seems as if <a> is 
being reinvented badly.

-- 
Matthew Paul Thomas
http://mpt.net.nz/
Received on Monday, 28 November 2005 17:26:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:24 UTC