Richard Cornford wrote:[color=blue]
> "Jim Ley" <jim@jibbering.com> wrote in message
> news:3f60c70c.111830193@news.cis.dfn.de...
>[color=green]
>>On Thu, 11 Sep 2003 14:38:38 -0400, DU
>><drunclear@hot-R-E-M-O-V-E-mail.com> wrote:
>>[color=darkred]
>>>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.[/color]
>>
>>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.[/color]
>
>
> 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?[/color]
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/
[color=blue]
> 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).[/color]
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.
[color=blue]
>
> 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.
>[/color]
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.
[color=blue]
> 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.
>
>[/color]
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 
