Re: [XHR2] Blobs, names and FormData
On Wed, 29 Jun 2011 20:17:52 +0200, Jonas Sicking jo...@sicking.cc wrote: Just a small nit: We would also use blob for File objects with an empty .name property, right? Done: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-formdata-append -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] setRequestHeader and redirects
On Sun, 26 Jun 2011 16:46:23 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 6/25/11 2:23 PM, Anne van Kesteren wrote: So each specification that deals with custom headers of some kind (e.g. EventSource has Last-Event-ID and Cache-Control) needs to say what happens to them in the face of redirects? On the face of it, yes. Especially because different redirect response codes have different semantics (well, in theory), so some headers may need to be preserved across some of them but not others. And without knowing the meaning of the header, it's impossible to say when it should be preserved across the redirect and when it only makes sense in the context of the original request. I raised this with the HTTP WG: http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0489.html It seems they are going to do something about it: http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0490.html I guess we should evaluate again when that is done. -- Anne van Kesteren http://annevankesteren.nl/
Re: Mutation events replacement
On 01/07/11 20:13, Boris Zbarsky wrote: Similarly, I've found it important to be able to distinguish between nodes that are being removed from a document tree and nodes that are being moved within the document tree, Interesting, given that Gecko's DOM implementation does NOT make such a distinction at the moment. Why did you find this to be important? My use case involves multiple people simultaneously editing the same document. The mutations due to user actions are batched and serialized as JSON. If you know that a given node was moved then you can avoid the overhead of serializing a full description of its attributes and content, as is necessary when describing a node to be inserted. If the browser is able to build a list of all the mutations involved in a given user action, this would presumably be more efficient than leaving this to web page scripts to do. It is critically important to know what nodes have been inserted, removed, moved, or have had their attributes changed. If all you know is that some of the children have changed for a given node, the script has to do a lot of work to find out which have changed and in what manner, and this will probably involve keeping a local duplicate of the DOM tree at considerable cost. The application uses web sockets for exchange of synchronization messages, and performs a near real time reconciliation of revisions to the document tree, based upon 3 way merges with one of the clients playing the role of senior editor when it comes to resolving conflicting edits. -- Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Re: Mutation events replacement
On 7/2/11 6:28 AM, Dave Raggett wrote: My use case involves multiple people simultaneously editing the same document. The mutations due to user actions are batched and serialized as JSON. If you know that a given node was moved then you can avoid the overhead of serializing a full description of its attributes and content, as is necessary when describing a node to be inserted. OK, that's similar to David's use case. Do we have any data on how common the move pattern is compared to the remove and insert pattern? That is, does having such an optimization help in practice? If the browser is able to build a list of all the mutations involved in a given user action, this would presumably be more efficient than leaving this to web page scripts to do. Well, sure, for the cases when web script would build such a list. Is that the common case for mutation consumers? For Gecko's internal mutation consumers, this is NOT a common case; the vast majority of them just want to know that something changed because attempting to synchronize state is too complicated to be worth it in most of those cases. An exception is the code managing the CSS box tree, but this has other requirements as well (and is _very_ complicated because it's considered performance-critical). It is critically important to know what nodes have been inserted, removed, moved, or have had their attributes changed. For some use cases, this is a useful optimization, yes. Are those cases the common case? If all you know is that some of the children have changed for a given node, the script has to do a lot of work to find out which have changed and in what manner, and this will probably involve keeping a local duplicate of the DOM tree at considerable cost. That may be ok, if the use cases that incur this cost are rare and the common case can be better served by a different approach. Or put another way, if 1% of consumers want the full list because it makes them 4x faster and the other 99% don't want the full list, and the full list is 3x slower for the browser to build than just providing the information the 99% want, what's the right tradeoff? The numbers above are made up, of course; it would be useful to have some hard data on the actual use cases. Maybe we need both sorts of APIs: one which generates a fine-grained change list and incurs a noticeable DOM mutation performance hit and one which batches changes more but doesn't slow the browser down as much... -Boris
Re: Mutation events replacement
On 02/07/11 15:07, Boris Zbarsky wrote: On 7/2/11 6:28 AM, Dave Raggett wrote: My use case involves multiple people simultaneously editing the same document. The mutations due to user actions are batched and serialized as JSON. If you know that a given node was moved then you can avoid the overhead of serializing a full description of its attributes and content, as is necessary when describing a node to be inserted. OK, that's similar to David's use case. Do we have any data on how common the move pattern is compared to the remove and insert pattern? That is, does having such an optimization help in practice? If the browser is able to build a list of all the mutations involved in a given user action, this would presumably be more efficient than leaving this to web page scripts to do. Well, sure, for the cases when web script would build such a list. Is that the common case for mutation consumers? For Gecko's internal mutation consumers, this is NOT a common case; the vast majority of them just want to know that something changed because attempting to synchronize state is too complicated to be worth it in most of those cases. An exception is the code managing the CSS box tree, but this has other requirements as well (and is _very_ complicated because it's considered performance-critical). It is critically important to know what nodes have been inserted, removed, moved, or have had their attributes changed. For some use cases, this is a useful optimization, yes. Are those cases the common case? If all you know is that some of the children have changed for a given node, the script has to do a lot of work to find out which have changed and in what manner, and this will probably involve keeping a local duplicate of the DOM tree at considerable cost. That may be ok, if the use cases that incur this cost are rare and the common case can be better served by a different approach. If you have used Google Docs for minute taking in teleconferences, you won't want to go back to older ways of taking minutes since it allows every one present to make corrections and add to the minutes during the meeting. Live concurrent editing of DOM trees for shared editing is compelling for real time collaboration and works with today's implementations of mutation events. Of course, having a flag to ask for the full list would be fine, but having to keep a duplicate DOM tree and do an expensive search to figure out what changes had occurred would be a retrograde step and harm the new wave of real-time collaborative web applications. Maybe we need both sorts of APIs: one which generates a fine-grained change list and incurs a noticeable DOM mutation performance hit and one which batches changes more but doesn't slow the browser down as much... That would be fine. -- Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Re: Mutation events replacement
On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky bzbar...@mit.edu wrote: The numbers above are made up, of course; it would be useful to have some hard data on the actual use cases. Maybe we need both sorts of APIs: one which generates a fine-grained change list and incurs a noticeable DOM mutation performance hit and one which batches changes more but doesn't slow the browser down as much... Maybe we'll have a boolean that indicates whether an observer wants a full-list or not when the observer is attached? - Ryosuke
Re: Mutation events replacement
On 02/07/11 17:51, Ryosuke Niwa wrote: Maybe we'll have a boolean that indicates whether an observer wants a full-list or not when the observer is attached? That would do the trick nicely! -- Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Re: Mutation events replacement
Olli Pettay Tue, 28 Jun 2011 04:32:14 -0700 These are *not* DOM-Event listeners. No DOM Events are created, there are no capture phases or bubbling phases. Instead you register a listener on the node you are interested in being notified about, and will get a call after a mutation takes place. The proposed model will be great for element observation, but, as far as I understand it, document observation and especially document transformation would not be supported. Perhaps someone can outline how the replacement would solve two use cases for DOM mutations: 1) break on mutation. In Firebug we add DOM mutation listeners to implement graphical breakpoints. The replacement would work fine for local, element observation breakpoints like add/remove attribute. If my goal is to break on addition of elements with class=foo, then I guess I have to listen for addChildlistChanged on all elements, and add an additional addChildlistChanged listener for each new element? So in general one would implement document observation by walking the DOM and covering it with listeners? 2) element transformation. The replacement fires after a mutation. Library or tools that want to transform the application dynamically want to get notification before the mutation. A common solution then is to bracket changes: beforeChange or onModelChanging afterChange or onModelChanged Of course element transformation may want to prevent the current change and replace it. Some changes are reversible so the observed change can be countered with a remove (at unknown cost to performance and user experience). But some changes are irreversible such as script tag addition. So, for example, I can't see how to implement JS pre-processing using only the after event. (This may not be possible with the current mutation events either, but it is something I want to to). Thanks, jjb
Re: Mutation events replacement
Olli Pettay Tue, 28 Jun 2011 04:32:14 -0700 These are *not* DOM-Event listeners. No DOM Events are created, there are no capture phases or bubbling phases. Instead you register a listener on the node you are interested in being notified about, and will get a call after a mutation takes place. For live concurrent editing of DOM trees, this seems to suggest that you are required to register an observer with *all* nodes in the DOM tree and not just its root node. Is that correct? If correct, it would be a pain for document editing applications. For use cases like document editing, it would be valuable to allow observers on ancestor nodes to see changes to their descendant nodes. n.b. the current mutation events work nicely for the document editing use cases. -- Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Re: Mutation events replacement
On 07/02/2011 09:27 PM, Dave Raggett wrote: Olli Pettay Tue, 28 Jun 2011 04:32:14 -0700 These are *not* DOM-Event listeners. No DOM Events are created, there are no capture phases or bubbling phases. Instead you register a listener on the node you are interested in being notified about, and will get a call after a mutation takes place. For live concurrent editing of DOM trees, this seems to suggest that you are required to register an observer with *all* nodes in the DOM tree and not just its root node. Is that correct? No. You can register listener in the document and get notifications about all the changes in the document tree. The only real functional change comparing to mutation events is handling of element removal. DOMNodeRemoved fires before the node is removed, ChildlistChanged fires after the change has happened. -Olli If correct, it would be a pain for document editing applications. For use cases like document editing, it would be valuable to allow observers on ancestor nodes to see changes to their descendant nodes. n.b. the current mutation events work nicely for the document editing use cases.
Re: Mutation events replacement
On Sat, Jul 2, 2011 at 10:46 AM, John J. Barton johnjbar...@johnjbarton.com wrote: 1) break on mutation. In Firebug we add DOM mutation listeners to implement graphical breakpoints. The replacement would work fine for local, element observation breakpoints like add/remove attribute. If my goal is to break on addition of elements with class=foo, then I guess I have to listen for addChildlistChanged on all elements, and add an additional addChildlistChanged listener for each new element? So in general one would implement document observation by walking the DOM and covering it with listeners? I don't think we can support this use case in general. We're trying to avoid invoking scripts synchronously and your use case requires exactly that. 2) element transformation. The replacement fires after a mutation. Library or tools that want to transform the application dynamically want to get notification before the mutation. Why do you need to get notified before the mutation? Again, this is exactly the sort of usage that causes us headaches and what we want to avoid because scripts can then modify DOM before we make mutations. A common solution then is to bracket changes: beforeChange or onModelChanging afterChange or onModelChanged Of course element transformation may want to prevent the current change and replace it. Some changes are reversible so the observed change can be countered with a remove (at unknown cost to performance and user experience). I don't think we can address your use case here. Scripts' intercepting and preventing mutations browser is about to make or mutating DOM in the way browser doesn't expect is exactly what we want to avoid. - Ryosuke
Re: Mutation events replacement
On 07/02/2011 08:46 PM, John J. Barton wrote: Olli Pettay Tue, 28 Jun 2011 04:32:14 -0700 These are *not* DOM-Event listeners. No DOM Events are created, there are no capture phases or bubbling phases. Instead you register a listener on the node you are interested in being notified about, and will get a call after a mutation takes place. The proposed model will be great for element observation, but, as far as I understand it, document observation and especially document transformation would not be supported. Perhaps someone can outline how the replacement would solve two use cases for DOM mutations: 1) break on mutation. In Firebug we add DOM mutation listeners to implement graphical breakpoints. The replacement would work fine for local, element observation breakpoints like add/remove attribute. If my goal is to break on addition of elements with class=foo, then I guess I have to listen for addChildlistChanged on all elements, and add an additional addChildlistChanged listener for each new element? So in general one would implement document observation by walking the DOM and covering it with listeners? 2) element transformation. The replacement fires after a mutation. So do current mutation events, except DOMNodeRemoved/DOMNodeRemovedFromDocument -Olli Library or tools that want to transform the application dynamically want to get notification before the mutation. A common solution then is to bracket changes: beforeChange or onModelChanging afterChange or onModelChanged Of course element transformation may want to prevent the current change and replace it. Some changes are reversible so the observed change can be countered with a remove (at unknown cost to performance and user experience). But some changes are irreversible such as script tag addition. So, for example, I can't see how to implement JS pre-processing using only the after event. (This may not be possible with the current mutation events either, but it is something I want to to). Thanks, jjb
Re: Mutation events replacement
On 7/2/11 1:46 PM, John J. Barton wrote: 2) element transformation. The replacement fires after a mutation. Library or tools that want to transform the application dynamically want to get notification before the mutation. A common solution then is to bracket changes: beforeChange or onModelChanging afterChange or onModelChanged This really only works if you trust the listeners. The browser core can't trust scripted listeners using Web APIs. So, for example, I can't see how to implement JS pre-processing using only the after event. (This may not be possible with the current mutation events either, but it is something I want to to). It's not clear that you need a web-facing API for your use case, though -Bori
Re: Mutation events replacement
On 7/2/11 2:27 PM, Dave Raggett wrote: n.b. the current mutation events work nicely for the document editing use cases. Only if you have full control over the set of all registered listeners. If you do not, you're SOL, because current mutation events can be delivered out of order if mutations happen inside mutation event listeners, for example. -Boris
