38 Reader Comments

This is a pretty cool technique, although I don’t quite see the difference between doing everything via LINK attributes, rather than having a generic dropdown-list form element.

Yes, many browsers do use LINK attributes to create custom button bars for that page. This makes it awkward to have a LINK list that is very long. In your demo, it’s a dropdown list, an infinitely high widget. A toolbar is limited in both width (width of the window) and has a height of a single element.

Often in the article, it is stated that you can hav every page on your site as a LINK attribute. This is less-than-optimal, as text browsers tend to place the contents of the LINKs at the top of the page, and “normal” browsers could potentially have a giant, confusing, non-hierarchical list from which to pick.

Perhaps a better way to go about this would be to dynamically generate LINK attributes for previous/next, but leave the full site-list out of the equation. This will be a bit more meaningful, as it provides LINKs in context with the current page

“Wouldn’t it be great to allow our users to reach all the pages of our site via a handy drop-down menu — without expending extra effort addding [sic] one to each page?”

So instead you’ve gone ahead and created a lengthier and convoluted method to do what the FORM/SELECT elements (and a little JS) already do. I would still have to add all the LINK elements to “each page”, and when it comes time to update it, it’s still as intrinsically time-consuming as updating FORM/SELECT, so where is the benefit? So you’re hard-coding LINK elements now instead of OPTION. Nice use of JavaScript/DOM, but I don’t see the need. Have I missed something?

If you’re going to use SSI to include the link elements, then you could still also use the form/select method and use an include there instead…and then you don’t need to use javascript…or am I missing something?

As Michael pointed out, this is simply to show what is already there, only lacking support in some browsers. Therefore it is very accessible, and as assistive technology _does_ support LINK, a lot better than just a simple dropdown.

As for the “turn off Javascript and the navigation is off”, please read the end of the article, which points to a PHP solution for the same effect.

As for the PHP solution, be free to improve it, currently it either checks if the value was sent to it via post and sets the location to it, or, if there is a P via get, it checks if the file exists, and loads it via fgets. I presume therefore that it will fail with something like /etc/pwd.

I had to agree with the other readers questioning the usefulness of this technique - it does seem like a case of ‘if it ain’t broke, don’t fix it’... with one caveat. I actually have a client right now whose site doesn’t have PHP. They have a relationship with their host that they really like, despite the fact that the host is pricy, and they don’t want to move. So I had to work around not being able to do any SSI options. This could have been a very useful technique when I was revamping their site.

But in most cases, this seems likely to be more trouble than it’s worth.

PHP is not necessary, it is just needed if you want to offer the same functionality without Javascript. LINKs are there to link documents together, they should not replace a full web site navigation though. The original version of the article might have explained this concept a lot more, but was too lengthy to be released on ALA.

