browsers and javascript

[Terry A. Haimann]

I have been working on creating a dynamic web page and have made slow but
steady progress. What I have now has an opening page with two drop
down boxes. Based on a choice from the first box, the second box is
populated from a mysql table. The values from two boxes are then sent via
a query string to a new page. The 2nd page then uses these two values and
runs a select against the mysql database and creates an html table.

This all runs fine using either Mozilla(on Red Hat 8.0, my development
system) or on Netscape 7.0(Win9x,) but on my older Netscape 4.7 or ie 5.5
the scripts do not run successfully.

Is there a page that lists what features from javascript will work in a
specific browser? Is there a site where I can d/l specific browsers to see
if my page is working for that browser?

Thx Terry

[Jim Ley]

On Thu, 11 Sep 2003 16:57:11 GMT, "Terry A. Haimann"
<te***@yngstr.o ldboy.com> wrote:

Is there a page that lists what features from javascript will work in a
specific browser?
It would be a stunningly useful page, and I've often wondered if
collection of the info etc. could be generated, produce a good set of
test pages which interogate the DOM, and get the submissions collected
by some webpage, I'm still interested in doing it, but it's very hard.
Is there a site where I can d/l specific browsers to see
if my page is working for that browser?

http://browser.evolt.org/ has a lot, but by no means all, there's
millions of 'em.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[DU]

Jim Ley wrote:

On Thu, 11 Sep 2003 16:57:11 GMT, "Terry A. Haimann"
<te***@yngstr.o ldboy.com> wrote:

Is there a page that lists what features from javascript will work in a
specific browser?

It would be a stunningly useful page, and I've often wondered if
collection of the info etc. could be generated, produce a good set of
test pages which interogate the DOM, and get the submissions collected
by some webpage, I'm still interested in doing it, but it's very hard.

That is basically what I submitted and advocated to do with the Gecko
DOM reference 18 months ago. First start to cover what various Mozilla
released versions (Mozilla 1.2, 1.3, 1.4, etc.., NS 7.0, NS 7.1, Camino,
K-meleon, etc..) support, can do, (definitions, parameters, example
section, reference sections,e tc..) and then add a cross-browser support
or compatibility section where you identify if the other most used
browsers support such property, attribute or method. You first should
cover only W3C DOM2 attributes, CSS2 properties and DOM2 methods. If
later you want to add proprietary DOM attributes, methods, then it's
your call, but you should first cover only W3C web standards stuff in
such documentation.

That is what basically a few rare books in javascript do also. It's a
giant task to do: many browsers to cover, new releases all the time.
Such documentation resource would have to start with the most recent
browsers releases.

In a sense, a lot of websites do this also in their own little areas of
expertise. There is no unity or collaboration among all these sites. The
expert knowledge on cross-browser support is scattered everywhere.
Mozilla.org or even webstandards.or g should have taken such challenge
many years ago. It then becomes a source of W3C web standards
evangelization as such reference is promoting standards and educating
people in using a "code once, read anywhere" approach.

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunc...e7Section.html

[Jim Ley]

On Thu, 11 Sep 2003 14:38:38 -0400, DU
<dr*******@ho t-R-E-M-O-V-E-mail.com> wrote:

Jim Ley wrote:
If
later you want to add proprietary DOM attributes, methods, then it's
your call, but you should first cover only W3C web standards stuff in
such documentation.

Hey I wouldn't do it alone, no-one could, it would have to be the
million-monkey and a few monkey minders approach. Basically the
Monkey-Minders would need to develop a site, and a format whereby
people could submit the results of simple DOM tests, develop those
tests aswell, and then present the results. It's probably not that
huge a job for a few Monkey Minders to get done, and I think there's
probably enough Monkeys out there to cover a lot of browsers quickly,
once the basic structure was in place.

If there's enough Monkey Minder interest out there, I don't mind
devoting time, and resources to help setting something up, I have
thought about this before.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[DU]

Jim Ley wrote:

