W3C home > Mailing lists > Public > www-html@w3.org > December 2003

Re: <a> and @href (was: Re: XHTML 2.0: Suggestion for <addr/> and <blockaddr/> to replace <address/>)

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Sun, 7 Dec 2003 19:44:20 +0200 (EET)
To: www-html@w3.org
Message-ID: <Pine.GSO.4.58.0312071929530.12108@korppi.cs.tut.fi>

On Mon, 8 Dec 2003, Lachlan Hunt wrote:

> jkorpela@cs.tut.fi wrote:
- -
> >Consider, for example, user agents that communicate with the user via
> >speech synthesis and keyboard input only. At present, if the link texts
> >(contents of <a href="...">...</a> elements) are well-written, as they
> >should, the user can use a "links reading mode" to get an idea of what
> >links there are, or to proceed from one link to another by tabbing, or to
> >request for an alphabetic list of all links, then relatively quickly find
> >the link he's interested in.
> >
> There is no reason why a UA can't simply find all elements within the
> body that have @href set, instead of just <a> elements, and doing
> exactly that.

Exactly what? If the content of an element that acts as a link is
unlimited, so that an <address> element, or a list element, or table, or
whatever, can be alink, it surely becomes impractical to construct, for
example, a list of all links, identified by their link texts.

It is _useful_ to restrict link element content to text. Allowing inline
markup is somewhat questionable but probably OK as long as authors
generally understand that they shouldn't rely on the effects of such
markup.

> It's not hard to list all elements with @href set.

The question is whether they can be listed in a useful way, i.e. whether
the list is helpful e.g. to automatic analyzers and indexers (remember how
Google works on link texts now), to speech-based browsers, and to users
lost in hyperspace and trying to get a _useful_ list of all links on a
page in an alphabetic order.

> >Traditionally, links are indicated as links by the use of "link colors",
> >varying by the state of the link... but as we think of the proposed
> >"everything can be a link" idea, it should become evident how problematic
> >the link concept is...
> >
> Actually, I have to disagree with this too.  The <a> element provides no
> more semantic meaning than the presence of @href.  Infact, I believe
> being able to make any element a link can provide more semantic
> information about the link.

My point was about _indicating_ a link as a link. What's the use of a link
that cannot be _recognized_ as a link? I know it can be used by software,
but seriously: is the entire hyperlink concept really to be abandoned?

If anything can be a link, nothing will. It is _useful_ to restrict
linking features to elements specifically indicated as links and to really
think about linking, instead of just scattering some $%&!@href attributes
here and there. A link is a reference. That alone is just as semantic, or
more semantic, than HTML in general.

>   For example, if the following elements had an @href, the semantic
> meaning could be like this.
> <code> A link to a document, or fragment, relating to the piece of code.
> <dfn> could be a link to the formal definition of the term being defined.
(etc.)

Surely, anything could be made a link - and great confusion can be caused.
A link per se is just a reference, and in principle the rel attribute is
supposed to explain the relationship between the linking and the linked
resource. This attribute has never been standardized, and working with
this would be useful. But making everything a link is not, especially we
all (authors and users) are supposed to guess the relationship.

If you wish to explain, say, a fragment of 42 lines of program code by a
reference to some documentation, then do so - with a normal link. Making
the code itself a link would just create confusion. And those 42 lines of
code would really mess up a list of all links on a page.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
Received on Sunday, 7 December 2003 12:44:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:59 GMT