Linking UpPublished 14 years, 11 months past
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!
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?
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).
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.
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.
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.
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
tfeetelements maybe… «Unfortunately» the
tfeetelement doesn’t exist, and if it did, only two
tfootelements should be allowed inside. He-he.
Enough with the jibberish already, I see that multiple
tbodyelements 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
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 captionwould come in handy? Doesn’t this somehow relate to the point stated about the
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
5. Only being able to link the
codeelements 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.
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>
tbodiesis definitely valid, but I’m pretty sure
tfootand are one-per-table.
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.
Enlighten me, Wolfgang, why a
definition listwould ever be the most semantic solution to mark up a menu?
The main categories are not
definition titles, and its subcategories are not
Jeff King: Wouldn’t it be just natural if it followed the natural z-index like with every other thing? The
aelement in you example has higher natural z-index. So, the
liwould still link, but the
aelement would have higher priority (the element itself is on top of the
li), making the
examplepart of the text link elsewhere.
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.
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?)
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)clickevents. 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
aelement. That’s because any linked element would be a hyperlink; in this scenario,
ajust 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)clickevent 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.
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.
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!
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?
You are right, Hein, that example was probably not the best.
But does this invalidate my question?
dlonly correct in cases, where
ddis THE definite definition of
dtso 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
here is a better use-case for dd, directly from the whatwg-draft (scroll down a bit):
one might want to link to the personal pages of those individuals.
actually, according to the draft,
and not strictly definitions. seen that way, even the proposed menu seems valid.
dlsit 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!).
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!)
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.
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.
Links for 2008-06-25 - tonyscott.org.uk
[…] HTML5: Linking up [Eric Meyer] […]
If we’re going down this route, I would like to see
ddelements. Examples – you could have the
dtlink 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
ddwhere it references name-value pairs.
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.
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.
You make some good points about list elements. The question is more of, where do you draw conformity?
HTML 5 und die Möglichkeit, jedes Element zu verlinken
HTML 5 und die Möglichkeit, jedes Element zu verlinken