meyerweb.com

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

Strengthening Links

As a follow-up to “The Missing Link“, I’ve written a fairly lengthy document that presents a number of alternatives for creating a more flexible and robust linking mechanism.  The important core of the piece comes first, identifying a generic problem and covering some pros and cons of various ways to address the problem.

After that comes a much longer section which presents reasons to add linkability to various elements in the HTML5 specification.  I did not consider WebForms elements, but instead the list of 91 elements found in the primary list in Simon Pieters’ excellent HTML5 Elements and Attributes guide.

The important thing in that long list is not the exact mechanism I propose, but that I was able to find use cases for 30 HTML5 elements.  Each one is described briefly and accompanied by one or two markup examples.  Another 18 (listed at the end of the document) seemed initially to be good candidates, but I failed to find reasonable use cases for them.  The remaining 43 elements weren’t even considered, since they all seemed to be obviously poor choices.  One example is video, which would likely suffer if it were a hyperlink– resolving what to do when a user clicks on the video controls was completely unclear to me.

Now, as to why I’m blogging this instead of taking it to one or another of the relevant mailing lists: I’m looking for community input in order to strengthen the document.  Did I miss any alternative solutions in that first section?  Are there more pros and cons for the various alternatives?  What use cases did I miss in that last list of 18; or, for that matter, what are some strong use cases for the list of 30 that I didn’t include?  Are there any elements among the 43 I omitted that do, in fact, have strong use cases for being linkable?

I’ll do my best to keep up with comments.  Have at it, folks!

Update 11 Jun 08: I’ve updated the document to incorporate ideas from commenters, and added a few extra bits of information at the end of the document.  It’s worth another look, especially since I’ve gotten some semi-official encouragement to submit the proposal to the HTML Working Group.

