[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Tables (once again) and virtual lynx pages
|
From: |
pAb-032871 |
|
Subject: |
Re: lynx-dev Tables (once again) and virtual lynx pages |
|
Date: |
Thu, 18 May 2000 10:43:00 -0700 |
In "Re: lynx-dev Tables (once again) and virtual lynx pages"
[17/May/2000 Wed 00:20:37]
David Woolley wrote:
> > 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++;
I did mention something about "resolving relative URLS from three
or more separate absolutes". Yes, that would be tricky. Since
fetching all the HTML documents in the first place would be a
kind of d)ownload operation, Lynx's automatic insertion of <BASE
HREF= and X-URL tags -- instead of being a problem -- could serve
as "markers" within the resulting file, telling it when and where
to switch bases.
I really wasn't talking about a full frames implementation anyway,
just a sort of concatenated file including nav-bar, welcome text,
etc [basically, all the *initial* items of a frameset]. From there
it could ignore TARGET attributes, rendering subsequ
discrete files. The rest of the site could be accessed with a
lot less maze-rat searching through a disjointed, multipart index.
Lynx would only have to do this once, when it initially runs into
a frameset "placeholder" or stub.
> this is one of the
> reasons why frames are not permitted in the latest HTML standards),
Or, frames could just just get so rare after a while that nobody
has to worry about it [okay, I'm daydreaming, but it was a *nice*
daydream].
Patrick
<mailto:address@hidden>
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden