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

> [Original Message]
> From: Lachlan Hunt <lhunt07@netscape.net>
>
> 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.  In fact, 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 equivalent) As Ernest has suggested, it could be a postal 
> URI if one is created.
> <li>  Very useful for navigation lists.

Actually, in the case of your examples for <code> <dfn> and <quote>,
the cite attribute and not the href attribute would appear to be the
best choice for the document as the connection is to source or
explanatory material for the content, and not using the content of
the element to point to addition info.  Your last three examples
would in my opinion all be nicely served by href as it current is defined.

However, the cite attribute could be handled by using href in conjunction
with rel.  Perhaps that is the direction we should go.  Drop both the cite
and href attributes from the Hypertext Attribute Collection.  Add a new
attribute called "link" that takes a URI. Then specify that in XHTML2,
a specific linktype such as "Hyperlink" is required to cause the element
to be treated as an ordinary single-clickable link (assuming the usual
visual browser convention that is). Then the <a> element could have
the purpose of being able to indicate such a link without having to
specify the rel attribute.  This would.
1) Cut down on the number of attributes.
2) Eliminate a potential source of conflict over the metainfo attributes
   such as type and hreflang as to whether they refer to cite or href.
3) Make non-inline links such as Jukka is worried about more
   difficult to do.

If the src attribute from the Embedding Attribute Collection were
also changed to use "link" and a specific value of "rel" to achieve
the effect we could eliminate yet another attribute and source of
conflict over the metainfo attributes at the expense of being
not able to do a hyperlink or a cite in the same element as
an embedding.  That looks like something authors would be
likelier to do than want to use cite and href on the same element
so I don't know if it would be worth it.

BTW Jukka, as I am not familiar with aural browsers, how well do
they handle the cite attribute as it is currently used in HTML?

Received on Sunday, 7 December 2003 20:58:00 UTC