[whatwg] href attribute

Andrew Fedoniouk wrote:
> Back to basics:
> 
> "A hyperlink is a relationship between two anchors,
> called the head and the tail of the hyperlink[DEXTER]. " [1]

   This is not a definition of the <a> element. In fact, <a> is defined
as a anchor, not a hyperlink.

   By contrast, the |href| attribute "specifies the location of a Web
resource". Thus, using |href| for hyperlinks on other elements is an
alteration of the attribute's semantics, because the element you put
them on doesn't have the semantics of a source anchor.

> Any element is allowed to be a tail of the hyperlink:
> 
> "The id attribute may be used to create an anchor at the start tag
> of any element (including the A element)." [2]

   While one could argue that the |id| element give anchor semantics to
an element, it is clear that in this context the text implicitly refers
to the semantics of a DESTINATION anchor, not a source anchor. Even if
you were to ignore this context, it would mean that using |href| as a
global attribute would ALWAYS require you to include an |id| attribute
on the element.

> But I do not understand why we have such a limitation for
> the head of the hyperlink.

   The definition of <a> as inline is the only limitation in HTML I'm
aware of. Everything else is a CSS issue, and we should generally avoid
making fundamental alterations to HTML purely to achieve presentational
ends.

> There are multiple semantically correct cases when
> block elements like <li>, <option>, <address> , <img> etc.
> *are* hyperlinks.

   Actually, by the definition you quoted, they're not hyperlinks and
can never be hyperlinks because a hyperlink is a relationship. In HTML
4.01, they can't even be source anchors. The HTML 4.01 version of |href|
doesn't have the semantics to make them source anchors even if you made
the attribute global.

   So let's be clear that what you're talking about is making every
element semantically an <a> element. In other words, every element would
automatically be a source anchor. Thus, you have taken semantics that
were explicitly represented by an element and made them implicit and
invisible in the markup. This is a poor way of dealing with semantics
that are at the very heart of the World Wide Web, and I would certainly
not call it "semantically correct".

> But designers are forced to use
> weird tricks to fight with inline nature of <a>s.

   That issue can be addressed without getting rid of <a>, by either
allowing <a> to contain block-levels, or by creating a new block-level
container with equivalent semantics.

Received on Saturday, 10 March 2007 19:17:41 UTC