On Thu, 11 Sep 2003 14:38:38 -0400, DU
<dr*******@ho t-R-E-M-O-V-E-mail.com> wrote:

Jim Ley wrote:
If
later you want to add proprietary DOM attributes, methods, then it's
your call, but you should first cover only W3C web standards stuff in
such documentation.

Hey I wouldn't do it alone, no-one could, it would have to be the
million-monkey and a few monkey minders approach.

Of course. And such process would have to be a perpetual process of
updating: new browser releases, new standards, etc..

Many places have done this more or less for certain chunks of web standards.

http://www.richinstyle.com

http://www.westciv.com/style_master/...ort/index.html

http://www.xs4all.nl/~ppk/js/version5.html

http://www.xs4all.nl/~ppk/css2tests/

http://devedge.netscape.com/library/...oldschool.html

http://devedge.netscape.com/library/...selectors.html

Basically the Monkey-Minders would need to develop a site, and a format whereby
people could submit the results of simple DOM tests, develop those
tests aswell, and then present the results. It's probably not that
huge a job for a few Monkey Minders to get done, and I think there's
probably enough Monkeys out there to cover a lot of browsers quickly,
once the basic structure was in place.

What you're talking about has been done by richinstyle.com in the past.
People were submitting their results on tests. Their results were
compiled and based on their browser and browser versions.

"More than three hundred test pages, featuring many thousands of tests,
which will show you just how buggy your browser really is(...)"
http://www.richinstyle.com/
but the site is no longer maintained and is not working.
If there's enough Monkey Minder interest out there,
I'm sure there would be interest for this. Every single day, developers
have to consult some kind of compatibility charts somewhere or
reach/find a documentation resource on a property or method.

I don't mind devoting time, and resources to help setting something up, I have
thought about this before.

Jim.

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunc...e7Section.html

[kaeli]

In article <pa************ *************** *@yngstr.oldboy .com>,
te***@yngstr.ol dboy.com enlightened us with...

Is there a page that lists what features from javascript will work in a
specific browser? Is there a site where I can d/l specific browsers to see
if my page is working for that browser?

Thx Terry

http://www.xs4all.nl/~ppk/js/index.html

All kinds of neat stuff, including browser support for events, css, etc.
One thing it lacks is a decent search.

