Re: lynx-dev Javascript

[David Woolley]

> 
> I don't get it. Everyone seems to be of this opinion, and yet
> the more I read up on libjs and the more I study lynx's sources,
> the less I believe it.

I must admit I've only made cursory glances at the Lynx code, but I
think there are only one or two people in the world who are active on
Lynx and have gone any further.  In combination with the number of
people who have attempted to get into Lynx and abandoned the effort
through an ability to understand it (and a lack of documentation),
this has convinced me that Lynx is suffering from software old age
(small change piled on small change, piled on small change).

> document.form) I'd _have_ to wrap them. So, what's the
> difference between a) lynx's source code having an internal
> representation suited to it, and b) the wrappers doing all the
> conversion work?

See the recent threads on bloat.  But also it is quite likely that 
Lynx just doesn't track the required information in the first place.

> Step 1: Add the js _language_ support, no object model at all

You can't do much except generate alerts!

A very early step needs to be to establish the design principles for
interfacing Lynx, otherwise you are going to un-necessarily make
the result difficult to maintain.
> 
> Step 2: Add to the object model only those objects on which
> others depend, and those good for debugging (document.write?)

document.write is probably one of the worst things to do!

When used at load time, it:

- involves potentially recursive entries to the parser;

- is likely to involve invalid HTML (the HTML should be valid both
  before and after document.write, but usually isn't) - this probably
  only really poses a problem to non JS parsing, not to a JS add on;

- load time uses of document.write are usually to generate code for
  browser specific gimmicks, or to get round differences in browser
  object models.

Run time document.write is quite likely to be used to create non-modal
dialogues, or more or less equivalently to dynamically fill in frames -
Lynx only understands a fully modal model.

> 
> Step 3: Add to the OM those objects that annoy users more ;-)
> (such as document.form)

That's most of the Netscape object model!  (IE more or less allows everything
to be an object.)  Images, frames and layers are most of the rest of the
Netscape model.
> 
> >From here on development may follow the usual Free Software pace
> - everytime someone is interested in an object lynx doesn't
> support, it is a relatively easy task to add it to the OM and
> submit the patch here.

Without an initial structure for the design, the result will be a mess;
with such a structure, the final pieces will probably be so easy as not
to he worth delaying.  The real incremental changes will happen as HTML,
or IE document description langaage grow further.

I think one can get some feel for the bloat in Lynx by comparing it
with tools like html2ps, which parses rather a large proportion of valid
HTML and can really handle tables, but is very much more compact
than Lynx, and weblint, which parses the whole language.  I think
even Amaya is probably not much bigger than Lynx, even though some
versions could render tables in a pseudo text mode as well as in a
full graphical mode (the current version doesn't attempt to do table in
text mode).

Lynx does more than html2ps in terms of handling faulty HTML and in
supporting forms and providing the comms side, and html2ps is built on
Perl, but I still think that html2ps does its job a lot more compactly.

> > If you don't need Lynx because of a disability, my advice would be 
> > to use IE4 (it is at least a year ahead of NS4) when accessing commercial
> > sites; most of them are designed to be almost unuseable without graphics.
> 
> I don't use windows, and I don't call this a disability :-)

It is if you don't have the luxury of ignoring inaccessible sites because
they belong to major suppliers (like Microsoft), and are expected to
spend your gime efficiently, rather than unravel weird navigation 
structures.

> 
> I do have a "disability", still; my computer is so old and
> broken that I prefer to live in text-mode world (less RAM eaten,
> less processor time wasted, less crashes).

The home system is a 386 SX 25 with 6MB++.  I use Lynx from that machine,
but when it is necessary to access commercial sites (and often there
is no Lynx friendly candidate) I usually give in and use IE4 from the 
office.  Originally I only had 4MB and Lynx bloat a couple of years ago
was beginning to become an issue.
 
> Also, my browsing of "commercial sites" accounts for less than
> 10% total. Most of my time I'm browsing Free Software and
> related sites, and these people tend to have a clue.

Unfortunately, Linux sites, at least are succumbing to JS gimmicks
and cookies.  I certainly have to keep cancelling requests to run JS
on IE4 on www.linux.org.  Fortunately these are only bandwidth wasting
graphic buttons which change when you put the mouse over them.

I'd agree that Lynx friendly sites usually have the most real information,
but often information is only available from commercial sites, even
though it tends to be of lower grade, because such sites are normally
controlled by marketing people not technical people; also, one normally
has to plough through commercial sites before one finds a good links page.

However, my impression is that nearly all the demands for JS and cookies,
on this list, come from people wanting to use the most commercial sites
of all on the web, namely pure internet (advertising/market research)
based businesses like Yahoo, Lycos, AltaVista, etc. and finance related
businesses (banks and stock broking related), which although not purely
internet based have no physical product, either.

In the former class, I suspect that most of these people are not in 
the high spending market that the services are targetted at, meaning
there is little incentive for them to support Lynx.

It's possibly interesting to note that although an annoyingly large
number of commercial and vanity publishing sites use JS, I can cancel
JS on nearly all the sites that I have wanted to access (main recent
exceptions are Microsoft and British Telecom).  I make a policy of
rejecting JS because of the number of JS security holes being 
discovered in IE.  (On the other hand I'm actually coding JS 
applications for intranet use, but for sale, not internal use.)

It might be interesting to note the main uses of JS, in approximate
reverse order of frequency with which I've encountered them:

- image buttons that change when the mouse is over them (harmless);

- text that appears when the mouse is over something else (normally
  marketing prose and therefore ignorable);

- image maps which directly link to other versions of themselves,
  containing graphic pointers to the current selection, and load the
  real link into a different frame as a JS side effect (show stoppers
  and require extensive frames support to implement well in Lynx, not
  just JS);

- menus implemented as pulldown lists (navigation stoppers, but probably 
  relatively easy to support within the Lynx model);

- forms validation (generally OK if you can still submit);

- forms submission (I think I've only really found these at Microsoft and
  haven't analysed one in detail, although I think some of the programmers
  where I work who are working more to the official brief may have done
  some).

British Telecom have also produced a page (their domestic packaging of
ISDN) which consists of three completely blue frames when viewed in IE4
with Javascript disabled (i.e. an empty blue screen built in pieces).
I never analysed this, but a previous version was of the self referential
image map kind, as described above.)

> I use lynx because I like it, and I develop Free Software
> because I like it. Adding libjs support will be, from what I'm
> seeing, a challenging, interesting and instructive assignment.
> So, I'm on it.

I don't know the level of committment you are able to give, but I think
you are underestimating what is needed to do the job properly.  I think
if you do do it well you will become one of the prime developers for
the whole of Lynx, not just for the JS add on, as the job will encompass
the whole of the user facing side of Lynx.

++ I think it will get upgraded soon.