W3C home > Mailing lists > Public > www-dom-ts@w3.org > February 2002

Re: Synchronous Load method for Mozilla and Internet Explorer

From: Robert Clary <bclary@netscape.com>
Date: Sun, 24 Feb 2002 15:03:18 -0500
Message-ID: <3C794706.2080707@netscape.com>
To: Curt Arnold <carnold@houston.rr.com>
CC: www-dom-ts@w3.org
Unfortunately, Opera is pretty bad when it comes to dynamically changing 
content and many of it's implementations of the DOM Style interfaces are 
rather unique to say the least. :-)  Several DOM interfaces such as 
Document.createElement are defined in Opera 6 however they are not 
implemented as far as I can tell.  If this is incorrect I would love to 
be educated since I have several scripts which I would love to include 
support for Opera.

The current jsUnit depends upon HTMLElement.innerHTML to update it's 
status areas which pretty much limits it to using IE and Mozilla. I 
think that since we can not rely on the DOM to change the test harness 
content dynamically we should allow browsers which do not support 
innerHTML to use basic DOM 0 approaches such as document.write to 
another window or frame.

You can test for the existence of innerHTML in HEAD before page onload 
using something like:

if (document.documentElement && 
typeof(document.documentElement.innerHTML) != 'undefined)
{
  // you have innerHTML
}

After the body tag or after page load you can use

if (document.body && typeof(document.body.innerHTML) != 'undefined)
{
  // you have innerHTML
}

Of course this depends upon the browser supporting the necessary 
properties besides innerHTML.

I do not know much about Konquerer except that I get reports from users 
that it does support a good deal of the DOM. I unfortunately do not have 
a version I can test with.

The approach that I would recommend except where absolutely necessary, 
is to use object detection as in the above and to provide fall back code 
for browsers which may not support the non-standard features we might 
wish to use to actually operate the testframe.  

This can also be used to make sure that browsers which are able to do 
so, will execute the same code paths in the tests suite itself. For 
example, instead of testing the browser version to determine if a 
Document can be created, testing for the existence of 
Document.implementation.

Object detection and single code paths in the test suites promotes the 
widest range of possible browsers. All they have to do is implement the 
appropriate parts of the DOM, document.implementation, for example and 
we can allow them to create their own documents rather than relying on 
features of particular browsers which may not be available in general.

I have begun working on modifying jsUnit to support browsers other than 
Mozilla and IE  however have not achieved success as of yet.  

I like the idea of the test suite runner. It would be nice to allow a 
'pure' DOM test version which used a single code path and could be used 
to directly compare different implementations.

Bob
Received on Sunday, 24 February 2002 15:08:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:04 UTC