Strengthening Links
Published 16 years, 5 months pastAs a follow-up to “The Missing Link“, I’ve written a fairly lengthy document that presents a number of alternatives for creating a more flexible and robust linking mechanism. The important core of the piece comes first, identifying a generic problem and covering some pros and cons of various ways to address the problem.
After that comes a much longer section which presents reasons to add linkability to various elements in the HTML5 specification. I did not consider WebForms elements, but instead the list of 91 elements found in the primary list in Simon Pieters’ excellent HTML5 Elements and Attributes guide.
The important thing in that long list is not the exact mechanism I propose, but that I was able to find use cases for 30 HTML5 elements. Each one is described briefly and accompanied by one or two markup examples. Another 18 (listed at the end of the document) seemed initially to be good candidates, but I failed to find reasonable use cases for them. The remaining 43 elements weren’t even considered, since they all seemed to be obviously poor choices. One example is video, which would likely suffer if it were a hyperlink– resolving what to do when a user clicks on the video controls was completely unclear to me.
Now, as to why I’m blogging this instead of taking it to one or another of the relevant mailing lists: I’m looking for community input in order to strengthen the document. Did I miss any alternative solutions in that first section? Are there more pros and cons for the various alternatives? What use cases did I miss in that last list of 18; or, for that matter, what are some strong use cases for the list of 30 that I didn’t include? Are there any elements among the 43 I omitted that do, in fact, have strong use cases for being linkable?
I’ll do my best to keep up with comments. Have at it, folks!
Update 11 Jun 08: I’ve updated the document to incorporate ideas from commenters, and added a few extra bits of information at the end of the document. It’s worth another look, especially since I’ve gotten some semi-official encouragement to submit the proposal to the HTML Working Group.
Comments (21)
I think your second option – Add href, hreflang, media, ping, rel, target, and type to a number of elements in HTML5 – has a lot of merit.
As far as older user agents, if they support javascript, it seems like you could handle a work-around using JS & DOM to read those attributes that the HTML 4 user agent wouldn’t understand natively.
I think creating a new element will just add more confusion. There’s enough confusion with the anchor tag acting as a link, and the link tag acting as a reference. I would be pretty leery of changing their behavior (beyond adding NEW functionality).
1) For all of the elements which can already contain an <a> child element, do you have any reasoning for placing the href on that element (other than to save the 7 characters involved in typing <a></a>)?
2) I don’t think I saw mention of it in your document, are you proposing that the user agents should have some default behavior with elements that have an href attribute, such as showing the pointer cursor?
3) How do you propose the user agent should act if there is an href attribute on an element, and an <a> child element with a different href? Would the behavior differ if the <a> element was the only child versus if there are additional children or text nodes?
e.g.
<abbr title=”Google” href=”http://www.google.com”><a href=”http://finance.google.com/finance?q=GOOG”>GOOG</a></abbr>
or
<address href=”http://mag.example.com/article/132/authors/”><a href=”http://ln.hixie.ch/”>Ian Hickson</a>,
David Baron, and the Dalai Lama</address>
Kevin:
1. That often it is the case that such element have their entire content linked, and therefore it’s really the element being linked, only we can’t do that.
2. I am proposing that they should treat elements with
hrefattributes as hyperlinks. What that means is up to the user agent and any applicable CSS, just as it is today with linkedaelements.3. The same way they would handle it if both those elements were given
(on)clickevents with different targets instead ofhrefattributes.Your document and use cases look solid (and very desirable) to me. I can’t see any problems with them.
For the
<progress>element, is linking to the thing for which progress is being displayed the missing use case? That is, if you’ve got more than one progress bar on a page, should each one link to its related task?This could be a use case for
<meter href="...">too.I disagree with you about not adding a href to the video element. Embedded vid’s, when you play them, can be clicked on to take you back to the original location at YouTube or Dailymotion, etc, etc. So I think a href on video should work, and work like that, since the concept’s already being done already everywhere anyway.
I just LOVE the example showing a href for a blockquote. It’d make it much simpler (without scripting) and efficient to give a visitor access to the original document.
Overall, great use cases.
Peter: you may be right– that may be just what I missed. I’ll have to ponder it a bit, but if you have a concrete example you could share, that would be awesome.
Devon: good point. I was under the impression that the video files contained that functionality (being Flash files and all), so the interesting question becomes whether a user agent should try to resolve conflicts between when the video file calls for and what the markup says. Any thoughts? I know I’d lean to letting the markup win but then I’m a serious old-skoola primacy-of-markup type.
Oh thanks! I had no idea camino and such a bug. Fixed for now. I plan a redesign this month anyway. The videos use a param with the link in it.
Another solution would be to have some cross-referencing feature to/from “a” elements.
Two possibilities:
1. A new attribute @for on “a” elements (like @for on “label”)
e.g. <a for=”citation” href=”http://go.there/”></a>
<cite id=”citation”>Let’s get out of here</cite>
2. A new attribute @link on various elements which references an “a” element.
e.g. <a id=”citeref” href=”http://come.here/”></a>
<cite link=”citeref”>I think I’d like that</cite>
The second scheme is trivial for styling and adding onclick handlers, and also allows one <a href> to represent several elements.
Probably you would use empty “a” elements. I’m not sure how well this would work with screen readers.
In HTML 4, an a(nchor) element can contain any inline element. That specifically includes OBJECTs. Since currently a video is supposed to be embedded using an object element, it seems only reasonable that a video element (which would be used in place of the current OBJECT method) should be containable by an a element.
Thus there is no need to add an href attribute to any inline elements, nor any that will will replace object elements, like video – IF the working group catches on to this notion and writes the Rec accordingly.
This leaves the case of elements that are not “inline” ones. Because non-inline elements can contain inline ones, and because inline elements mostly can contain anchors, adding an href to a block element would be pretty nearly the same as allowing nested anchors, which is currently not allowed.
So before jumping on the bandwagon here, it seems to me to be a good idea to get clear on why nested anchors aren’t allowed. This was probably discussed to death when some earlier version of HTML was standardized. I don’t personally know any of the reasons that must have been advanced at the time, but they must be out there somewhere.
As for Eric’s specific example of wanting to click on a row of a table, and get dispatched to a link destination, one could get that to happen – pretty nearly – by adding a table cell to each row that contained text or an image with a link (te.g., “click on me to see a link for the entire row”, only we hope more streamlined). No javascript necessary. [Yes, yes, I know, this doesn’t let you click anywhere on the row, but I don’t see that as much of a drawback. In fact, what if you wanted to have different links on each cell, and also one for the whole role? That would be mucho confusing. Better not to be setting up this situation. Perhaps it’s cases like this that were behind the no-nesting restriction on anchors.]
@Tom:
I have an application that does just what you’re saying is bad. It’s a list of users. Clicking on the row takes you to a detail page about the user. Clicking one of any number of icons allows you do take actions with that user, for instance, edit user information. The row logically has several informational cells as well as the cell holding the icons. This is, of course, implemented via Javascript. Using Eric’s ideas would have made it trivial.
Some reasons adding hrefs to other elements would be nice:
1) Logical, straightforward, fits in your head.
2) Debloats HTML, CSS and JS, reducing bandwidth and storage requirements.
3) Keeps the model simple. E.g. allowing anchors around table cells overcomplicates an already complex table model. E.g. tr > td would potentially fail.
4) Guarantees the clickable area stretches exactly to the edge of the element’s border edge. (Especially useful with table cells, whose size depends on complex, native rendering factors.)
Nice work.
In the section “Devise some new element like link…” you say “Requires the invention of (e.g.) linklang to add the semantics of hreflang”.
Why not just make <link> accept href, hreflang, et al? In other words, <link> would be a direct replacement for <a> in terms of attributes. The only difference is that <link> would be allowed to span block elements as well as inline.
<link href=”blah.html”>
<h1>Example</h1>
<h2>Subtitle</h2>
</link>
I like the idea of a new <link> element because it essentially fixes the main problem with <a> (that it can’t span block elements), but does so by adding a new element rather than changing the behaviour of an existing one. And apart from anything else, “link” is a far more intuitive/semantic name than “a”.
But for the sake of lean markup, I also like the idea of having any (well, most) elements accept href/hreflang/etc elements.
<h1 href=”blah.html”>Example</h1>
So I vote for both the above.
Andy Wardley : have you never put <link/> elements in the <head/> of your documents ?
Or are we using something else for Stylesheet file inclusions/icon referencing etc …
Awesome idea!
Here are use cases for <samp> and <kbd> elements.
If you want to access the console press <kbd href='where-is-the-tilde-key.htm' >Tilde</kbd>
<p>
The program responded with <samp href='manual-error500.html' >Error 500: Program had an error!</samp>, so I reverted the config file.
</p>
<time> should be linkable, for a scheduling/calander/event web application for example, it could link to other scheduled events at the same time. Would it be practical to pass datetime attribute as a parameter?
I’d also say the both sub and sup should have this attribute, if only for consistency. Keep in mind that mathematical formula’s maybe legitimately marked up using sub and sup.
Tom: we already have a situation where each cell in a row can have a different destination and the whole row can have yet another destination: just add
(on)click. What I propose is to make that stuff easier to add at the markup level, and not require JS to make those links works. Whether or not nested links is a good idea, the ship has sailed. Allowing it to happen at the markup level is simply enabling people to do more easily what they’re already doing in more complex and fragile ways.Jeremy: regarding
sampandkbd, of course! Thank you. I’m also largely persuaded by thetimeexample, though example markup would really be helpful.When it comes to
sub, though, I don’t think adding it solely because it’s been added tosupis a tenable position. The linking ofsuphas a very common use case to back it up. Doessub? It might, but I haven’t seen or envisioned one yet.I think I have nailed a a few solid examples of href for <sub>
V = V<sub href='transverse.html'>T</sub> - V<sub href='radial.html' >r</sub>If that not the right way to mark up that example (any physics gurus around?), subscript can also distinguish between different versions of a sub-atomic particle. It can also be used to denote radix (or base), while not common, it is still valid.
For example
100<sub href='binary.html'>bin</sub> = 4<sub href='decimal.html'>dec</sub>And finally the easy time example.
You have an appointment at <time datetime='2008-06-12 16:00:00' href='/appointments/2008-06-12/1600/'>4:00pm Today</time >That link looks rather like a permalink on many blogs… there’s another example! :)
I’ve updated the proposal document with material reflecting Jeremy’s examples for various elements, Peter’s ideas on
progress, and Devon’s suggestion for addingvideo. (I’ll get an acknowledgments section in there before I declare it ready for formal proposal.)I also added lists of all the elements I didn’t include and the four that already have
hrefto the end of the document. In that list of unconsidered elements, are there any I’m overlooking?audioseems like maybe it should come in, but is it a common practice to make embedded audio files link back to some other page, like with embedded videos?I’m also wondering about
embedandobject—should they have direct linking, or is that better handled with already-extant markup patterns?Hi Eric. I have a few musings, although you may want some more detailed use cases ultimately. But, just to kick some ideas around:
pre, I can envisage usinghrefin exactly the same way as you suggest forcode, i.e. when a block of code should be linked to the source file from which it is takenLists (
ul,ol,dl, etc) may well be a subset of a larger, more complete list, e.g.Many elements could benefit from an href attribute, including:
<ul href=”/all/elements/that/will/benefit.htm”>
<li>abbr</li>
<li>div</li>
<li>td</li>
</ul>
In this example, it is both more efficient and more flexible to link the entire list, rather than each and every item. The arguments are similar to those for linking either an entire table or a individual tr.
You include both
captionandtableas ‘possibles’, but refer to the latter from the former, suggesting at least one of these would be useful.New post, everyone! (I touch on your points in the post, Bobby Jack.)