Re: DOM4 not compatible with ACID3 tests

On 9 September 2011 01:02, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Sep 8, 2011 at 1:13 PM, Ian Hickson <ian@hixie.ch> wrote:
>> On Thu, 8 Sep 2011, Jonas Sicking wrote:
>>>
>>> The new DOM-Core specification changes some of the behavior for DocType
>>> nodes to make them act more like all other nodes in the DOM.
>>> Specifically:
>>>
>>> 1. They always have a ownerDocument
>>> 2. They can move between, both using explicit calls to AdoptNode, and
>>> implicit adoption during for example insertBefore
>>> 3. They can be cloned between documents using importNode
>>>
>>> We've written a patch to implement these changes in Gecko (which
>>> resulted in a nice reduction in code). However, ACID3 tests for the old
>>> behavior which is making it a harder decision to check this patch in. As
>>> I understand it this isn't a Gecko specific interaction with ACID3, but
>>> all browsers will see the same loss in ACID3 score if they implement the
>>> new DOM-Core spec.
>>>
>>> Because of this we've been reluctant to land said patch. I would expect
>>> the engines that currently score 100/100 to be even more reluctant to
>>> lose a point or two.
>>>
>>> The obvious fix here seems to me to change ACID3.
>>
>> Yup, that seems reasonable. I'll roll this change into the upcoming
>> general 2011 Update for the acid tests. I understand there are some other
>> things that need fixing too, e.g. SVG-related things. Anne has started a
>> wiki page on the topic here:
>>
>>   http://wiki.whatwg.org/wiki/Acid3
>>
>> It would be great if any other changes people are aware of that would be
>> helpful in simplifying the Web platform could be listed on that page too..
>
> I don't have time to read through all of ACID3 at the moment, but here
> are some of the things that I think it should *not* rely on:
>
> Attribute nodes in any shape or form. There are some really big
> changes being proposed and as far as I know it's currently wholly
> unknown what changes will be compatible with the web, and which won't.
> So most likely experimentation is going to be needed here which means
> deploying various solutions and see how much breaks. If people aren't
> willing to deploy solutions that reduce the ACID3 score, then that
> significantly reduces our ability to find a minimal set of required
> APIs.
>
> Anything with mutation events. We want to deprecate them entirely.
>
> Anything using the following functions which seem useless or otherwise
> have been discussed to be removed:
>  Node.isSameNode
>  Text.replaceWholeText
>
> Possibly also these function:
>  Node.isEqualNode
>  Node.lookupPrefix
>  Node.lookupNamespaceURI
>  Node.isDefaultNamespace
>  Text.wholeText
>
> We're likely not going to be removing all of this, but none of them
> seem like high priority for moving the web forward and so testing them
> in ACID3 doesn't seem to have a purpose. And if ACID3 was the only
> reason we kept them, then that would be actively holding the web back.
> And given the hurdle for changing ACID3, and that we seem to be
> versioning it by years, I'd rather not be conservative about removing
> things now that we have the opportunity.
>
> Then there is of course the whole SVG Fonts thing. I'll defer to the
> SVG WG here, but mozilla's opinion on SVG fonts is pretty well known I
> assume?
>
> / Jonas

I'd suggest the DOM Range tests in ACID3 could be modified to test
against the newer WHATWG Range spec, which clears up some ambiguities
in the DOM 2 Range spec (there's one about what happens to Range
boundaries after a particular insertNode call that I emailed
acid3feedback@webstandards.org about over a year ago). There's also
some attribute node tests in there.

Tim

Received on Friday, 9 September 2011 12:31:31 UTC