LYNX-DEV Bookmarks - a better idea (?)

[Walter Skorski]

Steve Holmes wrote:

> The only thought I can share so far concerning multiple bookmarks might be
> what I observe when using Netscrape.  It allows to build a "hierarchy" of
> bookmarks in the same bookmarks file simply by creating nested headers.
> However, when lynx displays this file, I don't suppose it would work out
> with the desired effects achieved by having separate bookmark files.

How's this for an idea?  Add a COLLAPSIBLE attribute to the UL tag to
give Lynx an analogous behavior.  For example:

<ul>
 <li>Bookmark List One
 <li><a href="#2">Bookmark List Two</a>
  <ul id="2" collapsible=collapsed>
   <li>Item One of Bookmark List Two
   <li>Item Two of Bookmark List Two
  </ul>
 <li>Bookmark List Three
 <li>...
</ul>

This would be rendered as if the inner list didn't exist (except
possibly for a change or addition to the bullet character), until the
"#2" link was selected.  (If it had said "collapsible=collapsible", or
merely "collapsible", the inner list would be visible at the start.)

Selecting the link would cause the inner list to appear (or disappear,
if it was already visible).  In this way, a bookmark list could be
categorized at least eight levels deep (as could any other list) while
still being maintained in a single file, yet show only as much detail
as is necessary for the user to find what he's looking for.
Furthermore, the file would degenerate cleanly for any
"noncollapsible" browser, showing everything it needs to, along with
some benign and pointless extra links.

A function like this could also be exploited whenever anyone gets
around to redesigning the options screen...

I had originally thought of creating a new internal LYNXLIST URL
scheme to handle activating the expand/collapse function, but realized
that doing so wasn't strictly necessary, and would result in the extra
links that are seen in noncollapsible browsers being bogus instead of
merely pointless.

The biggest question I see needing to be resolved before this could be
implemented is whether it could be done without Lynx having to
rerender the entire page every time a collapsible link is selected.
It'll take a clever programmer to work around Lynx's "one pass" nature
in order to prevent this, but I don't think it's impossible; you'd
just need to treat it as a redisplay request rather than a rerendering
(i.e. more like ^W than ^R).

And, of course, the mechanics of adding and removing bookmarks would
have to change slightly; after selecting a link to add, you'd be shown
the collapsed bookmark file and asked where in the file you want the
new link added.  Also, we wouldn't want to inconvenince the user who
selects a link to add, drills down four levels to find the most
relevant spot, and finds that there's no category for it; so adding
subsections needs to be doable in the middle of an item add.

Just some food for thought.

--
.    iksrokS retlaW<>Walter Skorski    ..        address@hidden         .
 Computer Administrator, Div. of Medical Genetics, Thomas Jefferson University

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;