- From: John Whelan <whelan@itp.unibe.ch>
- Date: Mon, 21 Sep 1998 17:52:54 +0200 (MET DST)
- To: w3c-wai-ig@w3.org
- Cc: charlesn@sunrise.srl.rmit.edu.au
Charles McCathieNevile writes: > Marju asked if there was a guideline about how to use frames in a way > that enabled various points to be bookmarked, and said the current > technique was to rebuild the frameset each time, with all links having > TARGET="_top" > > Nir said that the solution was to not use frames, since rebuilding the > frameset every time a link was followed was a waste of bandwidth. > > That is a kind way of viewing it. Rebuilding the frameset each time is > like publishing a book in modules, with a binder and complete table of > contents available, and then only supplying the modules along with the > binder and contents. Non-frames browsers, such as lynx, will be forced > back to an intermediate step of establishing the relevant frame for each > link followed, which is worse than when frames are correctly coded. Hear, hear. Even for frames-capable versions of links, rebuilding the frameset means an extra step to get to the content pages. A less draconian solution, if you want to use frames, is to write a simple CGI that creates the appropriate frameset for any content document. I started doing this so I could provide multiple entry points to a frameset without constructing a bunch of static documents. You can use SSI to add a link to the appropriate frameset on every content page, et voila, fully bookmarkable frames. (Doesn't work if there are more frameset states than content documents, but 99% of the framesets out there are one or more menu frames plus a single content frame.) See http://www.slack.net/~whelan/cgi-bin/tbrw.cgi for my implementation of this idea. John T. Whelan whelan@iname.com http://www.slack.net/~whelan/
Received on Monday, 21 September 1998 11:53:19 UTC