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

Linking Up

The href everywhere” document (which is officially titled “HTML5: More Flexibile Linking”) has been updated, so kindly give it another look and challenge my assertions, use cases (or lack thereof), and any weak points.  Unless you consider the whole idea of extending linkability to be a weak point, in which case, never mind.  You may or may not be right, but attacking the whole premise isn’t going to get much traction.  I’m convinced the general idea is a good one.  Now it’s up to me to make the best case for it and convince implementors that I’m right.

Thanks to comments on the previous post in the series, a few elements were added to the list of those which have plausible use cases, and I added some documentation of the elements that either aren’t on the list or don’t need to be on it at the end.  Eventually, the “Possible Additions” section will disappear entirely, and at that point I’ll be ready to submit it for consideration to the Working Group.

There are a few outstanding questions raised by commenters on the previous post:

  1. Is there a reasonable case for linking any of ul, ol, or dl?  In cases where they represent quotations of other documents, they’re be wrapped in a blockquote anyway, and I’ve already got a use case for that one.  Linking li makes sense, but the whole list?  There are also questions about dd—would it make sense to allow linking to the paired dd?—but I don’t see a use case for dd.  The whole point there is it’s supposed to be the definition, not a shortened reference to a longer definition.

  2. I was persuaded of the utility of linking video, my previous uncertainty having been based in a misunderstanding of how click-this-video worked now, but what about audio?  I haven’t noticed it being common to link embedded audio clips to other sources, but maybe I’m missing something.

  3. Can a table have multiple thead, tbody, or tfoot elements?  If so, linking them starts to make more sense.  I only wish I could find the part of the HTML5 draft that answers this one way or the other. In a like vein, I can’t decide if it makes more sense to add linking to caption or table.  I’m kind of tending toward the former.  Anyone have good arguments either way?

  4. Should embed and object have direct linking, or is that better handled with already-extant markup patterns?  (If so, using param, I would imagine.)

  5. Is there a reason to link a whole pre to some other resource, other than linking part of a program to a codebase?  Because in those cases, I’d probably use the <pre><code>...</code></pre> pattern, and link the code element.  pre is a presentational element, really, and you’ll note that I haven’t proposed adding linking to just about any of the presentation elements, sup and sub being the exceptions.

  6. There’s a list of “(Possibly) Unsuitable Elements” near the end of the document that might bear some review in case I’m missing some obvious use cases.  Obvious to someone other than me, I mean.

Let me know what you think!  I’m definitely moving forward with this, as I’ve received encouragement from a member of the HTML WG,  but I’d like the proposal to be as solid as possible before I do so.  Thanks for everyone’s help!

