meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Any-Element Linking Demo

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…

68 Responses»

    • #1
    • Comment
    • Wed 23 Jul 2008
    • 1434
    Rob L. wrote in to say...

    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
    • Comment
    • Wed 23 Jul 2008
    • 1439
    Eric Meyer wrote in to say...

    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
    • Comment
    • Wed 23 Jul 2008
    • 1444
    Pete Nelson wrote in to say...

    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
    • Comment
    • Wed 23 Jul 2008
    • 1457
    Wolfgang Löer wrote in to say...

    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
    • Comment
    • Wed 23 Jul 2008
    • 1504
    Brian Hefter wrote in to say...

    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
    • Comment
    • Wed 23 Jul 2008
    • 1513
    Nathan Vack wrote in to say...

    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
    • Wed 23 Jul 2008
    • 1539
    Received from 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
    • Comment
    • Wed 23 Jul 2008
    • 1547
    M. Dave Auayan wrote in to say...

    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
    • Comment
    • Wed 23 Jul 2008
    • 1615
    tan wrote in to say...

    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
    • Comment
    • Wed 23 Jul 2008
    • 1617
    tan wrote in to say...

    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
    • Comment
    • Wed 23 Jul 2008
    • 1639
    bruce wrote in to say...

    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
    • Wed 23 Jul 2008
    • 1648
    Received from 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
    • Wed 23 Jul 2008
    • 1829
    Received from 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
    • Comment
    • Wed 23 Jul 2008
    • 2227
    Allwyn Fernandes wrote in to say...

    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
    • Comment
    • Wed 23 Jul 2008
    • 2305
    Eric Meyer wrote in to say...

    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
    • Comment
    • Thu 24 Jul 2008
    • 0625
    Dave wrote in to say...

    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
    • Comment
    • Thu 24 Jul 2008
    • 1305
    Dylan wrote in to say...

    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
    • Comment
    • Thu 24 Jul 2008
    • 1531
    Lachlan Hunt wrote in to say...

    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
    • Comment
    • Thu 24 Jul 2008
    • 1548
    Eric Meyer wrote in to say...

    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
    • Comment
    • Thu 24 Jul 2008
    • 1552
    Eric Meyer wrote in to say...

    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
    • Comment
    • Thu 24 Jul 2008
    • 1553
    Eric Meyer wrote in to say...

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

    • #22
    • Comment
    • Thu 24 Jul 2008
    • 1554
    Eric Meyer wrote in to say...

    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
    • Comment
    • Thu 24 Jul 2008
    • 1613
    Dusan Smolnikar wrote in to say...

    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
    • Comment
    • Thu 24 Jul 2008
    • 1631
    Lachlan Hunt wrote in to say...

    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
    • Comment
    • Thu 24 Jul 2008
    • 1809
    John Mayne wrote in to say...

    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
    • Comment
    • Thu 24 Jul 2008
    • 1934
    Eric Meyer wrote in to say...

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

    Done! Next?

    • #27
    • Comment
    • Thu 24 Jul 2008
    • 1938
    Eric Meyer wrote in to say...

    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
    • Comment
    • Thu 24 Jul 2008
    • 1946
    Samori Gorse wrote in to say...

    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
    • Comment
    • Fri 25 Jul 2008
    • 0603
    Frank Boës wrote in to say...

    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
    • Fri 25 Jul 2008
    • 0851
    Received from 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
    • Comment
    • Fri 25 Jul 2008
    • 1002
    Luka Kladaric wrote in to say...

    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
    • Comment
    • Fri 25 Jul 2008
    • 1018
    Christopher Hester wrote in to say...

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

    • #33
    • Pingback
    • Fri 25 Jul 2008
    • 1311
    Received from 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
    • Fri 25 Jul 2008
    • 1340
    Received from 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
    • Comment
    • Fri 25 Jul 2008
    • 1409
    Eric Meyer wrote in to say...

    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
    • Comment
    • Fri 25 Jul 2008
    • 1502
    Thierry Régagnon wrote in to say...

    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
    • Comment
    • Fri 25 Jul 2008
    • 1510
    Ray Dickman wrote in to say...

    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
    • Comment
    • Fri 25 Jul 2008
    • 1708
    Michael Dunstan wrote in to say...

    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
    • Comment
    • Fri 25 Jul 2008
    • 1717
    thinsoldier wrote in to say...

    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
    • Comment
    • Fri 25 Jul 2008
    • 1733
    Todd wrote in to say...

    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
    • Sat 26 Jul 2008
    • 0543
    Received from 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
    • Comment
    • Sat 26 Jul 2008
    • 0623
    Bernhard wrote in to say...

    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
    • Comment
    • Sun 27 Jul 2008
    • 0721
    Phunky wrote in to say...

    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
    • Comment
    • Sun 27 Jul 2008
    • 0722
    Phunky wrote in to say...

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

    • #45
    • Comment
    • Sun 27 Jul 2008
    • 0825
    Bernhard wrote in to say...

    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
    • Comment
    • Sun 27 Jul 2008
    • 1306
    Wayne Elgin wrote in to say...

    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
    • Comment
    • Sun 27 Jul 2008
    • 1727
    Todd wrote in to say...

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

    • #48
    • Comment
    • Mon 28 Jul 2008
    • 0545
    Bernhard wrote in to say...

    @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
    • Mon 28 Jul 2008
    • 2244
    Received from Trevor Davis | Blog | Weekly Link Round-Up #41

    […] Any-Element Linking Demo […]

    • #50
    • Pingback
    • Tue 29 Jul 2008
    • 0752
    • #51
    • Comment
    • Tue 29 Jul 2008
    • 1107
    Christopher Hester wrote in to say...

    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
    • Comment
    • Tue 29 Jul 2008
    • 1546
    Mike Schinkel wrote in to say...

    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
    • Comment
    • Thu 31 Jul 2008
    • 0559
    Eric Meyer wrote in to say...

    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
    • Comment
    • Wed 6 Aug 2008
    • 0714
    bruce wrote in to say...

    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
    • Comment
    • Wed 6 Aug 2008
    • 1013
    Eric Meyer wrote in to say...

    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
    • Comment
    • Thu 7 Aug 2008
    • 1253
    bruce wrote in to say...

    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
    • Comment
    • Thu 7 Aug 2008
    • 1605
    Wolfgang Löer wrote in to say...

    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
    • Comment
    • Thu 7 Aug 2008
    • 1659
    Eric Meyer wrote in to say...

    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
    • Comment
    • Fri 8 Aug 2008
    • 0418
    bruce wrote in to say...

    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
    • Comment
    • Sun 10 Aug 2008
    • 2211
    Ian wrote in to say...

    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
    • Comment
    • Mon 11 Aug 2008
    • 0956
    koew wrote in to say...

    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
    • Comment
    • Tue 12 Aug 2008
    • 1236
    Michaël Guitton wrote in to say...

    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
    • Thu 18 Sep 2008
    • 0432
    Received from 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
    • Comment
    • Fri 17 Oct 2008
    • 0405
    Kit Grose wrote in to say...

    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
    • Tue 13 Oct 2009
    • 1026
    Received from 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
    • Comment
    • Wed 17 Mar 2010
    • 1447
    Dennis File wrote in to say...

    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
    • Fri 4 Feb 2011
    • 0854
    Received from 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
    • Sat 22 Feb 2014
    • 0520

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


July 2008
SMTWTFS
June August
 12345
6789101112
13141516171819
20212223242526
2728293031  

Sidestep

Feeds

Extras