Any-Element Linking Demo

Published 16 years, 4 months past

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.

One more step toward a concrete proposal…

Comments (72)

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

    IIRC Firefox 2 & 3 don’t support JS access to the status bar at all.

  2. Oh yeah. So they don’t. Ah well; it’s still a minor thing. One note, though: there’s no anchor in the table row. Just a linked cell.

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

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

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

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

  7. Pingback ::

    prototypecreative.com » HTML 5 Linking Demo

    […] Eric Meyer has created a quick and dirty demo that shows us how elements in HTML 5 can become hyperlinks. […]

  8. I have a fix for your visited “link” problem: http://prototypecreative.com/blog/2008/07/html-5-linking-demo/

    It’s pretty sneaky and probably a very inefficient way to do it, but it’s a solution.

  9. Hi

    Have you tried to check if the referrer on the target page is as expected? (in all browsers).

    I can not remember right now, but I think document.location in IE 6/IE 7 does not gives a referrer. Nor any of the other methods (

    Do this on the target page

    [script type=”text/javascript”]alert(document.referrer)[/script]

    .. or try ouput it using some server technology.

  10. If my asumptions are right, I think the solution for the refferer problem is to branch the code so MSIE is using the elment.click() method while other browsers can use document.location

    tan

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

  12. Pingback ::

    rascunho » Blog Archive » links for 2008-07-23

    […] 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) […]

  13. Pingback ::

    Vorschau auf HTML5/XHTML2 - Wenn jedes Element ein href tragen kann - Peter Kröner - Die Kunst des Machbaren

    […] Meyer hat eine nicht unspannende Demo für HTML5 zusammengekloppt: Mittels Javascript wird simuliert, wie es […]

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

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

    Of course. Even I should’ve seen that. Thank you!

    Hope to respond to other posts and questions tomorrow– now it is time for exhausted-parent sleep.

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

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

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

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

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

  21. Good points, Wolfgang! I need to add those to the document. Thanks much!

  22. M. Dave— thank you! I haven’t added it yet (partly because I’m still trying to figure out how it works) but I have plans. I appreciate the contribution!

  23. Nice demo, and I loved the framework remark ;)

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

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

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

  26. Well, I’ll get right on addressing those many internal concerns, Lachlan.

    Done! Next?

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

  28. It’s a nice solution, and easy to apply, it works fine with Opera 9.50 as well.

    I’ll be nitpicking a bit with the goThere function. document.location is an object with methods, instead of document.location = url you should use the replace method.

    E.g :

    document.location.replace(‘http://urltogo.com’);

  29. And maybe one could extend the Doctype / DTD for validation, like described in w3c documentation – or is there a DTD for HTML5 already?

  30. Pingback ::

    Ajaxian » HTML 5 Linking all around the horn

    […] Eric Meyer has been working on an HTML 5 linking proposal and has put together a demonstration of his proposal. […]

  31. excellent work!

    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…

    i hope you add generic linking support for tables

  32. Great! Only why are most of the links in the table not underlined? (Firefox 3, OS X)

  33. Pingback ::

    Something Witty Goes Here

    […] Meyer’s link-anywhere proposal inspired me to at least float this issue in my blog in case someone else thinks it important. For […]

  34. Pingback ::

    HTML 5 Linking Proposal: Depth for Every Element | Danny Thorpe

    […] 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. […]

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

  36. When I first read about your idea, I found it interesting.

    Now that I have read the first part of “Weaving the Web”, I think it really sticks to the first vision of the Web where the hyperlink is the key to deal with more and more informations every day.

    I hope it will be included in some way in HTML 5.

  37. I think this is a great idea Eric!

    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.

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

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

  40. It does not work in IE6 or IE7. It did work in FF3 and the styling (I assume you had styled it) was not present in IE7.

  41. Pingback ::

    HTML 5 Hyperlinking

    […] 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, […]

  42. Sweet idea, Eric!

    Couple quick fixes to make your demo more standards compliant:
    1. Declare a character encoding
    2. Enclose content of script in CDATA tags. The < and > signs in the script confuse XHTML parsers.

    In a hurry right now. Shall fiddle with script and be back later.

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

    Just a thought!

  44. Argh need a “edit” button on the comments :D my fat fingers have failed me a couple of times in that post!

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

    Enjoy! Then tear it up and improve it!

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

  47. @Bernhard – Your table lacks a summary… therefore not validating the page.

  48. @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.

    It can only get better.

  49. Pingback ::

    Trevor Davis | Blog | Weekly Link Round-Up #41

    […] Any-Element Linking Demo […]

  50. Pingback ::

    Max Design - standards based web design, development and training » Some links for light reading (29/7/08)

    […] Any-Element Linking Demo […]

  51. Comment 35 has me renamed! Who is this mysterious “Christian” person referred to? Did you mean “Christopher?” Hehe. I forgive you Erica.

    :-D

    I see a mime starting here. Wonder if Jeremia Zeldman would be up for it. Or maybe Davina Shea. Or Wally Holzschlag?

  52. Nice, and I’m 100% supportive of your proposal. No matter though, Ian and Lachlan will either ignore it or veto it, so why go to all the effort?

  53. Mike: because if I don’t go to the effort, then there’s no chance of it happening. At least if I try, there’s a non-zero chance of success, however small that chance may be.

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

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

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

  56. Here’s a test page I made to show some friends. Green borders are divs.

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

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

  58. I’ve been thinking much the same since seeing Bruce’s demo, Wolfgang— push for both, with (improved) wrapping support in the near term and attribute expansion on a longer timeline.

    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?

  59. You’re welcome! (That’s what Opera pay me for …)

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

  60. I read this article a few weeks ago. It makes perfect sense to me.
    Then, after pondering, I pondered…

    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?

  61. Ian: By using ID’s instead of anchor names, you could remove the <a>-tag completely – if the any-element-linking would become standard.

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

  62. 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;
    }
    }
    })();

  63. Pingback ::

    Bruce Lawson’s personal site  : Any-Element Linking in HTML 5

    […] 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 […]

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

  65. Pingback ::

    Clickable <li> « I Love Usability

    […] 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 […]

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

  67. Pingback ::

    The lovely picks from html5 at Notepack

    […] linking To be honest, I preferred Eric Meyer’s revolution where any element could link, but an evolution is fine as well – it’s all about flexibility after all. […]

  68. Pingback ::

    href all the things | Rich Jenks

    […] http://meyerweb.com/eric/thoughts/2008/07/23/any-element-linking-demo/ […]

  69. 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!)

    A related proposal that might be of interest is:Fragmention

    ( original post: kartikprabhu.com/href-everything-ericmeyer )

  70. @Kartik: The same goes for »regular a-tag links«. Holding down the ALT-Key while selecting does the trick in these situations.

  71. Hi Eric,

    I thought of your posts today, regarding this idea of yours, when I saw the following post today regarding the dropping of xlink:href=”” from SVG and the adoption of href=”” in place of it. See: https://css-tricks.com/on-xlinkhref-being-deprecated-in-svg/

  72. The nice thing about using vanilla JS is that it still works 10 years later! :)

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

if you’re satisfied with it.

Comment Preview