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

[Jeremy Blosser]

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 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.

> BrowseX doesn't have the "bloat-ware" of Javascript.... though
> CSS is a step in the right direction, so I'll go for that
> feature.  I find it hard to like Javascript AND also
> CSS.  Seems the two concepts are contradictory.  One is an
> attempt to centralize presentation and get it out of
> HTML, the other concentrates on presentation dynamics interspersed
> throughout HTML.

You might care to look into some of the XML/XSL/XHTML standards.  CSS and
ECMAscript aren't as contradictory as you might think, and XML's style
sheet component (XSL) actually includes all of ECMAscript as a method for
handling layout and style dynamically.  If CSS is a step in the right
direction, adding a DOM to it as XSL does is even farther in that
direction.  It allows the content component to be nothing *but* content,
and *all* the rendering (including the actual layout, what components are
included or excluded, etc.) to be handled by the style sheets.

To put it another way... the future as we're seeing it now is to have XML
documents that contain only content and classifications for that content,
and XSL style sheets to generate pages or other delivery forms from that
content as they're needed, in whatever form it's requested.  Again, to me
this primarily seems to have potential to help those that prefer text-only
browsing or have other needs and preferences.

-- 
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