[NTLUG:Discuss] Javascript and CSS == Usable WWW browser? was Re: [NTLUG:Discuss] BrowseX (FAST, small browser) is outinBETA!!

[Jeremy Blosser]

Christopher Browne [cbbrowne at localhost.brownes.org] wrote:
> On Mon, 02 Oct 2000 11:53:30 CDT, the world broke into rejoicing as
> Jeremy Blosser <jblosser at firinn.org>  said:
> > Chris Cox [cjcox at acm.org] wrote:
> > > Kevin Brannen wrote:
> > > > 
> > > ....
> > > > I also agree with everyone else who wrote that lack of Javascript & CSS
> > > > will hurt BrowseX's spread.  I know I won't bother looking at it for
> > > > that reason.
> > > 
> > > I guess that means that text based browsing is completely dead.
> > > I know that this may well start a long thread, but you have to realize
> > > that a web page that is dependent upon Javascript for its functionality
> > > is probably not going to work on a text only basis.... text only browsers
> > > are still very useful and often used by people with disabilities.
> > > Granted there might be some (but very few) instances where having
> > > Javascript inside of a text browser might be useful... but hardly
> > > necessary.
> > 
> > I disagree, and this is one of the things about Lynx that bugs me.  There
> > is nothing about Java/ECMAscript that makes it only relevant to non-textual
> > browsers.  It gets the most [ab]use from people that use it for wizz-bang
> > graphical things, but the places where it can actually be useful can be
> > just as useful in a textual context.  At it's core, ECMAscript is all about
> > applying the concepts of OOD to web page structure.  I don't want to get
> > into a long listing of what's good about OOD -- there are plenty of places
> > to go for that debate.  Suffice it to say being able to refer to parts of a
> > page as objects can just be darn useful.
> 
> I sit of two minds on this;
> 
> On the one hand, I seldom see web pages that forcibly require ECMAscript
> that use it for anything more profound than demonstrating that the guy
> that wrote the page is a Really Elite WebMeister.  

This is the heart of the problem ES faces, and the reason I bother to get
involved in this discussion. :)  People use it for dumb things, and they
piss off people enough that they throw the cliche out with the bathwater.
I doubt many of us have seen any of the useful stuff ES can be used for --
we just have to deal with it as pop off windows and scrolling status bars
and seizure-causing animations.  BTW, browsers should have options to let
you turn off parts of JS instead of just all or none. :)

> The point of the exercise is _not_ to "apply the concepts of OOD to web
> page structure;" it is to display _useful information_.
> 
> Putting "OOD into the web page structure" is all well and good if the
> goal is to convince another company to hire you.  If the point of the
> exercise is to have a useful web page, nobody ought to need to care if
> the PAGE contains "OOD" or if that takes place on the server behind the
> scenes, never to be seen by the outside world.

No, there is a point to having it on the client sometimes.  Someone already
mentioned making things load/work faster.  This is similar to transmitting
a bitmapped streaming movie vs. a vector-based flash movie.  The second is
much faster.  Also, a server can only operate on content when you submit
something.  It can't auto-populate the address/etc. fields in a form as
soon as you give your name.

> Using ECMAscript controls to link to stuff instead of <a href=
> "whatever.html"> seems a false indicator of "eliteness."

Yes, unless you have an audience that isn't going to be web savvy and you
want to give them options for a 'back' button on the page.  The best you
can do in HTML is link back to a predefined page that may or may not be how
they got where they are.  With a scripted link you can access the browser's
history and work the same way the back button does.  There are other cases
where dynamically-generated links inline can save space/download
time/hassle for the user.

> On The Other Hand.  
> 
> I do agree that nothing inherently _prevents_ embedding an ECMAscript
> interpreter in a text-based browser.
> 
> > I really wish the developers of Lynx would realize this and do something
> > about implementing ECMAscript as it applies to textual browsing.  This is
> > going to be critical if they want to keep up with the standard as it
> > progresses -- XML relies heavily on ECMAscript in it's style sheets (XSL)
> > to allow document layout to be rendered on-the-fly.  One benefit of having
> > this supported will be that the user can specify in even greater detail how
> > they want their content presented, including with more or less
> > text/graphics/wizz-bangs.  That benefits all of us, especially those with
> > special needs.
> 
> The one other thing that seems silly to me is to assume that Lynx is
> the Only Option.
> 
> There's w3m and links as alternatives; it would make a whole lot of
> sense to not assume that Lynx is the _only_ possible "test bed" for
> such an idea.  Both of these browsers do a somewhat better job on
> tables than does Lynx, by the way.

Yes, and I use both of them, especially Links... the color support is a
nice touch. :)  And last I knew Links did have plans to include some kind
of ES support.  I suppose I wish Lynx would do it because it has a
(deserved) reputation for handling standards well, and could help the
perception a lot if it implemented something like this.  Not nearly as much
as sites that implemented it in useful ways, but...

-- 
Jeremy Blosser   |   jblosser at firinn.org   |   http://jblosser.firinn.org/
-----------------+-------------------------+------------------------------
the crises posed a question / just beneath the skin
the virtue in my veins replied / that quitters never win