[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV javascript useful at all? (was mensa)
From: |
Heather Stern |
Subject: |
Re: LYNX-DEV javascript useful at all? (was mensa) |
Date: |
Tue, 14 Apr 1998 21:38:09 -0700 (PDT) |
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!
- LYNX-DEV www.us.mensa.org or was it .com ?, Philip Webb, 1998/04/07
- Re: LYNX-DEV www.us.mensa.org or was it .com ?, Filip M Gieszczykiewicz, 1998/04/07
- Re: LYNX-DEV www.us.mensa.org or was it .com ?, Philip Webb, 1998/04/07
- Re: LYNX-DEV www.us.mensa.org or was it .com ?, Doug Kaufman, 1998/04/07
- Re: LYNX-DEV www.us.mensa.org or was it .com ?, Wayne Buttles, 1998/04/08
- LYNX-DEV handling Javascript (was mensa etc), Philip Webb, 1998/04/08
- Re: LYNX-DEV handling Javascript (was mensa etc), Jan Hlavacek, 1998/04/09
- Re: LYNX-DEV handling Javascript (was mensa etc), Philip Webb, 1998/04/09
- Re: LYNX-DEV www.us.mensa.org or was it .com ?, David Woolley, 1998/04/10
- Re: LYNX-DEV javascript useful at all? (was mensa),
Heather Stern <=
- lynx-dev Re: LYNX-DEV javascript useful at all? (was mensa), David Woolley, 1998/04/16
- lynx-dev Post, Get prompt... plus bad html errors, Matt Ackeret, 1998/04/19
- Re: lynx-dev Post, Get prompt... plus bad html errors, Al Gilman, 1998/04/19
- Re: lynx-dev Post, Get prompt... plus bad html errors, Frederic Briere, 1998/04/19
- Re: lynx-dev Post, Get prompt... plus bad html errors, Matt Ackeret, 1998/04/19
- Re: lynx-dev Post, Get prompt... plus bad html errors, Larry W. Virden, x2487, 1998/04/19
- Re: lynx-dev Post, Get prompt... plus bad html errors, David Woolley, 1998/04/21
- Re: lynx-dev Post, Get prompt... plus bad html errors, David Woolley, 1998/04/20