W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: DOM4 not compatible with ACID3 tests

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 8 Sep 2011 17:02:15 -0700
Message-ID: <CA+c2ei9dyCC1T23U9-BHLGf28vt9TTEujkWqLAOqzcL4HCrbVQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Webapps WG <public-webapps@w3.org>
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
Received on Friday, 9 September 2011 00:03:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT