Re: Status check

Dimitris Dimitriadis wrote:
> All,
> 
> Since there's not been that much activity around the DOM TS lately, I 
> wanted to get a picture of what people are working on currently. Last 
> time we did a roll call, activity was taking place in:
> 
> 1. Framework issues (Bob requested some feedback on browser behaviour)
> 2. HTML test sanity check
> 3. Licensing issues (Philippe sent a draft for a new grant of license).
> 
> On 1, I think we need to speed up thing some more. Bob, Edward, please 
> forward to the list any requests you have for specific issues. Also, in 
> continuation to the emails I sent to this list and company 
> representatives (Netscape and Microsoft) asking for help on the 
> framework, I sent a similar request to the Microsoft DOM WG 
> representative in order to ascertain IE functionality in connection with 
> the DOM TS (in particular IE for Mac that doesn't work that well).
> 
> One reason we need to speed things up is that a series of DOM WG 
> documents need to be advanced in the W3C document release pipeline. 
> Also, for DOM Level 3 to become a recommendation, prior levels need to 
> have been covered by a TS. This means that we need to release the full 
> DOM Level 1 TS, with HTML tests and the new framework, as soon as possible.
> 

[bc] Edward and I are getting ready to release jsUnit 1.3.0. We are 
currently working on the documentation however you can perform an 
anonymous check out of the current source. See 
<http://sourceforge.net/cvs/?group_id=28041> for information on CVS 
access. Feel free to quiz me if you have specific questions regarding 
how to use this version of jsUnit.

We have made several minor changes to jsUnit since we announced the 
alpha and posted links to it on bclary.com. the |preTest| functionality 
has been renamed |setUpPage| to better reflect it's use and to conform 
better to jsUnit's ancestry.

A minor change was made to the jsUnitTestSuite class to better support 
Konqueror 3.

The cross browser debugging script 
<http://bclary.com/xbProjects-docs/xbDebug/> has been introduced into 
jsUnit to help debug jsUnit on browsers which do not have Interactive 
Debuggers. To invoke xbDebug in an http:// based test environment, 
simply include debug in the url to the testRunner.html as in 
<http://bclary.com/jsunit/jsunit/testRunner.html?debug>

It is now possible to specify a query string to the http based version 
of jsUnit which can specify which test page to execute, and can specify 
parameters which the test page can use in setting up it's test 
environment. This could be used in the DOM TS to specify which test page 
to load, which data documents to be used, which method to use for data 
document loading, etc. For an example of this functionality please see 
<http://bclary.com/xbProjects-docs/xbStyle/tests/>. [and yes I am aware 
there are bugs in xbStyle :-) ]

Current browser support:

Mozilla/Gecko/Netscape 6 (all platforms)
========================================
Supports test function auto-discovery of inline scripts in test pages, 
test function declaration via exposeTestFunctionNames() in both inline 
and external scripts, and IFRAME data document loading over http:// 
connections.

Mozilla/Gecko/Netscape 6 currently has a bug where |load| events are not 
fired for file:/// based IFRAME content which means that 
Mozilla/Gecko/Netscape 6 currently can not use the IFRAME based document 
loader for file:/// based tests. However the IFRAME based document 
loader does work fine for http:// based tests.

Internet Explorer 5.5+ on Windows
=================================
Supports test function auto-discovery of inline scripts in test pages, 
test function declaration via exposeTestFunctionNames() in both inline 
and external scripts, and IFRAME data document loading over http:// and 
file:/// connections.

Internet Explorer 5.14 on Macintosh 9.1
=======================================
Does not support test function auto-discovery due to a difference in 
IE5/Macintosh's implementation of the script object versus the Windows 
implementation but does support test function declaration via 
exposeTestFunctionNames().

Does not support the IFRAME based document loader.

IE5/Macintosh does support the other basic functionality of jsUnit.

I have not received any feedback on possible approaches to improve 
support in jsUnit for IE5/Macintosh.

Konqueror 3
===========
Does not support test function auto-discovery.

Does not support the IFRAME based document loader.

Harri Porten is investigating the possibilities of adding such support 
to Konqueror at a later time.

Opera 5/6
=========
Does not run jsUnit due to limitations in it's implementation of 
ECMAScript and DOM 0. See <http://www.opera.com/docs/specs/> for more 
details.

General Support
===============
As browsers improve their support for HTML 4.01, ECMAScript and DOM 0, 
they should be able to execute jsUnit without change.  I believe 
jsUnit's target of ECMAScript 262 3rd edition, HTML 4.01, and DOM 0 
support is a reasonable one which can be achieved by any web browser 
which can reasonably hope to have a chance of executing the DOM TS. 
However, if the basic functionality of jsUnit can be extended to 
additional browsers without degrading the basic philosophy of universal 
support regardless of vendor, then I am open to suggestions. 
Unfortunately, I have not received significant feedback or suggestions 
which would allow me to extend the support of jsUnit to other browsers.

Considering the wide spread availability of web servers for developer's 
work stations, I think the use of http:// based test page urls 
containing test parameters out weigh any use of jsUnit in a file:/// 
based test environment, especially with regard to the DOM TS which has 
particular need of this ability to drive test pages.

Implications for the DOM TS
===========================

I do not believe that the patching process that was used in earlier 
versions of the DOM TS will be required for jsUnit 1.3.0. Instead, the 
use of exposeTestFunctionNames() will not only extend the number of 
browsers potentially supported, but will allow external scripts to be 
used in test pages and will obviate the need to 'inject' tests into test 
pages. This will also increase the ability of the DOM TS to take 
advantage of subsequent releases of jsUnit with little or no change to 
the DOM TS itself.

The use of the IFRAME based document loader will allow arbitrary web 
browsers to use the DOM TS to test their implementations.

The use of query string based parameters will allow customization of 
tests, reuse of scripts and data files, and other approaches which will 
allow additional proprietary document loading methods to be chosen 
without excluding third party web browsers which only support the basic 
ECMAScript/HTML 4.01/DOM 0 requirements of jsUnit.

I believe that jsUnit document loader approach will easily support 
loading multiple data documents per test page.

jsUnit 1.3.0 is not a drop in replacement for jsUnit 1.2.6 and will 
require some reworking of the build process and test page design in 
order to be reused in the DOM TS.

/bc

Received on Tuesday, 21 May 2002 00:25:12 UTC