LINK elements are good, for accessibility: (http://www.w3.org/TR/WCAG10-HTML-TECHS/#document-meta), they might help you with SEO (http://www.seoconsultants.com/meta-tags/link-relationship.htm) and on some browsers like Mozilla they also mean the next pages get preloaded (http://www.mozilla.org/projects/netlib/Link_Prefetching_FAQ.html). Link can be a lot of different things (http://www.w3.org/TR/REC-html40/types.html#type-links) not only site navigation. The idea of this article is that you should use LINK anyway, as it does make a lot of sense for linked documents. A lot of designers don’t care about it though, or even don’t know about it, mainly because IE does not display them. This is the gap this script should fill.

anon, yes, both valid points. I chose the dropdownnot to waste much screen estate. The regexp are not much of performance issue, after all, this is executed on the server.
As for PHP, again, this is a fallback, if you want to use any other technique, be my guest.

If you can use includes, you can store your link data in PHP in a database or associative array and automatically populate prev and next, too, by reading the current page name.

I used this technique in my unobtrusive Javascript course in case you want to see an example. I wanted users to go through it page by page, but have a chance to shortcut, should they come back later:
http://www.onlinetools.org/articles/unobtrusivejavascript/

No need for this script if you use Opera or Mozilla! They display the navigation bar for you to click on. Great idea though - you could have something big here. How about improving it way beyond what the aforementioned browsers can do?

If you have 30+ pages on a website then a drop down list can be a bit hard to wade through. As navigation I don’t like drop down menu’s that much. They can be powerful in some instances though such as a links page. I use several drop downs on my own links page which loads pages into a frame. Quite handy there but not too useful for nav otherwise.

If you are going for a list all approach I think CSS/dhtml techniques are better and more usable I believe especially with sub menus.

Drop downs might be handy if you are using sub index pages where not all links are 1 click away but a simple site map page can do the same job whilst saving a lot of code on every page.

true, and your point is? Again: This is not to replace a navigation of a web site, we talk about linked documents here, which have a common theme, much like tutorials and online books. LINK is not a navigation replacement, it is above the site navigation, a structural meta navigation.

if I have to type out all that js to render a two option dropdown it doesn’t seem very productive. I still can’t exactly tell where the ‘dynamic’ even comes into play after reading it 3x over ? anyone care to explain ?

How i’ve handled this problem is server-side using php. I read the directory I specify in and grab all files with a .html and dynamically generate a dropdown box on a loop using the list of contents from the dir scan. Now that is dynamic [and less lines of code than this JS in the article].... and server side which leaves no chance of the user being able to interfere by turning a browser preference off.

Well, kudos to you, you found yet another way to do the same.
I also take in your point about dynamic, as it is a misnomer in this case. The dynamic bit is the generation of the dropdown from data in the document, data that otherwise would only be there for clients that support LINK. IE for example does not use the link data we put in for anything, which means a lot of developers don’t even bother adding this data.

Dynamic in your sense means that the link data and the navigation gets generated for each document server side by reading all documents and also setting prev and next, which is exactly what you should do and is a great idea. This article, above all, was meant to raise awareness for the LINK element. Some of the original explanations and intensions got lost in the editing process though.

However, your point about “all these lines of code” you need to “type in”, is a meek one, as all you need to do is to call the script in the zip via ONE script tag. The script can also be done in 20 lines less, but is less legible and worse as a code example then.

Nice use of the LINK tag. I wish we could use more standard HTML elements than just the
“strangeset” IE implements. Maybe as IE becomes less used. I’ve got my Mom using Mozilla. It starts at home. Good job Chris.

Peter-Paul Koch has used this technique for some time on his own site to create a few unobtrusive links at the bottom of each page. He also uses his sitemap as the navigation for his entire site (in a frame not an SSI) using javascript to make it into a dhtml menu. His work should probably have been credited here, and is likely better written.

However, I was not aware of it and unless you read the “making of quirksmode” article on the site you wouldn’t be either. So let’s be a bit more careful assuming that some ideas were taken from somewhere else, shall we?

Personally I am not a big fan of writing out HTML without generating it via DOM, but that is just me.

We are talking about two different things here. This technique is there to show accessibility enhancing LINK info for IE. A Javascript Navigation can be made accessible by simply making it non-dependent on Javascript but enhance it by it.

It works in IE5, you can test it by downloading the standalone IE5 versions out there on the web.
http://www.skyzyx.com/archives/000094.php

You can make a dropdown with javascript redirection accessible by applying the javascript onsubmit rather than onchange on the select. All you need is a Javascript fallback on the server side.
http://www.evolt.org/forms_javascript/

Dante, as pointed out by Chris, using onsubmit on a button rather than onchange on the drop-down menu is the accessible option. The reason for this is the browser will only go to get a page when the _user_ confirms they want that to happen.

If the user had limited mobility with a pointing device they may accidentally change the drop-down menu to an option they actually do not want. Or, maybe the user is negotiating the drop-down menu using the keyboard: they would use arrow keys to select the option they want and would then tab to the submit button.

Cheers, that was the reason. It is negotiable though if users who _rely_ on keyboard navigation don’t actually know that a dropdown onselect is accessible when you pressl alt+arrow down first to expand it and then choose by using arrow up and down and submitting with enter.

What is a BFU? And let’s not forget that a lot of alternative User agents _do_ support LINK to start with, and the dropdown only appears when DOM is available. This means that the chances of a User agent creating the dropdown not being able to render it is very slim.

i think this is a really cool idea, but the main problem i have with it isn’t the HTML bloating or the non-javascript browsers and whatnot. My question is: don’t browsers preload anything within a link attribute? anything in a link tag will be preloaded because of the html DOM. if there’s a way to turn off that option in the HTML somehow, that would make this much more worthwhile for me. i personally wouldn’t want to link a multitude of documents only to make my visitors wait for them to preload.

that’s really my one question, unless there’s a way to link to a document that contains all the links, a table of contents or index or sorts…i dunno, my mind is running away with the possibilities.

(i don’t know if anyone pays attention to these threads anymore, since the article’s a bit old…but there seems to be a tiny issue with spam up there.)

some browsers may preload certain types of links, but unless the link is something like a stylesheet or a favicon etc… it will not delay the display of the page. but to my knowledge, most will not be preloaded at all.

i beleive in all newer gecko based browsers you can make the browser preload/prefetch by using:

<link rel=“prefetch” href=”/foo.html” />

again, this will not delay the display of the current page. it will be processed after the current page is done displaying.

Eric Meyer’s standards-based slide show (11-12/04), like Christian’s drop-down (5/04) splits one page into many “slides” and automatically generates a dropdown menu by which to navigate from one “slide” to another.

As you might expect, the *differences* between Eric’s and Christian’s ideas are as interesting as the similarities.