Linking Up

Published 16 years, 4 months past

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!

Comments (29)

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

    -Bruce

  6. 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. 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=”http://www.example.com”>This is an <a href=”#thisExample” >example</a></li>

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

  9. 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 http://www.adobe.com, 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. 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. 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. 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. 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. 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. 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. 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. 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. here is a better use-case for dd, directly from the whatwg-draft (scroll down a bit):

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

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

  19. actually, according to the draft,

    dt and corresponding dd in a dl are simply

    Name-value groups

    and

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

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

    Links for 2008-06-25 - tonyscott.org.uk

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

  24. 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. 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. 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. You make some good points about list elements. The question is more of, where do you draw conformity?

  28. Pingback ::

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

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

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