In support of the still-to-be-finished proposal for allowing most HTML 5 elements to become hyperlinks, I’ve written a quick proof-of-concept demo for your perusal. Basically, it’s a page with some JavaScript that captures the whole document tree, looks for any elements with an href attribute, and then sprinkles some events on those elements in order to make them act like hyperlinks. There’s also some CSS that applies old-school link presentation to said elements (blue and underlined, baby!). I’m using href because it was the easiest thing to do.

I’m sure I could have written a more elegant script (and yes, I know, your favorite JS framework would done it in half the lines and seventeen times the page weight) and I suspect there are some things I’m missing. I’ll be interested to hear what those may be. Meanwhile, if you want to try out your own arbitrary-element linking, grab a copy of the demo and edit the markup to your heart’s content. Or you could suck out the JS and apply it to your own test pages. Your call.

The demo works fine in Firefox 2, Camino 1.5, Safari 2, and Opera 9.2. I didn’t test it in anything else. It may well fail spectacularly in every other browser known to man and dog. That’s not really an issue, though. The goal here is to have a working demonstration, not a universal solution. (The latter may come later.) It’s a handy way to show people how browsers should behave in an arbitrary-link world.

The one thing that didn’t go right is the status-bar URL handling when hovering over a linked element (other than an a element) that descends from another linked element. For some reason the descendant’s URL never shows up in the status bar. I’m sure there’s an easy fix. I regard this as a minor issue. [Update 7/23: this has been fixed thanks to Allwyn Fernandez.]

The biggest thing that’s missing is simulating “visited” styles on non-a elements; in this case, turning them purple. That would require mining the history and dynamically adding classes and, well, all kinds of stuff. I’m sure it’s possible. I’m also sure that I don’t have the time right now to figure out how to do it well. Besides, ship early, ship often, right?

As I said before, I’m very interested to know what people think of the demonstrated behavior and how it might be improved. And hey, if anyone wants to contribute improvements to the JS, I’ll do my best to keep up.

For some reason the descendant”s URL never shows up in the status bar.

I know you didn’t test Safari 3, but FYI it works on the anchor link inside the linked paragraph, but not quite on the anchor link inside the linked table row. The webstands.org URL briefly flashes in the statusbar when you approach it from the left-hand side.

What happens to existing CSS that specifically targets the “a” element? Would the default style for HTML 5 make elements with the “href” attribute appear like “a/href” elements in the current spec?

Is there concern that this will break existing stylesheets?

Will a transitional DTD address this?

I really like the idea, even if most links today are simply labeled “Click Here”. Someday, people will learn how to take advantage of the web. This will be very beneficial, and goes a long way toward the semantic web.

Trying out your Demo I thought of an additional Con to “Leave things as they are and stick with DOM events to recreate this ability”:

– usability/standards: middle-mouse (open link in tab in FF) and possibly other link-related functionality doesn’t work. (i use this much more often than left-clicking links!)

also since i just read about that topic:
– accessibility: Links are better, if they are
– fewer (ie. not duplicated like linked hn, img and p in a box)
– bigger
– non-js
– more meaningful (than “read more”, which often stands for whole teaserbox)

My concern is, will other technologies such as screen readers and search engines be able to pick up on the fact that these elements are hyperlinks? I guess they only need to parse for the href attribute. It seems to rub me the wrong way a bit in terms of the semantic web. I can see this functionality being useful for interactive purposes (not having to use an anchor for clickable objects in a web app) but haven’t we been working all this time to go against using tags for purposes other than what they were originally intended for? It’s possible I don’t fully grasp what the ideal plan for this new functionality is. Ignoring those aspects, there are plenty of advantages to having this functionality available, and I don’t question that, but it still makes me think.

As far as I can remember, javascript doesn’t run with permission to see past history items — if it could, a page developer could have a script send your history for evil (session keys in URLs, anyone?) or advertising purposes.

I think browser writers would need to explicitly allow :visited support. In which case, they might just as well support href on more elements.

Yeah, Wolfgang – that’s one of the reasons I support what Eric wants to do. Instead of having perhaps 4 links to the same full story from a teaser (the heading, a teaser para, perhaps an image and a “read more” link), all of which would lead to the same place yet have different link text, you’d surround the four elements with a block level element with an href. That would reduce the number of links, but more importantly, it would reduce the complexity for someone navigating via the links.

[…] Eric’s Archived Thoughts: Any-Element Linking Demo Basically, it”s a page with some JavaScript that captures the whole document tree, looks for any elements with an href attribute, and then sprinkles some events on those elements in order to make them act like hyperlinks (tags: meyerweb.com 2008 mes6 dia23 at_tecp href HTML5 blog_post) […]

