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.oldboy.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.javascript FAQ - http://jibbering.com/faq/

[DU]

Jim Ley wrote:

On Thu, 11 Sep 2003 16:57:11 GMT, "Terry A. Haimann"
<te***@yngstr.oldboy.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.org 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*******@hot-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.javascript FAQ - http://jibbering.com/faq/

[DU]

Jim Ley wrote:

On Thu, 11 Sep 2003 14:38:38 -0400, DU
<dr*******@hot-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.oldboy.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.oldboy.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,
interoperability 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.cis.dfn.de...

On Thu, 11 Sep 2003 14:38:38 -0400, DU
<dr*******@hot-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*****@litotes.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.javascript FAQ - http://jibbering.com/faq/

[DU]

Richard Cornford wrote:

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

On Thu, 11 Sep 2003 14:38:38 -0400, DU
<dr*******@hot-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?

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

[bubipoo]

even a suggestion from the patrons here as to what they see as a minimum
browser standard to work to. eg: as long as it runs on browser ABC #123 the
large majority of surfers will be ok..
this browser would be handy to have installed as a test bed.


"Terry A. Haimann" <te***@yngstr.oldboy.com> wrote in message
news:pa****************************@yngstr.oldboy. com...

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 17:54:01 GMT, ji*@jibbering.com (Jim Ley) wrote:

On Thu, 11 Sep 2003 16:57:11 GMT, "Terry A. Haimann"
<te***@yngstr.oldboy.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.

Initial thoughts at
<URL: http://jibbering.com/discussion/js-doc-system.1 >

If there's enough interest in being the monkey minders, I'll start
working on the next step, feedback to me, or the list...

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

[Richard Cornford]

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

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

<snip>

It is a huge task and would take a fair bit of planning. ...

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.

I think that there would have to be more than just planning. The monkeys
need to get the test-suites, they may not actually run on their browser
but I think that there is more chance that they would be motivated if
they got more to start with than just a list of things to test and a
format for the results.

<snip>

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.

<snip>

OK. There seem to be plenty of existing APIs for RDF and it's an XML
format so there is lots of potential for extracting information from RDF
in all sorts of ways. I was about to post this when I noticed your
latest post and the jibbering.com URL reference. I don't have time to
respond to that tonight (must sleep now).

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.

<snip>

A downloadable is a way to go. I am intrigued by what exactly you have
in mind as web browsers seem to be set up for HTTP communication and
have very restricted file writing abilities (usually) so I still see
this as involving something taking the server role (even if it is
running locally) and receiving results from the browser and fileing
them.

For the DOM scanning that I have been doing (which is about taking a
test page and recording the entire DOM structure and all of the
properties, current values and property types for each object in that
DOM for comparison between tested browsers) I use a local Java
application server (either running on the local machine or on the local
network). I have been uploading the results as a query string attached
to a new Image src. It doesn't always work, or work the same so I am
building up a collection of data uploading objects with slightly
different strategies, some use Image.onload some have to use setTimeout
as onload doesn't work, and for IceBrowser I had to write a version that
opened a new window and set the information on a query string for
window.location. So far I have been able to avoid using hidden frames
(that would invalidate my tests anyway as it would alter the DOM
structure) or IFRAMEs.

The problem with my approach is that, because I am attempting to read
everything in one session, if reading properties (or even a particular
property) on one object can crash the browser I am bound to hit that
property/object. It has usually taken about a week of (intermittent)
work to add special exclusion rules for particular browsers to avoid
things like crashes and get a full set of results. For example, on
IceBrowesr attempting to read any properties on any object that would
type convert to a string starting "[Ljava." Would crash the browse. As
you can guess from the text that rule is very specific to IceBrowser.

I would see that as the task for the million monkeys, given a test
script that works on a range of known browsers (probably with some built
in mechanism for the type of exclusion rules that may be anticipated as
required) to modify that script so that it will work on their test
browser.

Richard.

[Jim Ley]

On Sat, 13 Sep 2003 01:12:48 +0000 (UTC), "Richard Cornford"
<ri*****@litotes.demon.co.uk> wrote:

"Jim Ley" <ji*@jibbering.com> wrote in message

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.
I think that there would have to be more than just planning. The monkeys
need to get the test-suites, they may not actually run on their browser

I was hoping we could get the hundred monkeys to develop the
test-suite too - so there's just a guideline of how to create, then
they're just reviewed for inclusion by the monkey-minders.
A downloadable is a way to go. I am intrigued by what exactly you have
in mind as web browsers seem to be set up for HTTP communication and
have very restricted file writing abilities (usually) so I still see
this as involving something taking the server role (even if it is
running locally) and receiving results from the browser and fileing
them.

The problem I see with live is as you note the problem with coping
with crashes etc. in the client, I was imagining a multi-window
approach, where the results of the test go on in one window, and the
user can update the reports in the other - no communication between
the two absolutely required (but makes things easier where it is
possible) the windows could easily even be on different machines, that
would just make it more effort for the monkey.

I don't really know, I hadn't thought about it enough. Obviously it
will end with an HTTP-post, but I also wanted the reports to be able
to be editted in a text editor etc. as some people will prefer that,
and make it easier to break up testing than a live wizard interface.
Anyway I don't really know, which is why the big problem is the
initial planning.

The DOM test-suite is one approach for some of it I think, but
different parts have different issues to be tested - event handling
different from core javascript.

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

[Richard Cornford]

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

On Sat, 13 Sep 2003 01:12:48 +0000 (UTC), "Richard Cornford"
<ri*****@litotes.demon.co.uk> wrote: <snip>

I think that there would have to be more than just planning.
The monkeys need to get the test-suites, they may not
actually run on their browser

