1 Fairly cool technique!

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

posted at 08:07 am on June 15, 2004 by CM Harrington

2 lovely, but... why?

“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?

posted at 09:07 am on June 15, 2004 by michael

3 Accessible?

Turn off javascript, you’ve lost navigation.

posted at 09:49 am on June 15, 2004 by Kevin O'Toole

4 re: lovely, but... why?

>>I would still have to add all the LINK elements to “each page”

Not if they’re in a SSI (or other flat file that gets flown in).

If they’re in an include, when it comes time to update, you just change the links in that one file.

No?

posted at 09:49 am on June 15, 2004 by banjo

5 re: lovely, but... why?

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?

posted at 09:56 am on June 15, 2004 by paul haine

6 Navigational enhancement not replacement

This is only an enhancement to the navigation, not a replacement. A site using this method should still be usable and accessible.

posted at 10:18 am on June 15, 2004 by Michael

7 Nice article, but how is it easier?

I think most of the points were said before already, but one.

About the php solution, I did not look at the php source, but giving the page to be parsed as a part of an url.. ..seems like a security risk to me.

Please tell me that you have taken care of stuff like: page.php?p=/etc/pwd

posted at 10:38 am on June 15, 2004 by Mikko Tapionlinna

8 Accessible- yes

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.

posted at 11:26 am on June 15, 2004 by Chris

9 If it ain't broke...

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.

just my $.02…

posted at 05:24 pm on June 15, 2004 by Jeremy

10 Jeremy

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.

posted at 06:08 pm on June 15, 2004 by Chris