Apparently I have been sleeping lately. (That could be true, I'm a bit tired lately.) I just spotted a nice markup idea from Derek in his post Tracking the Spread of Ideas. (I found that link after reading Three Things I’ve Learned About Blogging, which is also very interesting, but not the topic of this post.) Since Derek does accessibility related work I thought it would be nice to point out that he links to different locations using the same the name for link text. He also didn't provide a TITLE attribute so people could distinguish the two links. I should probably say that as well that it only happened because he quoted a slightly incorrect example. See also Should names link to specific posts/comments(?) to which the answer is: No, they should not.
Enough nitpicking, let's get to the point.
Derek proposes the following (white-space and markup are slightly modified):
Is the link element <a id="examplelink" href="http://www.wats.ca/articles/missinglink/49">the unsung hero of HTML?</a> (via <a rel="via" for="examplelink" href="http://www.digitalmediaminute.com/archives/000513.html">Digital Media Minute</a>)
As you can see he uses rel="via" to describe it is about a special kind of link. Atom uses the same REL attribute value in link logs. A relation between the actual link and the "via" link is made using the construct that can be found in the HTML Forms module; the FOR attribute of the "via" link points to the ID attribute of the "subject" link. I agree that the idea is quite nice, but I doubt if it is practical. rel="via" should get some profile though, maybe the WHATWG could look into this. Derek apparently wants so much metadata that it seems like he is actually reinveting the wheel, although RDF isn't particularly easy of course. Besides Joe Clark, Mark Pilgrim and myself I doubt if anyone would use these extensions to HTML. (Using FOR to point to the "subject" link that is.)
It would be a huge improvement if people actually told their resources on new things, but having some new easy to use markup might be nice.
In the comments on that page Lachlan points to link relationships, which goes a lot further on extending the possible values of the REL (and perhaps REV, if someone still knows that left alone attribute) attribute. Personally, I only like the user feedback values. The other values rely on personal opinions and are therefore not appropriate. (Yeah just like that, not appropriate.)
In the same comments section Eric Scheid wonders how one can keep different profiles different and proposes some syntax for it. It is basically the idea of namespaces and the kind of thing XHTML 2.0 proposes for this (see the ABOUT, PROPERTY and other attributes).
I believe that are the important bits. There is probably some usage in extending current practices and being able to define things more properly without using RDF, but it's not much. However, it would be nice if the WHATWG did something with the various proposals and that the CSS WG figured out a way to select the INPUT element related to the LABEL element using the FOR attribute construct which was described above.
Imho the same goes for:
<p> <q id="paradoxaal-hoogdravend">Eigenlijk meer een selectief fundamentalistische instelling</q>, aldus <cite for="paradoxaal-hoogdravend">Sjonnie Weltevree</cite> </p>
<blockquote cite="http://nathalie.com/2003/november/why-chicken-tastes-like-everything" id="nathalies-chicken"> This one sentence in <cite href="http://whatisthematrix.com/">The Matrix</cite> really… </blockquote> <p> As <cite for="nathalies-chicken" rel="sweetheart">Nathalie Vanderbild</cite> points out, … </p>
I think it's a matter of time, effort and benefit. You can do a lot of things w/ an anchor link, but most of this isn't worth the effort as even alternative browsers (i.e. accessibility) don't actually use the data.
Very interesting concept! I especially agree with Robbert on his comment about q and cite, since matching those up always bothered me. How is the user agent supposed to match them up reliably if there is a lot of quotes in a short piece of text?
I think the main problem with all of this extra markup is that it simply takes too much time if you're on a busy schedule. I hate to admit it, but I even sometimes leave off abbr tags when using abbreviations in my own posts when I'm busy.
You do get some very nice WYSIWYG editors these days, even in come CMS's. If one could build support for this into those editors with a simple point-and-click (or drag-and-drop) for associations, that would make it very practical.
As a last point, I think the only real issue that you might have is keeping all of those id's straight and unique. If you have many of them on a page, it's easy to get confused (again nice if you have a good WYSIWYG or an intelligent markup editor). One more concern I have with this is that when you change your template, you must be careful not to reuse an id that has already been used in one of your posts.
A good way to get around that of course is to establish a convention for your id attributes. For example, all of your id's in your template could start with template-. For example, template-nav.
I thought it would be nice to point out that he links to different locations using the same the name for link text. He also didn't provide a TITLE attribute so people could distinguish the two links
I actually struggled with that one -- I wanted to leave the original markup intact despite the fact that I didn't like the way it was marked up. I thought of adding a title attribute to the link, but again, opted for leaving it the way I found it. I would have used <ins>...</ins> markup, but that wouldn't work in an attribute value. And, I'll have to agree -- link to the post, not the person. If anything the markup should have linked Digital Media Minute to the blog, and the word via should have linked directly to the post.
Besides Joe Clark, Mark Pilgrim and myself I doubt if anyone would use these extensions to HTML. (Using FOR to point to the "subject" link that is.)
Ahem. I most certainly would... ;) That at least makes four of us. Add in a handful of your regular readers, and you never know...
I think I've actually come up with a better way of coding the same relationship that is hopefully more practical and less time consuming, and relatively easy to automate using plugins for blogging tools...