Anne van Kesteren

Using <link/> for navigation

I am still not sure if this is the way to go, since you could also drop the LINK element in favor of mod_headers and navigation might be part of contents. If it is part of the content it should be placed inside the BODY element in my opinion. I have created a file (a duplicate of the contact page at Limpid) where the navigation is a serie of LINK elements with the REL attribute set to section.

The LINK based Limpid contact page looks (almost) exactly the same as the original one in my build of Mozilla (20040206). Opera show only the first LINK element, 'cause it doesn't support :not() I believe and it doesn't treat the LINK elements as real clickable links, like Mozilla.

The example showed here is of course something we absolutely can't use right now (although I did thought about using it for this WordPress weblog), but I would love to hear your opinion about navigation; 'content' or 'no content' :-)


  1. I think the problem with this navigation system is accessibility. If CSS is not supported, the navigation can not be used.

    Ignore this.. I want to test the comment system 'cause it was bugging us. "oh"

    Posted by Mark Wubben at

  2. The results of the test: the slashes aren't stripped correctly in the preview, nor does can the comment be edited (for it's gone).

    Posted by Mark Wubben at

  3. If we're talking semantics, this is a difficult route. To be absolutely technically accurate, we should use a made up xml element, something like nav-list etc. The best we can get in XHTML is either saying it's a of links (using ul), or a list of (using link).

    Posted by David house at

  4. No, indeed Opera does not understand :not() yet - but you can easily do without: just put head > link[title=Index]::before in the end of the link list, and by cascading rules you have what you want. you also might need to add a padding-bottom:0; to the links to obtain what Mozilla displays wrongly... (after all, the padding is to be transparent, and you see what is underneath...).

    The only real draw-back with Opera is that the links are not clickable - could not get it to work yet...

    Posted by csant at

  5. I made a second example following a couple of your suggestions. I also found some Opera CSS extensions that made the clicks a little bit more usable. You can now right-click on them and the follow the link.

    Posted by Anne at

  6. Nice and well done! but...

    I personally would not reccomend using browser-specific attributes! That only helps fractioning the world even more. Let us rather get Mozilla support content on an element (i.e. not ::after or ::before) and Opera support links as clickable elements when rendered on a page - although I don't know exactly how the specs relate to the latter:

    Links specified by link are not rendered with the document's contents, although user agents may render them in other ways (e.g., as navigation tools).

    Further on the definition seems to specify that links to be used as "activate this link to visit that related resource" are a elements, while link elements define "document relationships" and "may only appear in the head section of a document". Strictly speaking you are doing an inappropriate use of the element, as you are placing them inside the body...

    Posted by csant at

  7. you are placing them inside the body

    No, he's not. They are still in the head.

    Oh, and I did something similar some time ago.

    Posted by David Hasather at

  8. I like your example, though I think the icons of 'first' and 'prev' should be the other way around ;-)

    @csant, I know that Mozilla doesn't support the content property for every element, I don't like it either, but they have a valid point. 'css3-content' isn't CR yet...

    Posted by Anne at