[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Tables (once again) and virtual lynx pages
|
From: |
David Woolley |
|
Subject: |
Re: lynx-dev Tables (once again) and virtual lynx pages |
|
Date: |
Wed, 17 May 2000 08:20:37 +0100 (BST) |
> RIGHT! But vertical scrolling can already do that. Why not
> have it write a whole frameset into a single HTML cache-file,
> and then render that? Yes, Lynx would have to ignore the multiple
> <HEAD><TITLE><ETC> entries, but it would offer complete access
It would also have to track multiple URL bases, handle target attributes
(properly designed frames pages always use target for off-site links, to
ensure that they don't appear part of the frameset++; this is one of the
reasons why frames are not permitted in the latest HTML standards), and
provide mechanisms for manually forcing a frame back to full screen.
Home page links in framesets should also use target, to wipe out the
whole framset, and, of course, navigations bars normally use target.
++ An increasingly common use of Javascript is to try, often not very
cleverly, to detect when a page has arrived in a frame, when it should
not, and reload it it in a full window, or when it is part of a frameset
and is not in a frame (they really want "not in the specific frame", but
usually can't handle the combination case), and load the home page.
Both of these break the back button (one of Jakob Nielsen's cardinal,
web design, sins) and the latter also breaks deep linking, although its
effects on deep linking are one of the reasons for abolishing frames.
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden