Re: LYNX-DEV javascript useful at all? (was mensa)

[Heather Stern]

I felt fairly certain that I posted something about what javascript (ick)
seems to be used for on the open web, and how we could address it in lynx
(should we want to) but as near as I can tell, it didn't make it to the list.

If you recently saw something very similar to this, but not the same, from
me, sorry... To reduce chatter I'll call javascript JS, and I mean either
javascript or Jscript.

I ate the fortune cookie first, then read what David Woolley wrote:
> > I was thinking that there could be some javascript hacks using the concept
> > of imagemap code as a base, but then I realized that javascript is usually
> > <!-- commented out -->.  I can't remember *blush*, does lynx do anything
> 
> It's only commented out to a reader that doesn't know the DTD declaration
> for script, otherwise it is part of a CDATA field.
> 
> > with text that is in comments or does it just throw it away until the
> > other end shows up? 
> 
> I'm not sure if Lynx understands this use of CDATA, but, if it doesn't,
> it will need to, because of style sheets.

At very least so as we improve in other ways, we can still correctly ignore
it.

> My view on Javascript programs masquerading as HTML is that you should
> use a GUI browser on them, as one is generally fighting a losing battle
> to attempt to render them in any meaningful way on a text mode browser.

There are a few things Javascript seems to be being used for:
1. Mouseovers - 
   a) to show extra text in the status line (whether in addition
      to or in replacement of proper ALT tags)

      Sounds good, but it'd be tricky.  We'd have to have some memory 
      set aside for it, and choose how to display it:
      i) paste it into the flow of normal text:
             bla Bla bla bla _hot_[mouseover:_foo_bar]_ bla bla

      ii) steal another line in the "status" space at the bottom of lynx 
         (brings it up to 4 lines eaten in Novice mode).  "intuitive" in
         the sense that its rendition is closest to the author's intent

      iii) put a [Mouseover] or maybe [JS] tag next to the hotspot, people
         can link it if they wanted to see what it said.  (Ugly.  But allows
         passing JS code to an outside handler?)
   
   b) to show a different image when moused over ("smart" menus)
      If they didn't ALT it, the result might be something like 
             The coolest menu since sliced bread: [IMAGE]{Mouseover] 
             [IMAGE][Mouseover] etc. ...

      Bleh!  In my opinion, not worth the trouble.  The closest I could
      see that would match the author's intent would be to have that patch
      that mentions the filename instead of [IMAGE], and have it change
      the tag to the other filename as you came over the image.  But then
      you can't "see" (zgv? speechread?) the other IMAGE? 
 
  (Side note: I saw that patch mentioned in an unrelated previous post,
   but couldn't find the patch on the open net.  Maybe I am not looking
   in the right place.)

2. Forms validation -
   In fact I've seen some sites that didn't work because they depended
   too strongly on JS validation code.  Unfortunately I can't point at
   them -- they fixed it :)

   I don't think we're prepared to play big brother for people's forms
   content, thanks anyway... and since people in every JS browser can
   turn it off, they have to write the CGI script on the server to 
   handle the non-JS case.  No sense wasting effort encouraging JS for 
   this, even though it's designed to help the visitor.

3. Painting some extras for JS browsers only -
   E.g. welcome netscape fans.  Image tags for animated images only painted
        for Javascript users.
   If we really implement any decent part of JS this may be easy.  But,
   right now it implies certain assumptions about the incoming browser.

4. Redirect to new page -
   Yes, I think they should use HTTP-REFRESH, or Location: but they don't
   always.  I think some folks use it to drop you into a special webspace
   for JS users.  If we do it, following should be optional, just like our
   present redirects.

5. Open a popup window - 
   Mostly annoying ads, sometimes a floating navbar.  This is where 
   stealing USEMAP code might come in handy.  However, it may be more 
   applicable to add these URLs to the Frames list at the top:
       Frame: main
       Frame: navbar
       Javascript: buy_my_app_popup
 
   I think Javascript is allowed to be in the head or the body.  So this
   might not always work well.

6. A timer -
   I saw an app that did this, when it timed outon you, it dragged you to
   a screen that said your session is now closed.  Sort of #4 on sqteroids.
   Not critical though, since in case of Javascript failure, they had to
   time you on the server side anyway.

7. Scrolling status line tickers - usually ads
   If these had never been invented I'd be really happy.  Too bad the 
   principle is so simple.  Maybe if we implement statusline writing but not
   timing, these can't work? :)

> Failing that, one should try to recognise those created by authoring
> tools, by pattern matching the whole, rather than parsing them, and
> try to reconstruct the parameters to the authoring tool.  This would
> mean tracking all the commonly used authoring tool templates for these
> things.

...and when they upgrade, we'd "break".  It sure wouldn't be blamed on the
page generator, whether it's buggy or not.  Bad idea, buys into maintaining 
bug-for-bug compatibility with someone else's product.

Recognizing the above "cases" rather than having lynx "really read" JS code
is only the same thing from a different POV.  We should either:

* do as accurate an implementation as we can (bearing text mode in mind of 
  course)
* create some way to invoke a "helper app" for it (a'la the way I use zgv to 
  fetch an *occasional* image),
or 
* simply not do it.

If we do it, we'll also want to do some serious testing of "popular"
javascript such as page generator's output and the favorites at Gamelan 
(developer.com).  

As for personal preference?  I am reasonably happy in using a browser that 
has Javascript always turned off by virtue of not having it built in.  I 
like statusline mouseovers... but not enough to leave JS turned on when I 
use Netscape in X.  Some javascripts look cool... but many of them crash
Netscape.  I should hope if lynx-dev even gives it a shot, that we will be
a lot more robust.

Heather Stern -*- email address - star at:
starshine.org --- Starshine Technical Services -*- Sysadmin Support & Training
    lasfs.org --- L.A. Science Fantasy Society -*- de profundis ad astra
-----------------
etymology: the stody of words, and how they came to be
entomology: the study of insects, including those deemed bugs
... in computer science, we can have *both* in one subject!