For some reason the descendant”s URL never shows up in the status bar. I”m sure there”s an easy fix.

Yeah – I think you’re just missing an “event.cancelBubble = true; ” in the onmouseover handler.

I think it’s a beautiful idea…

I’m a tiny little bit concerned about the use case for teasers on articles which contain links, a la Slashdot/BoingBoing… Clicking on most of the paragraph will take you to the longer version of the article, but clicking on the embedded hyperlink will take you somewhere else… Is that a usability issue? How would users distinguish which regions take you to where?

FYI – Doesn’t appear to work in IE7 – but then it would have been more suprising if it did!

You get the rollover effects on all the linked elements, but only the actual anchors take you to an address, the other elements give “Error on Page”

I”m a tiny little bit concerned about the use case for teasers on articles which contain links, a la Slashdot/BoingBoing… Clicking on most of the paragraph will take you to the longer version of the article, but clicking on the embedded hyperlink will take you somewhere else… Is that a usability issue? How would users distinguish which regions take you to where?

I guess that is going to be down to the designer / developer and their ability to make the feature usable. Same as many things currently.

Just for the record, Firefox actually does support altering the status bar via JS, it’s just that the preference involved is disabled by default (so for all intents and purposes it doesn’t really support it).

The security threat that would be introduced by browsers supporting this natively is just too severe, especially given the lack of compelling use cases.

Consider, for example, a comment form on a blog that uses relatively poorly written markup validation, which lets unknown attributes on elements through. Even if the filter strips or sanitises href attributes on a elements, it could miss it on other elements. Then a user could exploit this by inserting this onto some random element: href="javascript:...", using a malicious script.

Since browsers currently don’t support href on any element, that’s not a problem. But as soon as some browser ships with support, and as long as there exists sites with filters that allow such hrefs through (it would be irresponsible to assume they don’t exist), we have a security problem.

I don’t agree with either of your initial characterizations, Lachlan. If anything, I’d attach “lack of compelling” to “security threats”. All a filter has to do is strip off any href it finds, regardless of the element that uses it. Old filters may not be updated to do so, but there are already content-accepting sites and filters that don’t strip out a elements at all. Nobody I know claims that as a reason to remove a from HTML.

Pete, any link-styling CSS written around a:link (and so on) would not be applied to a non-a element. If the element’s left off, like :link, or explicitly uses the universal selector, like *:link, would be applied to linked non-a elements in a supporting browser.

To simulate the expected styling experience in the demo, I selected for [onclick], but that wouldn’t be a viable strategy if this ability were added to browsers.

About M. Dave’s solution, a quick explanation would be …
You can’t check if a link has been visited with javascript. But you can check if it is purple, due to :visited selector’s style being applied to it :)

Eric, the security threat was one of the many issues raised against your proposal when we discussed it internally at Opera. Also, making a whole table row a link (or at least behave like a link) is the only reasonable use case I saw when I previously reviewed your proposal. But I’m not convinced adding an href attribute is the best solution.

Am I the only one not convinced this MUST be in HTML 5? It’s vaguely nifty, but it doesn’t add any feature one cannot do through scripting, which should put it lower on the priority list than a lot of other proposals, imho.

Of course you aren’t the only person who feels that way, John— otherwise it would’ve already been put into HTML 5 and I wouldn’t be expending all this effort. There are people who don’t think it’s important, and some who think it’s actively harmful; but also people who think it is important, and some who think it’s awesome. Pretty much like anything.

But no matter how important or even awesome its addition may be, it won’t happen unless a case is made for it. Even with the case, it may not happen. Actually, given the way the process is structured, I’ll be astonished if it even gets close. I’m not going to let that stop me from trying, though.

while i agree with there being no obvious use cases for thead, tbody and tfoot, i believe there is a real world application for entire table elements to be links to another resource… situations where the table shown is an excerpt of a bigger table, or a link to a pdf/xls with that data, or simply quoted from a different site…

[…] Eric Meyer has put together a proposal for HTML 5 to enable an HTML document to associate URL links with just about every visual HTML element type. This would make it much easier to make a blockquote link to the source of the quote, and would enable things that are currently impossible in HTML such as making an entire row of a table into a link. […]

You know, I’m not 100% sure at the moment, Christian. I’m going to assume it has to do with styling restrictions on table rows, or else to an unexpected interaction with the UA styles. I looked in Firebug but it claimed underlining was applied to the table cells, so… I dunno.

Not sure table rows would be the only compelling use case as Lachlan said (maybe I’m more easily compelled). I work on a project right now where I think it would be great to allow linking on non-anchor elements. Off the top of my head – http://ray.sixent.com/pub – the bookmark listing I have there…clicking it opens a lightbox style viewing of the item. I’d love it if I could have the entire <li> link to the full-page view of the item as a method of degradation. In my current (daunting) task of making this app much more accessible and degrade better – having any element linkable would be quite useful imo.

