[webkit-dev] DOM L1 Core tests analysis
mjs at apple.com
Mon Jul 25 21:00:47 PDT 2005
On Jun 22, 2005, at 12:29 PM, Curt Arnold wrote:
> I was able to drop the self-hosted HTML tests for DOM Level 1 Core
> into the WebCore/layout-tests directory. The first
> run created the "-expected.txt" files and on a second run all the
> tests "succeeded" (in the sense that the response had
> not changed from the first run). Doing a grep on the expected
> files for "failure" and "error" identified the following tests
> which I have added a brief analysis of the cause of the failure.
I much-belatedly tried dropping in the Level 1 Core tests (at least
the HTML version) and they seem to do pretty well as layout tests. I
get 193 success, 45 failure. One thing that concerns me, though, is
that some of the tests that Safari fails appear to be failed by all
browsers that I could get my hands on. For example, Mac IE, Firefox
and Opera all fail this test:
Every browser I tried failed at least a couple dozen of the tests,
though not all failed the exact same set.
> Safari seems to have serious issues with the self-hosted XHTML
> tests which appears to be due to a failure to pick up the entity
> declarations in the document type declaration, however I haven't
> tried to track those down. I don't know whether I should expect
> WebKit to have any support for XHTML.
It does have support, but we don't really do entities.
> I will later see what happens when the L2 Core and L2 HTML self-
> hosted tests are dropped in.
> Manipulation of attributes and attribute child nodes appears to be
> the most significant problem area, however these are problem areas
> for many implementations. The apparent lack of an implementation
> for Document.cloneNode causes all of the multi-document tests the
> self-tests implementation depends on that method to create the
> second document.
That sounds like a serious problem - is there any way to change the
tests to get a second document in a more portable way? Perhaps they
could use a frame to hold a second document. The spec says that
behavior of cloneNode() on a Document is implementation-dependent,
and no browser supports it, so it seems like a bad idea to rely on it.
More information about the webkit-dev