DOM4 not compatible with ACID3 tests
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 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. / Jonas
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
[Bug 14083] New: status box is too big. wrong id?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14083 Summary: status box is too big. wrong id? Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#cro ssDocumentMessages OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Messaging (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, sim...@opera.com, public-webapps@w3.org Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/web-messaging.html Multipage: http://www.whatwg.org/C#crossDocumentMessages Complete: http://www.whatwg.org/c#crossDocumentMessages Comment: status box is too big. wrong id? Posted from: 85.227.153.57 by sim...@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.9.168 Version/11.51 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 14084] New: Hi! Returning a null from getItem() if the key does not exist is downright semantically wrong. null is a full-fledged value which can be serialized (JSONed), and is NOT the value we
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14084 Summary: Hi! Returning a null from getItem() if the key does not exist is downright semantically wrong. null is a full-fledged value which can be serialized (JSONed), and is NOT the value we get if we do: var x = myObject.someUnknownProperty; In that case we get t Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/webstorage/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Hi! Returning a null from getItem() if the key does not exist is downright semantically wrong. null is a full-fledged value which can be serialized (JSONed), and is NOT the value we get if we do: var x = myObject.someUnknownProperty; In that case we get the 'undefined' value, and that is what the return value of getItem() _should_ be if the item is not found. undefined is not serializable (JSONable) and is never a valid value, whereas null is sometimes an application-/domain-valid value. Returning null from getItem() is ambiguous in the case of an application using null as a placeholder or a falsy value. Returning undefined is unambiguous. - stephan beal (sgb...@googlemail.com) Posted from: 194.246.122.11 User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.218 Safari/535.1 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 14086] New: When performing AJAX type queries, they are already asynchronous and already occur in another thread. However, I have found that parsing the XML reply and converting that to a repr
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14086 Summary: When performing AJAX type queries, they are already asynchronous and already occur in another thread. However, I have found that parsing the XML reply and converting that to a representation usable by the javascript application can result in freezes to t Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Workers (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://www.w3.org/TR/2011/WD-workers-20110901/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: When performing AJAX type queries, they are already asynchronous and already occur in another thread. However, I have found that parsing the XML reply and converting that to a representation usable by the javascript application can result in freezes to the GUI for large amounts of data. When I tried to put the processing of the AJAX reply in a web worker (I tried to put the XML processing and marshaling to javascript amenable format in a web worker), I found that the web worker could not use the DOM Parser and the javascript data assembled by the web worker had to be converted to a string to be pushed back via a message to the main thread. So web workers do not appear to solve what appears to be a fairly common problem - a delay processing alot of XML data from the server. The ability to assemble data in a handy format in one thread and then give it to the main thread, without incurring a time penalty to essentially recreate the data in the main thread, would be nice to have. It appears what we have now are multiple processes rather than threads (no data sharing). Why not modify the core javascript language to add threads?(Like C++0x or Java). Why can't the web workers use an XML parser? Posted from: 199.89.158.132 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[EventSource] Question on event type
Hi all, Trying to implement a test for eventsource, it's unclear to me in the sequence below, how item 4 is to be implemented and coded for by a developer: (extract from http://www.w3.org/TR/eventsource/) When the user agent is required to *dispatch the event*, then the user agent must act as follows: 1. If the *data* buffer is an empty string, set the *data* buffer and the *event name* buffer to the empty string and abort these steps. 2. If the *data* buffer's last character is a U+000A LINE FEED (LF) character, then remove the last character from the *data* buffer. 3. Otherwise, create an event that uses the MessageEvent interface, with the event name message, which does not bubble, is not cancelable, and has no default action. The data attribute must be set to the value of the * data* buffer, the origin attribute must be set to the Unicode serialization of the origin of the event stream's URL, and the lastEventId attribute must be set to the last event ID string of the event source. 4. If the *event name* buffer has a value other than the empty string, change the type of the newly created event to equal the value of the *event name* buffer. 5. Set the *data* buffer and the *event name* buffer to the empty string. 6. Queue a task to dispatch the newly created event at the EventSourceobject (end extract) The event type for the MessageEvent is message (in all browsers I have tested, and there is no other type attribute defined for MessageEvent. So if I send from my server a line event: foo\n, I would expect from reading above that the event attribute type is set to foo. What am I missing? FYI, my test is at http://test.bkaj.net/webapi/server-sent-events/. I have yet to figure out how to get PHP (or the underlying Apache server) to not buffer output, so I send enough data to fill the buffer - a bad kludge but it makes the test work (I think). Any help there is also appreciated. Bryan
Re: [EventSource] Question on event type
On Thu, Sep 8, 2011 at 1:16 PM, Bryan Sullivan bls...@gmail.com wrote: The event type for the MessageEvent is message (in all browsers I have tested, and there is no other type attribute defined for MessageEvent. So if I send from my server a line event: foo\n, I would expect from reading above that the event attribute type is set to foo. What am I missing? Note that event type with DOM Events terms really means the name of the event. Changing it doesn't change the type in the sense of giving it a different interface; it's just a different label that you can listen for with addEventListener. This allows listening to different remote message types with different event handlers. See https://zewt.org/~glenn/event-source.html for an example. It would be good to have an example of this in the spec. FYI, my test is at http://test.bkaj.net/webapi/server-sent-events/. I have yet to figure out how to get PHP (or the underlying Apache server) to not buffer output, so I send enough data to fill the buffer - a bad kludge but it makes the test work (I think). Any help there is also appreciated. flush() (http://php.net/manual/en/function.flush.php) does this at the PHP level; whether it works at the HTTP server level varies. -- Glenn Maynard
RE: rename DOM Core to DOM4; deadline Sept 9
On Wednesday, September 07, 2011 9:53 AM, Arthur Barstow wrote: It appears the majority of the people that voiced an opinion on this thread prefer DOM4. If anyone objects to DOM4, please speak up by September 9 at the latest and include the rationale for your objection as well as an alternate proposal. Microsoft supports this proposal. I normally try to stay away from discussions about naming but this was one where we received feedback that it was important to change. I want to thank the group for giving this issue due consideration. Cheers, Adrian.
Re: [EventSource] Question on event type
Thanks for the help. So when you say the name of the event, how in JavaScript do I access the name of the event, e.g. to test it? Accessing the data (event.data) works, but how do access the name? In your example, event.data is output but I don't see you accessing or using the event name. Thanks, Bryan On Thu, Sep 8, 2011 at 10:46 AM, Glenn Maynard gl...@zewt.org wrote: On Thu, Sep 8, 2011 at 1:16 PM, Bryan Sullivan bls...@gmail.com wrote: The event type for the MessageEvent is message (in all browsers I have tested, and there is no other type attribute defined for MessageEvent. So if I send from my server a line event: foo\n, I would expect from reading above that the event attribute type is set to foo. What am I missing? Note that event type with DOM Events terms really means the name of the event. Changing it doesn't change the type in the sense of giving it a different interface; it's just a different label that you can listen for with addEventListener. This allows listening to different remote message types with different event handlers. See https://zewt.org/~glenn/event-source.html for an example. It would be good to have an example of this in the spec. FYI, my test is at http://test.bkaj.net/webapi/server-sent-events/. I have yet to figure out how to get PHP (or the underlying Apache server) to not buffer output, so I send enough data to fill the buffer - a bad kludge but it makes the test work (I think). Any help there is also appreciated. flush() (http://php.net/manual/en/function.flush.php) does this at the PHP level; whether it works at the HTTP server level varies. -- Glenn Maynard
Re: [EventSource] Question on event type
On Thu, Sep 8, 2011 at 1:56 PM, Bryan Sullivan bls...@gmail.com wrote: Thanks for the help. So when you say the name of the event, how in JavaScript do I access the name of the event, e.g. to test it? Accessing the data (event.data) works, but how do access the name? The type (or name) of the event is the first parameter to addEventListener. It's also available with event.type, if you use the same function for several listeners. -- Glenn Maynard
Re: [EventSource] Question on event type
That would seem to be the obvious way to access it, but does not seem to be working for current implementations of eventsource. That's why I was unsure of how to access it. I guess there are some other issues at hand here. I need to figure out what they are first, and will start another thread for that. It would very helpful if the spec was clearer on how to access the event type. I don't see this anywhere in the referenced DOM Events spec or HTML5 (or the living standard version). Thanks, Bryan On Thu, Sep 8, 2011 at 11:46 AM, Glenn Maynard gl...@zewt.org wrote: On Thu, Sep 8, 2011 at 1:56 PM, Bryan Sullivan bls...@gmail.com wrote: Thanks for the help. So when you say the name of the event, how in JavaScript do I access the name of the event, e.g. to test it? Accessing the data (event.data) works, but how do access the name? The type (or name) of the event is the first parameter to addEventListener. It's also available with event.type, if you use the same function for several listeners. -- Glenn Maynard
[EventSource] Is the field name event supported in current browsers?
Hi all, I am trying to develop a test for eventsource, and am finding that when I include an event field in an eventsource stream, the onmessage events are never fired (if I don't send the event field, just data fields, the events *are* fired). This occurs in FF, Safari, and Chrome (latest end-user versions). The EventSource spec is not really clear on this (there is no example that shows an event field). If anyone is familiar with what should be supported, please let me know if the following expectation is correct: The event stream below should result in a message event being fired, with event.type set to time and event.data set to Thu, 08 Sep 11 13:20:41 -0600: event: time data: Thu, 08 Sep 11 13:20:41 -0600 (blank line) Is this understanding correct? My test is at: http://test.bkaj.net/webapi/server-sent-events Thanks, Bryan
Re: [EventSource] Question on event type
On Thu, Sep 8, 2011 at 3:13 PM, Bryan Sullivan bls...@gmail.com wrote: That would seem to be the obvious way to access it, but does not seem to be working for current implementations of eventsource. That's why I was unsure of how to access it. I guess there are some other issues at hand here. I need to figure out what they are first, and will start another thread for that. It works for me in Chrome 13. https://zewt.org/~glenn/event-source2.html It would very helpful if the spec was clearer on how to access the event type. I don't see this anywhere in the referenced DOM Events spec or HTML5 (or the living standard version). See http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-event-typeand http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-types . -- Glenn Maynard
Re: [EventSource] Is the field name event supported in current browsers?
On Thu, Sep 8, 2011 at 3:24 PM, Bryan Sullivan bls...@gmail.com wrote: I am trying to develop a test for eventsource, and am finding that when I include an event field in an eventsource stream, the onmessage events are never fired (if I don't send the event field, just data fields, the events *are* fired). This occurs in FF, Safari, and Chrome (latest end-user versions). Please see the examples I linked earlier [1]. The default event type is message, so if you don't include an event field, the message event is fired. If you set event: foo, you're changing the event to foo, so the foo event is fired instead of the message event. (Note that you can't say source.onfoo like you can source.onmessage; for custom message types you need to use addEventListener.) The EventSource spec is not really clear on this (there is no example that shows an event field). If anyone is familiar with what should be supported, please let me know if the following expectation is correct: The EventSource spec assumes you're familiar with DOM Events via the DOMCORE and/or DOMEVENTS references. http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#events The event stream below should result in a message event being fired, with event.type set to time and event.data set to Thu, 08 Sep 11 13:20:41 -0600: event: time data: Thu, 08 Sep 11 13:20:41 -0600 (blank line) This will cause a time event to be fired instead of a message event. The default is message, set in step 3 of the steps you linked to earlier [2], and changed to time in step 4. Ian: Step 3 of [2] refers to the event type as the event name, and step 4 refers to it as the type. This is confusing, since it looks like it's referring to two different things. The DOM specs consistently refer to it as type, consistent with the Event interface. I wish type could be changed to name everywhere, but then it'd be inconsistent with the interface (which obviously can't be changed). [1] https://zewt.org/~glenn/event-source.htmlhttps://zewt.org/%7Eglenn/event-source2.html, https://zewt.org/~glenn/event-source2.html [2] http://dev.w3.org/html5/eventsource/#dispatchMessage -- Glenn Maynard
Re: [EventSource] Question on event type
OK, maybe I'm getting closer to understanding this. From your example, when the event field is set, it's not a message event that is dispatched but an event of type event name, so in order to see those events, I need to use the addEventListener interface for the eventsource object (they will not be delivered via the onmessage handler). I modified my test to use that explanation and it does work. It would be really great for the eventsource spec to have an example that explains this. Thanks a lot for your explanation and example. Sorry for the newbie-ish questions. Bryan On Thu, Sep 8, 2011 at 12:28 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Sep 8, 2011 at 3:13 PM, Bryan Sullivan bls...@gmail.com wrote: That would seem to be the obvious way to access it, but does not seem to be working for current implementations of eventsource. That's why I was unsure of how to access it. I guess there are some other issues at hand here. I need to figure out what they are first, and will start another thread for that. It works for me in Chrome 13. https://zewt.org/~glenn/event-source2.html It would very helpful if the spec was clearer on how to access the event type. I don't see this anywhere in the referenced DOM Events spec or HTML5 (or the living standard version). See http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-event-typeand http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-types . -- Glenn Maynard
Re: [EventSource] Is the field name event supported in current browsers?
Thanks for the explanation and examples. I've got it now. I agree it would help if the spec was clearer and had some more examples. I will see what I can offer. Bryan On Thu, Sep 8, 2011 at 12:41 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Sep 8, 2011 at 3:24 PM, Bryan Sullivan bls...@gmail.com wrote: I am trying to develop a test for eventsource, and am finding that when I include an event field in an eventsource stream, the onmessage events are never fired (if I don't send the event field, just data fields, the events *are* fired). This occurs in FF, Safari, and Chrome (latest end-user versions). Please see the examples I linked earlier [1]. The default event type is message, so if you don't include an event field, the message event is fired. If you set event: foo, you're changing the event to foo, so the foo event is fired instead of the message event. (Note that you can't say source.onfoo like you can source.onmessage; for custom message types you need to use addEventListener.) The EventSource spec is not really clear on this (there is no example that shows an event field). If anyone is familiar with what should be supported, please let me know if the following expectation is correct: The EventSource spec assumes you're familiar with DOM Events via the DOMCORE and/or DOMEVENTS references. http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#events The event stream below should result in a message event being fired, with event.type set to time and event.data set to Thu, 08 Sep 11 13:20:41 -0600: event: time data: Thu, 08 Sep 11 13:20:41 -0600 (blank line) This will cause a time event to be fired instead of a message event. The default is message, set in step 3 of the steps you linked to earlier [2], and changed to time in step 4. Ian: Step 3 of [2] refers to the event type as the event name, and step 4 refers to it as the type. This is confusing, since it looks like it's referring to two different things. The DOM specs consistently refer to it as type, consistent with the Event interface. I wish type could be changed to name everywhere, but then it'd be inconsistent with the interface (which obviously can't be changed). [1] https://zewt.org/~glenn/event-source.htmlhttps://zewt.org/%7Eglenn/event-source2.html, https://zewt.org/~glenn/event-source2.html [2] http://dev.w3.org/html5/eventsource/#dispatchMessage -- Glenn Maynard
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. `._.-(,_..'--(,_..'`-.;.'
[Bug 14093] New: Just to throw out an idea, to allow use of the XML parser, and alert() for debugging, one could implement web workers as simply another open page in the browser, with full access to
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14093 Summary: Just to throw out an idea, to allow use of the XML parser, and alert() for debugging, one could implement web workers as simply another open page in the browser, with full access to the DOM, etc, with the ability to communicate to the 'parent' by posting Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Workers (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://www.w3.org/TR/2011/WD-workers-20110901/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Just to throw out an idea, to allow use of the XML parser, and alert() for debugging, one could implement web workers as simply another open page in the browser, with full access to the DOM, etc, with the ability to communicate to the 'parent' by posting messages only. The parent could specify to the browser that the new page should not be made visible to the user (in the use case where the new page will be processing AJAX replies using the DOM Parser) or visible (in the use case where the developer is debugging the web worker and wants to see calls to window.alert()). So a web worker is like another tab in the browser that can communicate with the spawning tab via messages only. So web worker API is really just a intra-page communication interface with pages able to open new pages and keep them invisible. Tabs in a browser are like independent processes. And it seems web-workers is more about processes than threads. This allows one web application (process) to spawn another and talk to it. This will not interfere with or conflict with the idea of having javascript have threads in the future, but would complement it.With multi-processors becoming common, I think javascript will soon follow C++ in adding thread support. Posted from: 199.89.158.132 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: DOM4 not compatible with ACID3 tests
On Thu, Sep 8, 2011 at 1:13 PM, Ian Hickson i...@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