You can't download different copies of IE on the same windows box in
normal circumstances (it can be done, but it's a huge pain).
Search Google for any other browser version for Netscape, Mozilla,
Opera, etc if you can't find the older browsers on their respective
sites. More than likely someone still has a link up.

-------------------------------------------------
~kaeli~
Hey, if you got it flaunt it! If you don't, stare
at someone who does. Just don't lick the TV screen,
it leaves streaks.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace
-------------------------------------------------

[DU]

kaeli wrote:

In article <pa************ *************** *@yngstr.oldboy .com>,
te***@yngstr.ol dboy.com enlightened us with...

Is there a page that lists what features from javascript will work in a
specific browser? Is there a site where I can d/l specific browsers to see
if my page is working for that browser?

Thx Terry

http://www.xs4all.nl/~ppk/js/index.html

All kinds of neat stuff, including browser support for events, css, etc.
One thing it lacks is a decent search.

It also lacks use of valid markup syntax and use of doctype declaration
in all test pages and all example pages. If you're going to be testing,
verifying the support for DOM 2 attributes, DOM 2 methods and CSS2
properties, then best is to create testcases which are fully compliant
with CSS and using fully valid markup requirements, syntax because this
is where browsers will honor such DOM attributes, methods and CSS
properties at their best and in the fastest way possible. New browser
versions and new updated browsers are all geared at complying with
standards. All the benefits (speed and quality of rendering,
interoperabilit y on web-aware devices, etc...) of these new attributes,
methods, properties are more obvious, are more cleanly noticeable with
pages fully compliant with W3C compliant code.
You can't download different copies of IE on the same windows box in
normal circumstances (it can be done, but it's a huge pain).
Search Google for any other browser version for Netscape, Mozilla,
Opera, etc if you can't find the older browsers on their respective
sites.
sillydog.org has all the Netscape versions. But then, do you really want
to verify, to measure how old, deprecated browsers like NS 4.x comply
with CSS2 or DOM 2??

More than likely someone still has a link up.
-------------------------------------------------
~kaeli~
Hey, if you got it flaunt it! If you don't, stare
at someone who does. Just don't lick the TV screen,
it leaves streaks.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace
-------------------------------------------------

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunc...e7Section.html

[Richard Cornford]

"Jim Ley" <ji*@jibbering. com> wrote in message
news:3f******** ********@news.c is.dfn.de...

On Thu, 11 Sep 2003 14:38:38 -0400, DU
<dr*******@h ot-R-E-M-O-V-E-mail.com> wrote:

If later you want to add proprietary DOM attributes,
methods, then it's your call, but you should first
cover only W3C web standards stuff in such
documentation .

Hey I wouldn't do it alone, no-one could, it would have to
be the million-monkey and a few monkey minders approach.
Basically the Monkey-Minders would need to develop a site,
and a format whereby people could submit the results of simple
DOM tests, develop those tests aswell, and then present the
results. It's probably not that huge a job for a few Monkey
Minders to get done, and I think there's probably enough
Monkeys out there to cover a lot of browsers quickly,
once the basic structure was in place.

If there's enough Monkey Minder interest out there, I
don't mind devoting time, and resources to help setting
something up, I have thought about this before.

Creating some standard and extensive (in terms of browsers covered)
compatibility information strikes me as a worth while exercise to which
I would be happy to contribute (though my preference for doing the
server-side work in Java may not correspond with yours ;-)

It is a huge task and would take a fair bit of planning. For example:-

I would like to see the intention to be comprehensive. Obviously that
would be impossible to achieve initially but it could be planned from
the outset that the tests could be added to indefinitely so the results
could be ever more comprehensive.

The database design needs to be well thought out. That is not an area
where I have any real expertise and the books that I have that cover the
theoretical aspects of database design tend to express their ideas and
examples in terms of commercial applications. I find it hard to see
parallels between the commercial use of databases and the optimum
storage of browser DOM information. What I can see is that the database
design may seriously impact on the usefulness of the results. (It would
be good to be able to present many views of the same information, by
browser, by object, by property, etc.)

While information about the properties of objects is useful another
aspect of browser DOMs is their structure. But that information would be
difficult to express; how would you explain that the firstChild node on
a Gecko browser is likely to be a text Node containing a \n\r pair when
on IE it could be an Element because the \n\r pair has been normalised?
Or that IE attribute nodes exist for all default values of an element
instead of just for provided attributes and that they do not have text
child nodes containing their value.

The DOM structure also tells you things like; the 'document' property of
an IFRAME Element on IE 5.0 is a reference to the document within the
IFRAME while on Opera 7 it is a reference to the document that contains
the IFRAME. Testing which, if either, is the case on an unknown browser
could get quite involved, and worse if you consider doing something
similar for any object reference (possibly overrunning the memory on an
embedded browser in the process).

A general strategy of: Load test page -> execute client-side test ->
post results to server which returns next test page -> execute
client-side tests -> . . . etc. seems reasonable but it raises the
question of how much to test on each page. With the risk of crashing the
browser with almost any test (well, some at least) it would be better if
each page tested as little as possible but with so much to check the
overhead of loading each page might slow the entire process down until
it ceased to be feasible. The more you attempt per page on the client
the more you lose in the event of a crash. I suppose the pages could be
designed to be flexible, first attempting a lot and then splitting
testing up if the first approach did not seem to be working for a
particular browser.

As far as testing goes a good first test (after collecting the browser
type/version information from the user) might be to see if try-catch was
working, with a window.onerror fall-back and a META refresh to let the
server know if neither were viable. (and if that page did not report
back the next attempt with the same browser would be really hard work).

Richard.

[Jim Ley]

On Fri, 12 Sep 2003 00:58:29 +0000 (UTC), "Richard Cornford"
<ri*****@litote s.demon.co.uk> wrote:

"Jim Ley" <ji*@jibbering. com> wrote in message (though my preference for doing the
server-side work in Java may not correspond with yours ;-)
If someone else is doing the work, why would I care ?
It is a huge task and would take a fair bit of planning. For example:-
Planning is all really, the work will be done the million monkeys - I
think they could easily get motivated to executing test-suites. as
they'd only be doing it on a couple of browsers.
The database design needs to be well thought out.
My own preference would be for data to not be primarily stored in an
RDBMS, but stored as RDF documents which are extensible, and can be
loaded up into RDBMS to generate those different views we need.

In some ways the information is similar to test results, and there are
RDF vocabs for that.
While information about the properties of objects is useful another
aspect of browser DOMs is their structure. But that information would be
difficult to express; how would you explain that the firstChild node on
a Gecko browser is likely to be a text Node containing a \n\r pair when
on IE it could be an Element because the \n\r pair has been normalised?
Indeed, these issues are all tough!
A general strategy of: Load test page -> execute client-side test ->
post results to server which returns next test page -> execute
client-side tests -> . . . etc. seems reasonable but it raises the
question of how much to test on each page.
I personally would suggest a downloadable, rather than live online
test-suite would be appropriate, a live test-suite would be tough to
do without frames etc. and there are number of non-frame capable js
capable browsers.
As far as testing goes a good first test (after collecting the browser
type/version information from the user) might be to see if try-catch was
working, with a window.onerror fall-back and a META refresh to let the
server know if neither were viable. (and if that page did not report
back the next attempt with the same browser would be really hard work).

Which is why I think we can ask the user, they're monkeys, they'll
enjoy the work :-)

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[DU]

Richard Cornford wrote:

"Jim Ley" <ji*@jibbering. com> wrote in message
news:3f******** ********@news.c is.dfn.de...

On Thu, 11 Sep 2003 14:38:38 -0400, DU
<dr*******@ho t-R-E-M-O-V-E-mail.com> wrote:

If later you want to add proprietary DOM attributes,
methods, then it's your call, but you should first
cover only W3C web standards stuff in such
documentatio n.
Hey I wouldn't do it alone, no-one could, it would have to
be the million-monkey and a few monkey minders approach.
Basically the Monkey-Minders would need to develop a site,
and a format whereby people could submit the results of simple
DOM tests, develop those tests aswell, and then present the
results. It's probably not that huge a job for a few Monkey
Minders to get done, and I think there's probably enough
Monkeys out there to cover a lot of browsers quickly,
once the basic structure was in place.

If there's enough Monkey Minder interest out there, I
don't mind devoting time, and resources to help setting
something up, I have thought about this before.

Creating some standard and extensive (in terms of browsers covered)
compatibility information strikes me as a worth while exercise to which
I would be happy to contribute (though my preference for doing the
server-side work in Java may not correspond with yours ;-)

It is a huge task and would take a fair bit of planning. For example:-

I would like to see the intention to be comprehensive. Obviously that
would be impossible to achieve initially but it could be planned from
the outset that the tests could be added to indefinitely so the results
could be ever more comprehensive.

The database design needs to be well thought out. That is not an area
where I have any real expertise and the books that I have that cover the
theoretical aspects of database design tend to express their ideas and
examples in terms of commercial applications. I find it hard to see
parallels between the commercial use of databases and the optimum
storage of browser DOM information. What I can see is that the database
design may seriously impact on the usefulness of the results. (It would
be good to be able to present many views of the same information, by
browser, by object, by property, etc.)

While information about the properties of objects is useful another
aspect of browser DOMs is their structure. But that information would be
difficult to express; how would you explain that the firstChild node on
a Gecko browser is likely to be a text Node containing a \n\r pair when
on IE it could be an Element because the \n\r pair has been normalised?

You just need to say so in a "Notes" section like they have and use at
MSDN and like they should have done at Gecko DOM reference (they have a
Notes section but it is always empty). Then you just add in a
"References " section links to relevant documentations covering this
issue. Say like in your case:
"Whitespace in the DOM"
http://www.mozilla.org/docs/dom/technote/whitespace/
Or that IE attribute nodes exist for all default values of an element
instead of just for provided attributes and that they do not have text
child nodes containing their value.

The DOM structure also tells you things like; the 'document' property of
an IFRAME Element on IE 5.0 is a reference to the document within the
IFRAME while on Opera 7 it is a reference to the document that contains
the IFRAME. Testing which, if either, is the case on an unknown browser
could get quite involved, and worse if you consider doing something
similar for any object reference (possibly overrunning the memory on an
embedded browser in the process).
That is no problem at all. This is exactly the kind of info that these
tests should return. Either full compatibility, partial compatibility,
unsupported, etc.. You're not looking for 100% compliance and perfect
support from browser: you're looking for 100% reliable, trustworthy,
verified info about their support of various DOM attributes, methods,
CSS properties: everything public and accessible, therefore updatable
too. In the example you give, you would add in the Notes (or "See also"
section) section a reference to contentDocument attribute.

You need to establish a template of a page delivering the info about
attribute/method/property "x". I like the way MSDN does this:

A definition, then a syntax section, then a parameters section, then a
"return value" section, a "remarks" section, an "example" section,
"standards info" section, an "Applies to" section and a "see also"
section. We would have a "browser support/compatibility" section added.

A general strategy of: Load test page -> execute client-side test ->
post results to server which returns next test page -> execute
client-side tests -> . . . etc. seems reasonable but it raises the
question of how much to test on each page. With the risk of crashing the
browser with almost any test (well, some at least) it would be better if
each page tested as little as possible but with so much to check the
overhead of loading each page might slow the entire process down until
it ceased to be feasible. The more you attempt per page on the client
the more you lose in the event of a crash. I suppose the pages could be
designed to be flexible, first attempting a lot and then splitting
testing up if the first approach did not seem to be working for a
particular browser.

IMO, tests should only be there as an empirical manner to discover which
version of which browser supports which attribute/method/property. In
several cases, one than one testpage would be needed.
Testpage or demo pages should not be a purpose in itself. The info
gathered by such tests and the files built to restitute cross-browser
info about this or that method, property,.. is the purpose of such site.
Web developers of all expertise need a reliable place where they can get
info they're looking for. Right now, everything is scattered on the web
and after a while good sites close too.

One bad example:
Browser Feature Detection
http://devedge.netscape.com/toolbox/...ure-detection/
where all you see is a summary of what browsers support as attribute,
properties, methods... but you never get to see how well those browsers
listed who "support" such attribute, properties, methods *_actually_*
really support well and accordingly these. Only thorough testing would
reveal such info.
As far as testing goes a good first test (after collecting the browser
type/version information from the user) might be to see if try-catch was
working, with a window.onerror fall-back and a META refresh to let the
server know if neither were viable. (and if that page did not report
back the next attempt with the same browser would be really hard work).

Richard.

I think we first need to establish what would be the goals of such site;
public testing and gathering results from testers (the way
richinstyle.com was doing it) is certainly a good idea for starters.

3 more sites:

CSS2 testing (all in French)
http://www.editions-eyrolles.com/css2/tests/index.html

CSS2 Test suite in progress:
http://www.meyerweb.com/eric/css/tests/css2/

zvon.org also has excellent resources: it allows you to learn as you
try/test/verify with your own browser.
E.g.:
http://www.zvon.org/xxl/DOM2reference/Output/index.html
but I don't like the frames, there used to be more interactive examples

zvon.org is more didactic oriented than discovery/empiric oriented like
richinstyle.com was.

DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunc...e7Section.html