The scripted implementation does not allow the user to interact with the links with quite the same level of control as regular links. For example a user can not “Open Link in New Tab”, “Copy Link Location” or “Bookmark This Link”. (Tested briefly in Firefox 3.)

Should mock up something that looks like an actual page in the wild where this would be useful.

For example, in a system I’m working on the welcoming page lists the 20 recently edited records in a table.
The table has 12 cells, the contents of 11 of them link to the page to edit the record. 1 cell links to the profile of the administrator who last edited the record.

It would save a significant amount of markup to not have to put an [a href=”page.php/residents/form/edit/286″]ID# 154[/a] in every cell and instaed just put it on each TR

[…] 5 linking proposal for allowing most HTML 5 elements to become hyperlinks, has put together a demonstration of his proposal. His linking demo shows how you could put href=”…” on paragraphs, table rows, […]

When i first read about this i was kinda excited as it does sound like a great idea – removing the need of the ANCHOR tag and allowing us to just apply a link/href=”” attribute to the element does make sense.

But when you think of situations where it would really come in useful can you think of many? As i can only think of the TABLE-ROW example anything else just seems as if you would end up wrapping stuff in SPANs or ANCHORs still to be able to apply the link/href=””

Maybe it should look at working in a different way like you apply a link/href=”” to a PARAGRAPH and then any blank ANCHOR tags will take its parent elements link/href=”” by default?

This would allow us to how clickable TABLE-ROW by setting a link/href=”” on the TABLE-ROW and wrapping the TABLE-CELL contents in blank ANCHORs?

I put a working demo of a version that succesfully validates as XHTML 1.0 strict Here ….

The dirty tricks to fool the validator:
External script to avoid CDATA issues.
Script triggered on window load so – no event handler on the body tag.
No currently illegal “href” attributes in the static source. These are dynamically added on load and populated with values from fully legal “title” attributes, which have the added advantage of providing “tool tips”.

I could only test it in Iceweasel (FF3 build). There you get messages in the status bar, if you allow JS access to it.

I think those with security concerns are assuming a much quicker adoption than reality. Even assuming Safari and Opera bring HTML 5 in first, Firefox and definitely IE will have a much longer tail for introducing some of the HTML 5 elements. How long has CSS2 support taken, never mind 3?

So, it would seem that the modifications required to prepare for an href anywhere could be made over the course of however many years until HTML 5 is in place.

@Todd – Now who is the “validating fool”? (sorry for borrowing that term from your site)

I did of course refer to good old common and garden XHTML 1.0 validation and there the “summary” attribute is IMPLIED not REQUIRED.

Of course having a summary and a noscript element would improve accesabillity and at least warn off people with assistive technology that does not support JS – so I put a noscript element at the top of the page and added a summary attribute to the table tag. Now we’re even Section 508 compliant.

There is another alternative: change the spec to allow the <a> element to surround block level elements. All the browsers allow this <a><h1></h1><img /><p></p></a> (firefox gets a bit wierd with underlining).

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

That’s one of the possible solutions mentioned in the proposal document (“Change a so that it can wrap around any arbitrary collection of elements”), Bruce. I should add a link from the demo to the proposal, shouldn’t I?

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?

bruce: actually i use <a> around block-elements simliarly to your (first) test on my own site (because i wanted <h2> in it and the full box linked and i was lazy) and noticed only rarely a small rendering-problem in ff. (it then looks like there are individual links around everything on only one of the boxes. seems to happen usually when the page is loaded for the first time, so you might see it. will vanish on page reload.)

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? :)

[…] 5 should allow any element should be able to turn into a link by taking an href attribute – see his Any-Element Linking Demo. I suggested that, as a stop gap, HTML 5 should legalise the fact that all the big five browsers […]

I am a huge supporter of this functionality. I don’t see any logical reason to limit the functionality to table cells only (but I don’t think *every* element should be href-able; HTML and BODY are the obvious examples).

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?).

[…] with this if I want to make the entire list item a link, but there is some hope for the future. Eric Meyer proposed any element linking in which you could give any element an href property. Wouldn’t it be nice to be able to do […]

You could add “visited” functionality, but it’d be confusing. You would use javascript to dynamically create an <a> tag with the href of the to-be-created imitation hyperlink. Then use CSS to position:absolute the A tag off the screen. Then use something along the lines of

#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.

I realise I am 6 years too late to this, and hopefully you still read the comments:

The trouble I have with this proposal is that I can not select the text inside the linked paragraph without triggering the onclick which then takes me to the link. Is there a solution to this. (I really like selecting text!)