pre, I can envisage using href in exactly the same way as you suggest for code, i.e. when a block of code should be linked to the source file from which it is taken

Lists (ul, ol, dl, etc) may well be a subset of a larger, more complete list, e.g.

Many elements could benefit from an href attribute, including:

<ul href=”/all/elements/that/will/benefit.htm”>
<li>abbr</li>
<li>div</li>
<li>td</li>
</ul>

In this example, it is both more efficient and more flexible to link the entire list, rather than each and every item. The arguments are similar to those for linking either an entire table or a individual tr.

You include both caption and table as ‘possibles’, but refer to the latter from the former, suggesting at least one of these would be useful.

I also added lists of all the elements I didn’t include and the four that already have href to the end of the document. In that list of unconsidered elements, are there any I’m overlooking? audio seems like maybe it should come in, but is it a common practice to make embedded audio files link back to some other page, like with embedded videos?

I’m also wondering about embed and object—should they have direct linking, or is that better handled with already-extant markup patterns?

V = V<sub href='transverse.html'>T</sub> - V<sub href='radial.html' >r</sub>
If that not the right way to mark up that example (any physics gurus around?), subscript can also distinguish between different versions of a sub-atomic particle. It can also be used to denote radix (or base), while not common, it is still valid.
For example 100<sub href='binary.html'>bin</sub> = 4<sub href='decimal.html'>dec</sub>

And finally the easy time example.
You have an appointment at <time datetime='2008-06-12 16:00:00' href='/appointments/2008-06-12/1600/'>4:00pm Today</time >
That link looks rather like a permalink on many blogs… there’s another example! :)

When it comes to sub, though, I don’t think adding it solely because it’s been added to sup is a tenable position. The linking of sup has a very common use case to back it up. Does sub? It might, but I haven’t seen or envisioned one yet.

<time> should be linkable, for a scheduling/calander/event web application for example, it could link to other scheduled events at the same time. Would it be practical to pass datetime attribute as a parameter?

I’d also say the both sub and sup should have this attribute, if only for consistency. Keep in mind that mathematical formula’s maybe legitimately marked up using sub and sup.

Or are we using something else for Stylesheet file inclusions/icon referencing etc …

In the section “Devise some new element like link…” you say “Requires the invention of (e.g.) linklang to add the semantics of hreflang”.

Why not just make <link> accept href, hreflang, et al? In other words, <link> would be a direct replacement for <a> in terms of attributes. The only difference is that <link> would be allowed to span block elements as well as inline.

<link href=”blah.html”>
<h1>Example</h1>
<h2>Subtitle</h2>
</link>

I like the idea of a new <link> element because it essentially fixes the main problem with <a> (that it can’t span block elements), but does so by adding a new element rather than changing the behaviour of an existing one. And apart from anything else, “link” is a far more intuitive/semantic name than “a”.

But for the sake of lean markup, I also like the idea of having any (well, most) elements accept href/hreflang/etc elements.

<h1 href=”blah.html”>Example</h1>

So I vote for both the above.

1) Logical, straightforward, fits in your head.

2) Debloats HTML, CSS and JS, reducing bandwidth and storage requirements.

3) Keeps the model simple. E.g. allowing anchors around table cells overcomplicates an already complex table model. E.g. tr > td would potentially fail.

4) Guarantees the clickable area stretches exactly to the edge of the element’s border edge. (Especially useful with table cells, whose size depends on complex, native rendering factors.)

I have an application that does just what you’re saying is bad. It’s a list of users. Clicking on the row takes you to a detail page about the user. Clicking one of any number of icons allows you do take actions with that user, for instance, edit user information. The row logically has several informational cells as well as the cell holding the icons. This is, of course, implemented via Javascript. Using Eric’s ideas would have made it trivial.

Thus there is no need to add an href attribute to any inline elements, nor any that will will replace object elements, like video – IF the working group catches on to this notion and writes the Rec accordingly.

This leaves the case of elements that are not “inline” ones. Because non-inline elements can contain inline ones, and because inline elements mostly can contain anchors, adding an href to a block element would be pretty nearly the same as allowing nested anchors, which is currently not allowed.

So before jumping on the bandwagon here, it seems to me to be a good idea to get clear on why nested anchors aren’t allowed. This was probably discussed to death when some earlier version of HTML was standardized. I don’t personally know any of the reasons that must have been advanced at the time, but they must be out there somewhere.

As for Eric’s specific example of wanting to click on a row of a table, and get dispatched to a link destination, one could get that to happen – pretty nearly – by adding a table cell to each row that contained text or an image with a link (te.g., “click on me to see a link for the entire row”, only we hope more streamlined). No javascript necessary. [Yes, yes, I know, this doesn't let you click anywhere on the row, but I don't see that as much of a drawback. In fact, what if you wanted to have different links on each cell, and also one for the whole role? That would be mucho confusing. Better not to be setting up this situation. Perhaps it's cases like this that were behind the no-nesting restriction on anchors.]

Two possibilities:
1. A new attribute @for on “a” elements (like @for on “label”)
e.g. <a for=”citation” href=”http://go.there/”></a>
<cite id=”citation”>Let’s get out of here</cite>

2. A new attribute @link on various elements which references an “a” element.
e.g. <a id=”citeref” href=”http://come.here/”></a>
<cite link=”citeref”>I think I’d like that</cite>

The second scheme is trivial for styling and adding onclick handlers, and also allows one <a href> to represent several elements.

Probably you would use empty “a” elements. I’m not sure how well this would work with screen readers.

Devon: good point. I was under the impression that the video files contained that functionality (being Flash files and all), so the interesting question becomes whether a user agent should try to resolve conflicts between when the video file calls for and what the markup says. Any thoughts? I know I’d lean to letting the markup win but then I’m a serious old-skoola primacy-of-markup type.