[NFBCS] no display in old browser

[Doug Lee]

Rather delayed answer to your idea of implementing Javascript support in a text-based browser:

I imagine that the biggest challenge with this would be the necessary change in paradigm for the display of
the text. Currently I think the text is displayed in a static fashion and through a pager. To make most
Javascript pages work, I think, one would need to redesign that as something like a Curses-based,
realtime-updatable plane of text, where the content could be changed at any moment and, when that change
intersects the currently shown portion of text, produce immediate redisplay of all or part of the current
screen. I don't know Curses very well from the coding side, but I would be surprised if it could natively
handle, say, a 500-page virtual text space with a tiny visible portion. If that's true, the implementation
would need to model the text itself and then update Curses appropriately as that model changed. Finally, we
then have the same issue that screen readers and, for example, their place markers have: If page 105 is
showing and page 2 suddenly doubles in length, where should my cursor and visible segment of text be? I
think users would prefer the text to remain stable but the page count, if shown, to increase appropriately. But
that becomes an interesting trick to implement depending on what system is used to represent the text in the
first place.

Just my thoughts on a windy Saturday afternoon.

On Fri, Apr 05, 2024 at 10:03:04AM -0700, NFBCS mailing list wrote:
	hello.  Following up on both Peter and Doug's notes.

For peter:

	One option you have for creating something that will work with lynx is to write a script,
using something like shell, pearl or python, that downloads the daily jSON file from NASA and
reformats it into a web page that you serve.  The Demonstration API key in the message I posted
earlier suggests that you can only do this a few times a day, but I gather NASA changes this
content daily, so loading once in the morning, eastern time, for example, would probably get
you most of what you want.

For Doug:
Regarding creating a text browser which supports Javascript, I actually looked into this for a
while and might be pursuaded to look at it again.  As text browsers go, Lynx is a pretty
capable browser.  What I mean by that is it supports most HTML controls quite well, just not
javascript or the document object model.  In my research, I found adding Javascript itself,
using the Spidermonkey package, was most likely a relatively easy task.  The greater challenge,
and the one that looked more difficult to me, was creating the document object model which the
browser, lynx, and the javascript engine could work on.  Edbrowse, a completely line oriented
text browser, for example, incorporates the Spidermonkey engine, as does the text based
browser links. (l i n k s).  The problem with these two browsers is that neither of them
implement the document object model, which means any javascripts that try to run and which make
assumptions about their environments, don't work.  Next, for Links, (l i n k s) at least, I
found it didn't work as well with basic HTML pages, rendering it unsuitable for even basic text
browsing.

	Finally, I want to come back to my note about lynx being a pretty capable browser.  It has
been my experience that a very complicated web page, even when viewed through a capable browser
such as  Firefox or Chrome using a screen reader, is pretty unusable.  That is to say, it isn't
a very large step to get from a web site that's usable with lynx to a web site that's not
usable with a javascript capable browser and a screen reader.  It is that narrow window between
pure HTML, which works very well with Lynx, and complex javascript pages with a lot of dynamic
content, which don't work very well at all with javascript capable browsers  and screen
readers, which gives me hope that a text based browser, such as Lynx, could be given a new
lease on life if javascript and a basic Document Object Model framework were added to its
capabilities.  The challenge here is that the base of users who would appreciate such features
is probably vanishingly small.

-thanks
-Brian

-- 
Doug Lee                 dgl at dlee.org                http://www.dlee.org
There is more freedom in knowing how to handle pain than in knowing
how to avoid it.  (4/29/01)