Opera has made several CSS linking extensions. The problem is that they don't support their own specification. More specific: it doesn't work on generated content, which is a shame, since everyone wants to have: blockquote[cite]::after{ /* ... */ }. And, they don't support it using the XHTML namespace.
Although it is buggy in Opera, bugs will be fixed eventually and it is (when you think about it, don't try) a great extension. I wonder why this isn't used in the new CSS3 hyperlinks module.
Note that above test cases only work in a recent version of Opera or Mozilla (Safari?).
Safari 1.2 passes
Well, there's a lot of different linking specifications out there for the moment. W3C have for XML in general XLink (all types of referential links), XInclude (XML source include); XHTML targetted XFrames (embed external), HLink (linking sheets describing linking mechanisms for existing XML Applications); the CSS CSS2.0 Generated Content (embed external), which seems to be (partially) removed from CSS2.1 but reappears in CSS3 . The new CSS3 Hyperlinks is not actually an linking specification, it is a link behavior specification. Then we have Opera's CLink suggestion, Microsoft's HTC and Mozilla's XBL, all of which handle linking in their own way. I wish they could come to a decision. I would prefer if they made a clear document-interface and semantics-presentation-behavior separation, using the appropriate language for each part, not overlapping. Related to that, we have some TAG XML Linking discussion notes discussing linking.
Do I have to linking nailed down or did I overlook something in that? I was wondering about what XSLT can do in the form of XML inclusion (I don't know any XSLT yet)...
I have read that proposal from Opera as well, after I posted I noted the linking discussion. I like it, but I'm not sure if a browser is supposed to support CSS if they want to make something clickable.
I consider declaring a linking relation to be purely semantical, strucural data that SHOULD be placed in the document itself. However, behavior attached to the link is purely presentation and not at all semantics, so it should not be in the document itself but instead in a presentational sheet.
Then we have the different types of links (as I categorise them) - replaced (consisting of inclusion and embedding) and relational (inbound, outbound and third party relations). In neither case I'd say actuation of the link (what triggers the link), or presentation method (new window, new tab, current window etc.) should be part of the document itself.
Media type and parsing guidelines (external parser, raw text or XML structure) may or may not be semantics (a resource may have the same identifier but use e.g. content type negotiation or content language negotiation for many different media types). Properties such as scalability, presence of an intristic size, transparency, min/max limits in rendering frame size etc. do definitely not belong in the document. What the user agent should expect in that way, on the other hand, does.
Just my 0.02€
Well, with xbl you could, in theory, add an anonymous link to the document which adds uses the cite attribute as href, without using javascript. In practice the implementation of xbl in Mozilla sucks a bit too much. It works, but middle clicking is not working. http://home.hccnet.nl/m.wargers/bookmarklets/blockquote.htm