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.
Hi Curt,
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:
html/level1/core/hc_attrappendchild1.html
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.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