21 Responses»

    • #1
    • Comment
    • Thu 5 Jun 2008
    • 1345
    Pete Nelson wrote in to say...

    I think your second option – Add href, hreflang, media, ping, rel, target, and type to a number of elements in HTML5 – has a lot of merit.

    As far as older user agents, if they support javascript, it seems like you could handle a work-around using JS & DOM to read those attributes that the HTML 4 user agent wouldn’t understand natively.

    I think creating a new element will just add more confusion. There’s enough confusion with the anchor tag acting as a link, and the link tag acting as a reference. I would be pretty leery of changing their behavior (beyond adding NEW functionality).

    • #2
    • Comment
    • Thu 5 Jun 2008
    • 1359
    Kevin H wrote in to say...

    1) For all of the elements which can already contain an <a> child element, do you have any reasoning for placing the href on that element (other than to save the 7 characters involved in typing <a></a>)?

    2) I don’t think I saw mention of it in your document, are you proposing that the user agents should have some default behavior with elements that have an href attribute, such as showing the pointer cursor?

    3) How do you propose the user agent should act if there is an href attribute on an element, and an <a> child element with a different href? Would the behavior differ if the <a> element was the only child versus if there are additional children or text nodes?
    e.g.
    <abbr title=”Google” href=”http://www.google.com”><a href=”http://finance.google.com/finance?q=GOOG”>GOOG</a></abbr>

    or

    <address href=”http://mag.example.com/article/132/authors/”><a href=”http://ln.hixie.ch/”>Ian Hickson</a>,
    David Baron, and the Dalai Lama</address>

    • #3
    • Comment
    • Thu 5 Jun 2008
    • 1405
    Eric Meyer wrote in to say...

    Kevin:

    1. That often it is the case that such element have their entire content linked, and therefore it’s really the element being linked, only we can’t do that.

    2. I am proposing that they should treat elements with href attributes as hyperlinks. What that means is up to the user agent and any applicable CSS, just as it is today with linked a elements.

    3. The same way they would handle it if both those elements were given (on)click events with different targets instead of href attributes.

    • #4
    • Comment
    • Thu 5 Jun 2008
    • 1420
    Matt Wilcox wrote in to say...

    Your document and use cases look solid (and very desirable) to me. I can’t see any problems with them.

    • #5
    • Comment
    • Thu 5 Jun 2008
    • 1441
    Peter J. wrote in to say...

    For the <progress> element, is linking to the thing for which progress is being displayed the missing use case? That is, if you’ve got more than one progress bar on a page, should each one link to its related task?

    This could be a use case for <meter href="..."> too.

    • #6
    • Comment
    • Thu 5 Jun 2008
    • 1524
    Devon Young wrote in to say...

    I disagree with you about not adding a href to the video element. Embedded vid’s, when you play them, can be clicked on to take you back to the original location at YouTube or Dailymotion, etc, etc. So I think a href on video should work, and work like that, since the concept’s already being done already everywhere anyway.

    I just LOVE the example showing a href for a blockquote. It’d make it much simpler (without scripting) and efficient to give a visitor access to the original document.

    Overall, great use cases.

    • #7
    • Comment
    • Thu 5 Jun 2008
    • 1553
    Eric Meyer wrote in to say...

    Peter: you may be right– that may be just what I missed. I’ll have to ponder it a bit, but if you have a concrete example you could share, that would be awesome.

    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.

    • #8
    • Comment
    • Thu 5 Jun 2008
    • 1604
    Devon Young wrote in to say...

    Oh thanks! I had no idea camino and such a bug. Fixed for now. I plan a redesign this month anyway. The videos use a param with the link in it.

    • #9
    • Comment
    • Thu 5 Jun 2008
    • 1940
    Sean Hogan wrote in to say...

    Another solution would be to have some cross-referencing feature to/from “a” elements.

    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.

    • #10
    • Comment
    • Fri 6 Jun 2008
    • 1032
    Tom Passin wrote in to say...

    In HTML 4, an a(nchor) element can contain any inline element. That specifically includes OBJECTs. Since currently a video is supposed to be embedded using an object element, it seems only reasonable that a video element (which would be used in place of the current OBJECT method) should be containable by an a element.

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

    • #11
    • Comment
    • Fri 6 Jun 2008
    • 1640
    Michael Johnson wrote in to say...

    @Tom:

    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.

    • #12
    • Comment
    • Fri 6 Jun 2008
    • 1921
    Greg wrote in to say...

    Some reasons adding hrefs to other elements would be nice:

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

    • #13
    • Comment
    • Sat 7 Jun 2008
    • 0225
    Andy Wardley wrote in to say...

    Nice work.

    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.

    • #14
    • Comment
    • Mon 9 Jun 2008
    • 0856
    Chris Neale wrote in to say...

    Andy Wardley : have you never put <link/> elements in the <head/> of your documents ?

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

    • #15
    • Comment
    • Tue 10 Jun 2008
    • 0140
    Jeremy Arnold wrote in to say...

    Awesome idea!
    Here are use cases for <samp> and <kbd> elements.

    If you want to access the console press <kbd href='where-is-the-tilde-key.htm' >Tilde</kbd>


    <p>
    The program responded with <samp href='manual-error500.html' >Error 500: Program had an error!</samp>, so I reverted the config file.
    </p>

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

    • #16
    • Comment
    • Tue 10 Jun 2008
    • 1048
    Eric Meyer wrote in to say...

    Tom: we already have a situation where each cell in a row can have a different destination and the whole row can have yet another destination: just add (on)click. What I propose is to make that stuff easier to add at the markup level, and not require JS to make those links works. Whether or not nested links is a good idea, the ship has sailed. Allowing it to happen at the markup level is simply enabling people to do more easily what they’re already doing in more complex and fragile ways.

    • #17
    • Comment
    • Tue 10 Jun 2008
    • 1052
    Eric Meyer wrote in to say...

    Jeremy: regarding samp and kbd, of course! Thank you. I’m also largely persuaded by the time example, though example markup would really be helpful.

    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.

    • #18
    • Comment
    • Tue 10 Jun 2008
    • 1812
    Jeremy Arnold wrote in to say...

    I think I have nailed a a few solid examples of href for <sub>

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

    • #19
    • Comment
    • Wed 11 Jun 2008
    • 1404
    Eric Meyer wrote in to say...

    I’ve updated the proposal document with material reflecting Jeremy’s examples for various elements, Peter’s ideas on progress, and Devon’s suggestion for adding video. (I’ll get an acknowledgments section in there before I declare it ready for formal proposal.)

    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?

    • #20
    • Comment
    • Thu 12 Jun 2008
    • 0850
    Bobby Jack wrote in to say...

    Hi Eric. I have a few musings, although you may want some more detailed use cases ultimately. But, just to kick some ideas around:

    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.

    • #21
    • Comment
    • Thu 12 Jun 2008
    • 1550
    Eric Meyer wrote in to say...

    New post, everyone! (I touch on your points in the post, Bobby Jack.)

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


June 2008
SMTWTFS
May July
1234567
891011121314
15161718192021
22232425262728
2930  

Sidestep

Feeds

Extras