I was hoping we could get the hundred monkeys to develop the
test-suite too - so there's just a guideline of how to create,
then they're just reviewed for inclusion by the monkey-minders.

I think you can expect people to want to extend the test-suite (they may
want to test aspects dear to their personal interests that may not have
been covered by others) and they would need guidelines if their
contributions were to become part of a consistent whole. But I think
that we cannot duck having to implement at least some of the test-suite.
Guidelines are easier to follow when you have concrete examples to
follow and there is noting like attempting to implement guidelines to
show up their weaknesses.

<snip>... , but I also wanted the reports to be able to be editted
in a text editor etc. as some people will prefer that, and
make it easier to break up testing than a live wizard interface.
Anyway I don't really know, which is why the big problem is the
initial planning.

<snip>

As you note at <URL: http://jibbering.com/discussion/js-doc-system.1 >
"The biggest problem to solve before any real work can begin, is the
format of the test-results, ...". RDF seems to fulfil your text editor
requirement (just about) and to provide the required flexibility. Your
more specific proposal of EARL (Evaluation and Report Language 1.0 <URL:
http://www.w3.org/TR/EARL10/ > (an application of RDF)) strikes me as
suitable for the final stage of asserting the outcome of the tests
(though it might need the extension of describing the "severity" of a
pass [1]). (incidentally, my plans for the early part of this week have
been put back a day so I had the chance to read the EARL documents
today.)

[1] The "severity" of a pass for DOM compliance of, for example -
document.createElement("input"); - might require that the resulting
object implement the DOM core Element interface (and Node by extension)
and the HTML DOM HTMLInputElement interface but the default values of
properties of the HTMLInputElement may not be set consistently. The -
type - property should default to "text" according to the HTML DTD but
would it be grounds for claiming non-conformance with DOM if it
defaulted to "" as it would be usual practice to assign a value to -
type - immediately after creating the element (even if that assignment
was "text") and the browser implementation may decide to hold of
defaulting un-set values until the node was inserted into a document.
Giving practical conformance if not quite 100%.

The EARL working draft depicts its role in the expressing of test
results with a diagram like (best viewed with a fixed width font):-

___________________________
| |
| Reuirements Capture |
|_________________________|
||
\/
___________________________
| |
| Test Specification |
|_________________________|
||
\/
___________________________
| |
| Test |
|_________________________|
||
\/
___________________________
| | /|_ _
| Test Result | < _ EARL _|
|_________________________| \|
||
\/
___________________________
| |
| Collate Results |
|_________________________|
||
\/
___________________________
| |
| Analyze Results (query) |
|_________________________|
||
\/
___________________________
| |
| Present Results |
|_________________________|

- which places it as an expression of the results and facilitating easy
collation and analysis. But I think that there is more to which a formal
description could be applied and maybe more to record during the
testing.

Expanding the middle of the EARL diagram (based on a personal perception
of the situation (possibly misguided)):-

...
||
\/
___________________________
| |
| Test Specification |
|_________________________|
|| ||
\/ \/
___________ ____________
| | | |
| Test | | Test |
|Procedure| | Criteria |
|_________| |__________|
|| ||
\/ ||
___________ ||
| | ||
| Apply | ||
| Test | ||
|Procedure| ||
|_________| ||
|| ||
\/ ||
__________ ||
| | ||
| Raw | ||
|Results | ||
|________| ||
|| ||
\/ \/
___________________________
| |
| Application of Criteria |
|_________________________|
||
\/
___________________________
| | /|_ _
| Test Result | < _ EARL _|
|_________________________| \|
||
\/
...

EARL already expects a specification of "Test Criteria" which I think
could benefit form a formal description that could be referenced in the
test results. A formal specification of test criteria would allow
alternative test methods to be applied, including entirely manual
testing and allow the results produced to be collated with results for
the same criteria generated by other methods.

I also think it might be worth defining a format for raw test result
storage (there is potentially a lot of extra information about the
browser in those results as they represent what actually happened).

Another aspect of the procedure that might need to be formally expressed
is the dependency of one test on browser/JavaScript features that may be
expressed as the results of another test. For example, while testing a
script in the Palm OS Web Browser 2.0 last night I noticed that its ECMA
Script implementation fails to follow the algorithm for the production
LogicalORExpression (ECMA 262 3rd Ed. Section 11.11) in that - var x =
"" || {}; - will assign a boolean value to the x variable instead of the
specified object. That means that a test script for a more involved
aspect of DOM implementation that uses a binary logical OR operator may
produce a false negative result when the apparent failure could result
from a flawed ECMA script implementation.

Knowing that a test procedure (script) was dependent on a set of other
features would allow either a different script to be used or a low
confidence to be assigned to failure in the event that tests for the
features depended upon had already been failed (or were subsequently
failed).

That observation about the binary logical operators makes me think that
checking the ECMA Script implementation should precede the DOM testing.

So:-

var a = "";
var b = {};
var c = a||b;
if(c){
if(c === b){
c = b||a;
if(c && (c === b)){
//full ECMA 262 3rd Ed.
//section 11.11 LogicalORExpression
//algorithm implementation.
}
}
if(typeof c == "boolean"){
//partial implementation
//producing boolean results.
//good enough for most tests.
}
}
// else total failure of binary logical OR operator.

But that test is in turn dependent on:
1. variable creation and assignment.
2. String and Object literals.
3. if statements.
4. The binary logical AND operator.
5. The identity operator.
6. The typeof operator.
7. Automatic type-conversion.

It must be theoretically possible for a script's dependence on ECMA
implementation to be automatically determined but the Web Browser 2.0
failure highlights the main problem with that as an automatic dependence
determining program would have to discriminate between scripts that
require a full implementation and scripts for which an implementation
that erroneously returned a boolean value would be good enough.

Richard.