meyerweb.com

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!