#detector:visited { height:100px; }

where #detector is the hidden A element. Then use JS to get that A element’s offsetHeight, and find if the link has been visited. If so, change the style of the imitated hyperlink.

The biggest issue I can see with allowing links to wrap any elements is Hixie’s oft-stated goal to make sure the HTML5 specification for error behaviour is well-defined, which could be difficult for structures like:

<a href="#example"><tr><td>Content</td><td>Content</td></a><td>Content</td></tr>


where the author has no obvious implied intent (wanting to link the entire row? the two first cells?).

And hey, if anyone wants to contribute improvements to the JS [...]

IMHO you should drop the onload handler on body and attach the script just before the body closing tag:

(function() {

function click() {
window.location = this.getAttribute(‘href’);
}

function mouseover(e) {
window.status = this.getAttribute(‘href’);
(e || window.event).cancelBubble = true;
}

function mouseout() {
window.status = ”;
}

var coll = document.getElementsByTagName(‘body’)[0].getElementsByTagName(‘*’);
for (var i = 0, all = coll.length; i < all; i++) {
var el = coll[i];
if (el.hasAttribute(‘href’)) {
el.onclick = click;
el.onmouseover = mouseover;
el.onmouseout = mouseout;
}
}
})();

I can already imagine the nice table designs with easy-to-eye colourization, and how it would (hopefully) help users finding their data.

Does this not in the future lead to a (mostly) redundant <a> tag?

If every tag supports an href attribute, we won’t need an extra <a> tag to make links.
- <span> can be used for in-para links
- css can target it via the CSS3 attribute selector

The only remaining use for the <a> would be to define a bookmark/anchor.

It seems too simple. Have I missed something?

I’ve re-sent email– let me know if you don’t get it.

Bruce, thank you many times over for creating that demo and dropping me a pointer here. I don’t think I did get your mail– can you try sending it again, please?

i guess browsers make it work like the lots of other bad html-code because they try to honor the developer-intent if specifications are broken.

this is why i believe the option “change <a>” is the most sensible to include in html5
- it is quite backwards compatible
- is usable immediately (with a little caution)
- doesn’t make understanding/writing html any harder
- legalizes code which most people don’t even know to be invalid
- solves many or all of the otherwise “impossible” cases (depending on whether its allowed only around usual block-elements or special cases like <tr> or <td> as well)
- has no real argument against it (does it worsen anything?)
- seems easy to implement

the option “href everywhere” is clearly and by far the one best solution (from the code, web-user and developer-standpoint at least), but sadly it would take years to become usable.

-> hey why not simply integrate both – <a> for short term, href everywhere for long term? :)

http://www.brucelawson.co.uk/tests/anchors-wrapping-blocks.htm

In all the big 4 browsers, the first test (of a news page “teaser”) works. The second test fails as the inner anchor closes the nest.

(Did you get an email from me a couple of weeks ago about this? My mail server has been wobblier than a toddler’s tooth, so it’s possible it never got to you.)

Very, very interesting that all browsers allow wrapping a around block elements, since they should terminate the inline element as soon as the first block opening tag is reached—and I know that Gecko used to do this, even if it doesn’t now. It used to be required by (X)HTML parsing rules. Did that change when I wasn’t looking?

They fall down if there’s nested <a>s, as each browser closes the outer <a> with the inner <a> closing, so this

<a href="#"><p>Mary had a <a href="http://www.google.com\">little</a> lamb</p></a>

has no linkage on the word "lamb" in any browser.

It’s not as succinct as href anywhere, I agree.