lynx-dev
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev More discussion about javascript

From: Martin McCormick
Subject: lynx-dev More discussion about javascript
Date: Wed, 26 Jul 2000 09:16:34 -0500 
        Yesterday, I had the all-to-familiar experience of going
to a version of one of our campus web sites which had been
recast and found that all but one of the links had become useless
with that link being one to another page that I didn't even want.

lynx -source revealed the tell-tale autopsy results of death by
javascript once again.

<HTML>
<!-- Lotus-Domino (Release 5.0.3 - March 21, 2000 on Windows NT/Intel) -->
<HEAD>
<TITLE>OSU CIS</TITLE>
<SCRIPT LANGUAGE="JavaScript">

        A nice person with our web development team gave me an
altern ant link to try and that solved the immediate problem, but
it gave me an idea of an interim course of action.

        I know that javascript, itself, does not kill lynx
sessions.  Lynx, in fact, ignores JS so what is really happening
is that there is no communication between lynx and the server
that either one understands.  The javascript is apparently being
used to draw the link for the client's screen and then the mouse
click is sent as some sort of piece of data back to the server.
Since present-day lynx has neither of these capabilities, we
have, in the words of the movie "Cool Hand Luke," a failure to
communicate.

        I would like to be able to intelligently tell people
doing web design what to avoid as telling anybody to avoid
all javascript is like throwing the baby out with the bath water.
There are sites with all kinds of bells and whistles that still
work perfectly in lynx.  If our group understood what is
breaking, maybe we could fend off total disaster long enough to
fix the javascript problem in some other way.

        I went to the Mozilla discussion group on Usenet (and I
have the spam to prove it,) and described the dilemma facing us.

        I got several really good
responses as to what it would take to create a text-based user
interface to mozilla which is one possible alternative.

        I personally think lynx is great and I just love what it
does with cookies when no cookie file is designated.  I want to
see it live on because there are those of us who will most likely
never have any use or need at all for a GUI except to subvert the
system to make it look like a command line.

        A few people said that they prefer lynx for certain
applications and the overall response was positive.

        I want to help solve the problem, but in order to do
that, I must understand what it is and it looks like there is a
tremendous amount of work ahead regardless of whether one can
make lynx understand enough javascript to work well with sites
that should otherwise be accessible or try to put a lynx-like
functionality in mozilla which, according to some, isn't all that
far fetched.  I close by relaying a message I received from a
person on the mozilla group.  Give this all a thought.  We've got
to do something soon or we will have nothing but memories of
access and big bills for all the commercial stuff that only
pretends to work.  This message is a mixture of quotes of my
posting to the mozilla group and the response I received.  Please
read carefully.

Martin McCormick

  Quoted message follows:


From:    Ben Bucksch <address@hidden>
Subject: [Fwd: A Textual Interface for Mozilla]


part 1     text/plain                  71
For the case you missed it... (Message sent to n.p.m.general attached.)part 2   
  message/rfc822            5298


From:    Ben Bucksch <address@hidden>
Subject: Re: A Textual Interface for Mozilla


Martin McCormick wrote:
>         The problem right now is that most web sites play strictly to
> the Netscape/IE axis and use java and javascript.

Yup. A pain not only for blind people.

>         The discussion on the lynx list is serious in that people are
> wondering if it would be better to try to adapt the Mozilla source
> code to fix the GUIproblem rather than rework lynx which is, according
> to those who know a lot about it, beginning to truly show its age.

heh, yes. Not even table support. If you look into the source, you guess
why :). I'm not trying to bash the lynx developers, but hope, they will
actively engage into the project you suggested.

Feel free to draw the lynx developers here. I suggest n.p.m.layout as
newsgroup. Please cc me, if you post there about this topic.

>         There are initiatives that may, one day, make the X
> environment work for computer users who are blind, but they are not
> yet practical.

Berlin <http://www.berlin-consortium.org> might be interesting as well.

>         It would seem to me that Mozilla is in a unique spot with the
> open source and the fact that it already does java and javascript.  In
> other words, it should be easier to give Mozilla a non graphical user
> interface to coexist with the present GUI than it is to try to make
> lynx pretend to be Internet Explorer or Netscape.

Agreed.

>         Is there presently any work being done on this by anybody?

No. I once intended to do so, but gave up due to my lacking knowledge
about the rendering engine, lack of documentation and the size of the
project (for a text port).

I certainly think, it is a good idea and would like to see it being
implemented. If done well, you might not only get a browser, but the
whole suite, including Mailnews. In any case, you would dramatically
improve the HTML->TXT converter, which was the initial intention for me
to evaluate the "text port". The HTML->TXT converter is used to create
most mails Mozilla Mailnews sends out.

Note that 4.x also has a "TextFE"
<http://lxr.mozilla.org/classic/source/lib/xlate/text.c>, which is
primarily (only?) used for HTML->TXT conversion.

> My
> idea would be that one would install Mozilla on a UNIX system.  A user
> with an X console would get the present Mozilla screen.  A user with a
> VT100 would get a Text screen, tossing all the graphics.

Not that easy.

There is an interesting diagram
<http://www.mozilla.org/docs/url_load.html> about the overall design of
the rendering engine ("NGLayout" or "Gecko"), available as GIF and DIA
source file plus a descriptive text.
The following is only as accurate (or less) as my understanding of the
rendering engine, and my understanding of it is quite limited. Somebody
please correct me.

The |nsIRenderingContext| implementation, a port of GFX (responsible for
primitive drawing operations) and possibly XPToolkit (the latter 2 are
not mentioned in the diagram) have to be written from scratch.

Several |nsIFrame|s (representing objects on the screen) propbaly need
to be reimplemented.

|nsCSSFrameConstructor| is what actually lays the page out. Is it a
single class and as hackish as its design looks (but still better than
lynx :-) ). I guess, that class will have to be modified as well, which
would be one of the larger problems.

The other large problem might be to tell the nsCSSFrameConstructor to
instantiate the text implementation of the nsIFrame classes, not the
graphical ones. Also, the information to use text implementation will
propably has to be passed down from the webshell. (Note that the diagram
is outdated - the |nsIDocShell| and |nsIWebBrowser| (IIRC) replaced the
|nsIWebShell|.)

Everything else  - networking library, parser, content tree generator,
all the document stuff - should be reusable.

While I don't think that adding JS support to lynx is a good idea, note,
that the JS implementations from mozilla.org
<http://www.mozilla.org/js/> are usable indepedantly from the browser.

> the java and javascript commands would just make
> different things happen to try to accomplish the same goals that they
> normally do.

You'd have to redefine some methods. "onclick" (which many pages use :-(
) has no meaning on a console.

>         The GUI should be _AN_ interface, not _THE_ interface because
> many tasks, at some point, can be made either graphical objects or
> textual transactions and users should be able to do what works for
> them.  When you think about it, that's how the world works.

Right.


Followup-To n.p.m.layout

-- 
<http://www.bucksch.org>

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
reply via email to
[Prev in Thread] Current Thread [Next in Thread]