Re: DOM4 not compatible with ACID3 tests
On Thu, Sep 8, 2011 at 8:14 PM, Tim Down wrote: > 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 > acid3feedb...@webstandards.org about over a year ago). There's also > some attribute node tests in there. The insertNode issue is noted in the current spec, which has been merged into DOM4 (formerly known as DOM Core, formerly known as Web DOM Core): http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-range-insertnode DOM 2 Range and Gecko disagree with IE, WebKit, Opera, and old versions of Acid3. Apparently this originated as an Acid3 bug that all non-Gecko engines picked up to pass Acid3, which was later changed to accept both behaviors. I've spoken with smaug (Olli) about this before. My opinion is that the spec should change to match the IE/WebKit/Opera behavior unless at least one of them is willing to change, because that's the behavior that we'll more easily get interop on. It's possible you were thinking of a different insertNode issue, though.
Re: DOM4 not compatible with ACID3 tests
>> Anything using the following functions which seem useless or otherwise >> have been discussed to be removed: >> Node.isSameNode >> Text.replaceWholeText > > Could not find the former, noted the latter. I did not know by the way we > wanted to remove isSameNode(). Works for me. a.isSameNode(b) is the same as a == b and a === b when both are Nodes. It's a very silly function. / Jonas
Re: DOM4 not compatible with ACID3 tests
On 9 September 2011 01:02, Jonas Sicking wrote: > On Thu, Sep 8, 2011 at 1:13 PM, Ian Hickson 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 acid3feedb...@webstandards.org about over a year ago). There's also some attribute node tests in there. Tim
Re: DOM4 not compatible with ACID3 tests
On Fri, 09 Sep 2011 02:02:15 +0200, Jonas Sicking wrote: Attribute nodes in any shape or form. [...] Noted on the wiki. Anything with mutation events. We want to deprecate them entirely. Could not find any tests for these. (By deprecate you mean remove, right? :-)) Anything using the following functions which seem useless or otherwise have been discussed to be removed: Node.isSameNode Text.replaceWholeText Could not find the former, noted the latter. I did not know by the way we wanted to remove isSameNode(). Works for me. Possibly also these function: Node.isEqualNode Node.lookupPrefix Node.lookupNamespaceURI Node.isDefaultNamespace Text.wholeText These were not present in Acid3. 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? David Baron added SVG Fonts. I added SVG Animation (which was also discussed by the SVG WG and CSS WG). Both as potential items. See: http://wiki.whatwg.org/wiki/Acid3 -- Anne van Kesteren http://annevankesteren.nl/
Re: DOM4 not compatible with ACID3 tests
On Thu, Sep 8, 2011 at 1:13 PM, Ian Hickson 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
Re: DOM4 not compatible with ACID3 tests
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. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: DOM4 not compatible with ACID3 tests
On 09/08/2011 10:23 AM, Jonas Sicking wrote: Hi All, 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. It would suck if the ACID3 tests are what is holding the web back. However so far I haven't been able to get a response from the parties that can make that happen. Additionally, ACID3 contains some attribute-node tests which runs a big risk of making it hard to implement other parts of DOM-Core. My understanding is that in theory it's possible to implement the DOM-Core spec if it's implemented exactly as currently specced. But if that turns out to break too many websites right now, then we won't be able to experiment with alternative strategies since they would break ACID3. Again, I've poked the people that can change ACID3 about this too, but so far without success. I also haven't checked, but if ACID3 is testing mutation events, then that will likely hold back deprecating them from the web too. Should we change the course here for the DOM4 spec and declare ACID3 as set in stone No. and anything that breaks it is to be considered not web compatible? This would seem like a ridiculous solution to me, but if browsers won't implement changes that break ACID3, which I strongly suspect is the case, and if ACID3 can't be changed, then I don't really see much alternative. If ACID3 can't be changed, let's just create ACID4 which overrides ACID3 :p -Olli / Jonas
