- From: Tim Down <timdown@gmail.com>
- Date: Fri, 9 Sep 2011 01:14:44 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Ian Hickson <ian@hixie.ch>, Webapps WG <public-webapps@w3.org>
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