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:
Is there a reasonable case for linking any of
dl? In cases where they represent quotations of other documents, they’re be wrapped in a
blockquoteanyway, and I’ve already got a use case for that one. Linking
limakes 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.
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.
Can a table have multiple
tfootelements? 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
table. I’m kind of tending toward the former. Anyone have good arguments either way?
objecthave direct linking, or is that better handled with already-extant markup patterns? (If so, using
param, I would imagine.)
Is there a reason to link a whole
preto 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
preis a presentational element, really, and you’ll note that I haven’t proposed adding linking to just about any of the presentation elements,
subbeing the exceptions.
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!