browsers and javascript

Discussion in 'Javascript' started by Terry A. Haimann, Sep 11, 2003.

  1. 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
     
    Terry A. Haimann, Sep 11, 2003
    #1
    1. Advertising

  2. Terry A. Haimann

    Jim Ley Guest

    On Thu, 11 Sep 2003 16:57:11 GMT, "Terry A. Haimann"
    <> 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/
     
    Jim Ley, Sep 11, 2003
    #2
    1. Advertising

  3. Terry A. Haimann

    DU Guest

    Jim Ley wrote:

    > On Thu, 11 Sep 2003 16:57:11 GMT, "Terry A. Haimann"
    > <> 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/doctorunclear/Netscape7/Netscape7Section.html
     
    DU, Sep 11, 2003
    #3
  4. Terry A. Haimann

    Jim Ley Guest

    On Thu, 11 Sep 2003 14:38:38 -0400, DU
    <> 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/
     
    Jim Ley, Sep 11, 2003
    #4
  5. Terry A. Haimann

    DU Guest

    Jim Ley wrote:
    > On Thu, 11 Sep 2003 14:38:38 -0400, DU
    > <> 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/academy/browser_support/index.html

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

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

    http://devedge.netscape.com/library/xref/2003/css-support/css1/oldschool.html

    http://devedge.netscape.com/library/xref/2003/css-support/css2/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/doctorunclear/Netscape7/Netscape7Section.html
     
    DU, Sep 11, 2003
    #5
  6. Terry A. Haimann

    kaeli Guest

    In article <>,
    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
    -------------------------------------------------
     
    kaeli, Sep 11, 2003
    #6
  7. Terry A. Haimann

    DU Guest

    kaeli wrote:

    > In article <>,
    > 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/doctorunclear/Netscape7/Netscape7Section.html
     
    DU, Sep 11, 2003
    #7
  8. "Jim Ley" <> wrote in message
    news:...
    >On Thu, 11 Sep 2003 14:38:38 -0400, DU
    ><> 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.
     
    Richard Cornford, Sep 12, 2003
    #8
  9. Terry A. Haimann

    Jim Ley Guest

    On Fri, 12 Sep 2003 00:58:29 +0000 (UTC), "Richard Cornford"
    <> wrote:

    >"Jim Ley" <> 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/
     
    Jim Ley, Sep 12, 2003
    #9
  10. Terry A. Haimann

    DU Guest

    Richard Cornford wrote:
    > "Jim Ley" <> wrote in message
    > news:...
    >
    >>On Thu, 11 Sep 2003 14:38:38 -0400, DU
    >><> 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/tools/2001/feature-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/doctorunclear/Netscape7/Netscape7Section.html
     
    DU, Sep 12, 2003
    #10
  11. Terry A. Haimann

    bubipoo Guest

    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" <> wrote in message
    news:p...
    > 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
     
    bubipoo, Sep 12, 2003
    #11
  12. Terry A. Haimann

    Jim Ley Guest

    Javascript compatibility resource (was Re: browsers and javascript)

    On Thu, 11 Sep 2003 17:54:01 GMT, (Jim Ley) wrote:

    >On Thu, 11 Sep 2003 16:57:11 GMT, "Terry A. Haimann"
    ><> 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/
     
    Jim Ley, Sep 13, 2003
    #12
  13. "Jim Ley" <> wrote in message
    news:...
    >On Fri, 12 Sep 2003 00:58:29 +0000 (UTC), "Richard Cornford"
    ><> 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.
     
    Richard Cornford, Sep 13, 2003
    #13
  14. Terry A. Haimann

    Jim Ley Guest

    On Sat, 13 Sep 2003 01:12:48 +0000 (UTC), "Richard Cornford"
    <> wrote:

    >"Jim Ley" <> 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/
     
    Jim Ley, Sep 13, 2003
    #14
  15. "Jim Ley" <> wrote in message
    news:...
    > On Sat, 13 Sep 2003 01:12:48 +0000 (UTC), "Richard Cornford"
    > <> 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.
     
    Richard Cornford, Sep 16, 2003
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?dmlrdG9yOTk5MA==?=

    Refreshing client browsers (with javascript from asp.net code)

    =?Utf-8?B?dmlrdG9yOTk5MA==?=, Feb 22, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    525
    =?Utf-8?B?dmlrdG9yOTk5MA==?=
    Feb 22, 2005
  2. El Kabong

    Browsers, browsers! Quo vadis?

    El Kabong, May 11, 2007, in forum: HTML
    Replies:
    23
    Views:
    943
    dorayme
    May 13, 2007
  3. Kate Riley

    disable JavaScript in newer browsers

    Kate Riley, Jul 23, 2003, in forum: Javascript
    Replies:
    2
    Views:
    85
    Kate Riley
    Jul 23, 2003
  4. Jack
    Replies:
    0
    Views:
    89
  5. Manu Ashok
    Replies:
    1
    Views:
    100
    Michael Winter
    Apr 2, 2004
Loading...

Share This Page