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

jkorpela@cs.tut.fi wrote:

>On Sat, 6 Dec 2003, Ernest Cline wrote:
>
>>Actually with the proposed expansion of href from <a> to
>>just about any element in XHTML2, I think it is safe to say
>>that there is no longer any markup element for links.
>>    
>>
>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.  It might even be able to search for @href that begin with 
http:// or ftp://, or whatever increasing the searching ability of UAs.  
CSS3 will be able do this using *[href^=http://] or equivalent, and I 
believe XSL can already do this using XPath.

>Now, if there are no link elements, on the grounds that any element can
>be a link, the situation suddenly becomes perplexed. There's no convenient
>way of listing the link texts when a "link" can be an arbitrary element,
>perhaps covering half of the document.
>
Again, the same reason as above applies.  It's not hard to list all 
elements with @href set.

>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.
  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.
<quote> could be a link to the document or fragment where the quote came 
from.
<sub> or <sup> could be a link to a foot note at the end of the document.
<address> (or equivelant) As Ernest has suggested, it could be a postal 
URI if one is created.
<li>  Very useful for navigation lists.

>If it some day becomes feasible to use links that refer to postal
>addresses, this could be handled fine with such link constructs.
>You would write
><link ref="postal:...">My postal address</link>:
>followed by a presentation of the address, maybe using an <address>
>element, maybe not.
>
That's an example where I think @href in an <address>, <addr>, or the 
<cotact> elements I proposed in an earlier in this thread would be more 
semantic than a generic link tag such as <a> or <link>.  Although, 
<link> is not so generic when an appropriate @rel or @rev is used.  
However, specifying more %LinkTypes for every possible type of link is 
out of the question.  I think being able to use @href in any element 
provides more than enough semantics.

CYA
...Lachy

Received on Sunday, 7 December 2003 09:10:08 UTC