29 Responses»

    • #1
    • Comment
    • Thu 12 Jun 2008
    • 1549
    Tim Connor wrote in to say...

    Doesn’t the audio, in theory have the same use case as the video. I meant, aside from being a theoretically non visual element, doesn’t it still allow the player, plug-in, voice-to-text or other device to provide some sort of link back to a fuller page about the audio, a full length clip, a page to purchase, etc?

    • #2
    • Comment
    • Thu 12 Jun 2008
    • 1551
    Tim Connor wrote in to say...

    Oh, just read your comment on the previous post wondering about that. Are you going for purely existing use cases, or allowing what the logical consistent ones would be? Some of these might enable things that may not be currently wide-spread (such as the audio href).

    • #3
    • Comment
    • Thu 12 Jun 2008
    • 1553
    Eric Meyer wrote in to say...

    Maybe in theory, Tim, but I really need real-world use cases for this (and everything else). It’s become rather a manta for HTML5 that things have to based in common usage patterns and real-world use cases. Not a bad thing, but it does mean I have to approach this differently than if it were more of a “we’ll add ideas that seem good even if nobody’s doing anything like it” situation.

    I mean, there may well be use cases for audio. I just need to see them so I can add them. “This seems to be like that” isn’t enough.

    • #4
    • Comment
    • Thu 12 Jun 2008
    • 1603
    Jean-Sébastien Girard wrote in to say...

    The spec, in describing the table content model, says “followed by either zero or more tbody elements” and refers to multiple tbodies in several places.

    • #5
    • Comment
    • Thu 12 Jun 2008
    • 1732
    Bruce Davidson wrote in to say...

    The obvious case for a link on <audio> content is to link to a transcript etc. for users who can’t hear (or politely listen to) the audio. I’d have expected that to be taken care of by a alt attribute, similar to <img>, but as far as I can tell from the spec it isn’t. So I’d propose the following use-case:

    <audio href=”parliament-today/transcripts/1639″ src=”parliament-today/speeches/1639.ogg”>Your browser does not support audio, please click to read the transcript</audio>

    Of course as the content model is “transparent” it may not be at all obvious what (if any) the clickable area is to access the link, so it may not work at all.


    • #6
    • Comment
    • Thu 12 Jun 2008
    • 1803
    Hein Haraldson Berg wrote in to say...

    1. In my opinion – no. The independent list item elements would be sufficient. I agree on the part about the list being wrapped in a blockquote anyway, and that a definition really should be a definition, not just a link pointing forward to another resource.

    3. Is it logical for a table to have more than one thead, or one tbody? Two tfeet elements maybe… «Unfortunately» the tfeet element doesn’t exist, and if it did, only two tfoot elements should be allowed inside. He-he.
    Enough with the jibberish already, I see that multiple tbody elements are allowed, strange as it may seem.

    I do however see that this could be a nice feature, being able to split a table into divisions with own theads, tbody‘s and tfoot‘s. But then I would rather see that these elements got brand new, more logical names.

    Have you got an example as to where linking up an entire table or a table caption would come in handy? Doesn’t this somehow relate to the point stated about the dd element?

    4. With the different browser implementations still hanging around in today’s most popular browsers (mainly IE vs. the rest, as usual), wouldn’t it be OK to be able to link directly from object and embed?

    5. Only being able to link the code elements would probably do the trick.

    Great work. Nice walkthrough of the different elements with their pro’s and con’s, although I’m getting a bit fed up of the «legacy browser» con. It’s such a heavy load to bear when trying to climb the big, steep mountain of development.

    • #7
    • Comment
    • Thu 12 Jun 2008
    • 1902
    Jeff King wrote in to say...

    The document should also include definition of proper behavior for nested linked elements. With the current anchor element, it is illegal to nest them within eachother, so there is not conflict there. Would it then be illegal to nest an anchor element within a linked list item?

    How should a browser handle the following?

    <li href=””>This is an <a href=”#thisExample” >example</a></li>

    • #8
    • Comment
    • Thu 12 Jun 2008
    • 1932
    Wilson Miner wrote in to say...

    Multiple tbodies is definitely valid, but I’m pretty sure tfoot and are one-per-table.

    • #9
    • Comment
    • Fri 13 Jun 2008
    • 0313
    Wolfgang Löer wrote in to say...

    about 1.:

    i don’t see, why the reasoning of dfn wouldn’t apply to dd. its content might ideally be a full definition, but couldnt the dl-construct still be the most semantic solution in a wide variety of cases (like the dropdown-menu on, where dt/dd are used for subcathegories of links)? also, one might want to link to a source and not use blockquote (like, if the definition is just based on or a summary of a larger article).

    having said that, i think the easiest solution to the whole linking-problem and sufficient in most cases (except tr, probably) would be to “change a so that it can wrap around any arbitrary collection of elements”. the legacy problem wouldnt even be that bad,
    as its actually already working in at least some cases and most browsers (like lots of bad code works). so this would be more or less useful right away.

    • #10
    • Comment
    • Fri 13 Jun 2008
    • 0356
    Hein Haraldson Berg wrote in to say...

    Enlighten me, Wolfgang, why a definition list would ever be the most semantic solution to mark up a menu?

    The main categories are not definition titles, and its subcategories are not definition descriptions.

    Jeff King: Wouldn’t it be just natural if it followed the natural z-index like with every other thing? The a element in you example has higher natural z-index. So, the li would still link, but the a element would have higher priority (the element itself is on top of the li), making the example part of the text link elsewhere.

    • #11
    • Comment
    • Fri 13 Jun 2008
    • 0410
    Alan Gresley wrote in to say...

    I didn’t reply to your initial post about this since I didn’t quite agree with it. I can see some use cases but my concern is what happens for a users who can only use a keyboard. They use the tab keys in most browsers to navigate (bringing focus) to href links (I would have coded that properly but then my comment is rejected as spam :-). It’s easy for a users to navigate a page with a mouse but how does this impact keyboard users?

    This is a accessibility issue which you must consider Eric when writing your proposal.

    • #12
    • Comment
    • Fri 13 Jun 2008
    • 0741
    Thomas Tallyce wrote in to say...

    I like the general premise, but what about security?

    Avoiding users clicking on ‘dodgy’ links is hard enough in terms of education at present, but would this become hugely more difficult with lots of additional elements to educate people about? (Or does the fact that people can already make links ‘over’ an image make this a non-issue?)

    • #13
    • Comment
    • Fri 13 Jun 2008
    • 0808
    Eric Meyer wrote in to say...

    To respond to three concerns raised here:

    1. Where there are nested links, then browsers should do what they do right now when there are nested elements with (on)click events. For example, if I attach events to a cell and its parent row, then click on the cell, the cell’s target is the one I follow, because I clicked in it. If I click on another cell in the row, one that doesn’t have an event, then the row’s target is the one followed even though I technically didn’t click directly on the row. I think that’s called a bubble-up approach, but I’m a little fuzzy on the terminology. Anyone know for certain what it’s called (with references)?

    2. Keyboard navigation would be accomplished exactly as it is now with the a element. That’s because any linked element would be a hyperlink; in this scenario, a just becomes one of many elements that can be hyperlinks. In the case of nested hyperlinks, I’d recommend an outside-in approach. If there are browsers that allow any element with an (on)click event to gain focus, then I’d look to them for implementation guidance.

    3. These sorts of links would be less insecure (in the sense of hiding the possible dodginess of link targets) than JS-mediated linking. With the link targets in the document source, anyone can see it by viewing source, and link analysis by spiders is much simpler. It’s also more likely that the target will be visible in the browser chrome when the link is hovered or in focus. With JS-mediated links, the URL can be assembled in obscure ways that make it next to impossible to figure out what the target will be unless you’re a JS expert.

    • #14
    • Comment
    • Fri 13 Jun 2008
    • 1015
    Brian LePore wrote in to say...

    For those of you curious about the reasoning behind multiple tbody elements, the reason for this is that the tbody element allows one to semantically group rows in a table, just like how the colgroup and col elements allow one to group columns.

    Imagine you had a table of data of trials whose order does not matter. You could group all of the passes and fails into two separate tbody elements. Apply an id on each and then could easily write two CSS rules to style the pass trials green and the fail trials red.

    • #15
    • Comment
    • Fri 13 Jun 2008
    • 1018
    Brian LePore wrote in to say...

    What the heck. My post just explained a use case explaining how there can be multiple t-body * elements and it got marked as spam? It didn’t have any HTML elements in it, nor linked to anything, nor contained any common spam phrases. What’s the deal?

    * hoping to avoid the filter!

    • #16
    • Comment
    • Fri 13 Jun 2008
    • 1019
    Brian LePore wrote in to say...

    Eric, I’ve lost two comments due to the filter. What am I doing wrong?

    Could the preview button maybe one one if a comment will be marked as spam or not?

    • #17
    • Comment
    • Sat 14 Jun 2008
    • 1202
    Wolfgang Löer wrote in to say...

    You are right, Hein, that example was probably not the best.

    But does this invalidate my question?

    is dl only correct in cases, where dd is THE definite definition of dt so that it can’t be desireable to link to further sources, references, backstories or whatever? would’t that be very limiting? do such definitions even exist?

    and why would then several dd to one dt be allowed?

    • #18
    • Comment
    • Sat 14 Jun 2008
    • 1215
    Wolfgang Löer wrote in to say...

    here is a better use-case for dd, directly from the whatwg-draft (scroll down a bit):

    <dt> Authors
    <dd> John
    <dd> Luke
    <dt> Editor
    <dd> Frank

    one might want to link to the personal pages of those individuals.

    • #19
    • Comment
    • Sat 14 Jun 2008
    • 1237
    Wolfgang Löer wrote in to say...

    actually, according to the draft,

    dt and corresponding dd in a dl are simply

    Name-value groups


    may be terms and definitions, metadata topics and values, or any other groups of name-value data.

    and not strictly definitions. seen that way, even the proposed menu seems valid.

    when dt and dl sit in a dialog, even more use-cases come to mind, like linking to sound-files or again linking to personal pages (this is a dt use-case!).

    • #20
    • Comment
    • Mon 16 Jun 2008
    • 1142
    Eric Meyer wrote in to say...

    Brian: sorry about that; Akismet was apparently being more hyper than usual, as there were a couple of other comments by people other than you that suffered the same fate right around the same time. I did eventually see your e-mail and fished out the comments, so at least the “you’ve been spam-canned” warning plugin did its job. (Before I asked for help creating that plugin, there was no notice at all that one had been canned!)

    • #21
    • Comment
    • Thu 19 Jun 2008
    • 1140
    Mike wrote in to say...

    If I’m not mistaken the “href everywhere” concept will be included in XHTML 2.0. For me that is a big argument for XHTML 2.0 over HTML 5 (as it currently stands and as I currently understand them). I won’t pretend to understand either format entirely as I was only exposed to HTML 5 & XHTML 2.0 yesterday or maybe the day before as web design is only a small portion of my job responsibilities. I’m not trying to start a comparison (or flame) war over the two specs, just stating that I really like the concept (then there does not appear to be much difference between the nav tag and the nl tag either).

    I think XHTML 2.0 also has “src everywhere” or something to that affect that seems like a nice attribute. Again IMHO being not completely up to speed on either or both specs.

    • #22
    • Comment
    • Fri 20 Jun 2008
    • 0711
    Chris Cox wrote in to say...


    I apologise for the off-topic comment, but you’ve closed comments on the next one and I just wanted to say as a long-term reader, father of one and expecting another, congratulations on Version 2.1

    ALso, are you aware that the excuse generated that day was “The breakup of the American family”? Gave me a giggle.

    • #23
    • Pingback
    • Wed 25 Jun 2008
    • 0551
    Received from Links for 2008-06-25 -

    […] HTML5: Linking up [Eric Meyer] […]

    • #24
    • Comment
    • Tue 1 Jul 2008
    • 0834
    Stevie D wrote in to say...

    If we’re going down this route, I would like to see href attributes for dt and dd elements. Examples – you could have the dt link to an audio file to give the pronunciation – you could have pages about each term defined and want to link to them from the dt – seconding Wolfgang’s comment 18 where you would link from the dd where it references name-value pairs.

    • #25
    • Comment
    • Tue 8 Jul 2008
    • 0800
    Seamus wrote in to say...

    A case where you might want to link a PRE is when it contains a poem where the format is important (for example the text make the shape of an arrow). If you have an index of poems where the first few lines of each is shown, then you would put them in a PRE and link it to the full poem.

    • #26
    • Comment
    • Tue 8 Jul 2008
    • 1241
    Ro wrote in to say...

    Another good rationale for granting TH elements the href property is column sorting. Could reduce and simplify JS required for implementing that type of functionality.

    • #27
    • Comment
    • Tue 22 Jul 2008
    • 1122
    Rexibit Web Services wrote in to say...

    You make some good points about list elements. The question is more of, where do you draw conformity?

    • #28
    • Pingback
    • Sat 30 Aug 2008
    • 0428
    Received from HTML 5 und die Möglichkeit, jedes Element zu verlinken

    […] <ol> und bei Definitionslisten <dl>. Diese Fragen und noch andere hat sich Eric Meyer auch schon gestellt. Vor wenigen Tagen hat Eric Meyer eine kleine Demo unter dem Einsatz von Javascript, das HTML 5 […]

    • #29
    • Pingback
    • Mon 8 Sep 2008
    • 1007
    Received from HTML 5 und die Möglichkeit, jedes Element zu verlinken

    […] Listen <ol> und bei Definitionslisten <dl>. Diese Fragen und noch andere hat sich Eric Meyer auch schon gestellt. Vor wenigen Tagen hat Eric Meyer eine kleine Demo unter dem Einsatz von Javascript, das HTML 5 […]

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=""> <s> <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
May July