|
Boost : |
From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-09-09 15:35:11
From: "Thomas Witt" <witt_at_[hidden]>
> On Monday 09 September 2002 21:43, Rozental, Gennadiy wrote:
> > > > 2. Even with Javascript 1.5 it's pretty easy to write
> > >
> > > "portable" code.
> > >
> > > This would be a more convincing point had you done so. Have
> > > you tried the
> > > pages in Mozilla? (A browser which uses the reference
> > > implementation for JavaScript, no less.)
> >
> > Yes I did. And it's working perfectly well. Try it yourself.
>
> FWIW my browser (konqueror 3.0.2) crashes. I can't even view the index
page.
> Yes I know it does not have one of the best JavaScript implementations,
but
> that is not the point.
Actually, it is the point. We should not exclude the use of any browser or
other HTML utility just because it has no or poor JS support.
> I still haven't seen a convincing reason to use JavaScript.
I've got one, though like I've said it's a corner case kind of thing and if
banning JS outright is what's needed to prevent what we've seen so far, I'll
live with out it. Here's what I have in mind:
Example code in the documentation is often troublesome. Since this code is
in the documentation it's hard to compile it and insure it's correct. There
are basically two solutions I can think of here (and if anyone has better
suggestions, speak up). One is to parse the HTML to strip out the code and
compile it. This will require the use of tools I don't have, and don't have
time to write. There's other reasons why this is the sub-optimal
solution... for instance it's harder to write code in HTML to begin with,
what with formatting issues, etc. The second solution is to link to the
code in the documentation. Much easier to deal with from a maintenance
standpoint, but not ideal for users since this requires flipping back and
forth between the documentation and the example code. In Boost.Threads I'm
moving towards displaying the example code in a seperate window, allowing
the user to more easily flip back and forth between the example and the
documentation. This can be done with out the need for Javascript using the
target property of the <a> tag. Where Javascript would be handy here is in
controlling the appearance of the "example window", modifying the "chrome"
(the frame, title bar, tool bars, etc.) to provide a nicer UI, and more
importantly insuring the target window is moved to the top of the Window Z
order when it's reused. These features aren't necessary, they just make the
interface nicer. What's interesting about this case is that Javascript
could be employed here in a fully portable fashion, as it's use is
non-intrusive to how any browser/tool handles Javascript.
Since every case where Javascript could be useful is a case where Javascript
is not needed (because otherwise you have browsers/tools that will have
problems with the Javascript), I'll vote for banning if that's the only way
to insure we don't have Javascript issues like we do now.
Bill Kempf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk