Re: DOM Mutation Events Replacement: When to deliver mutations

2011-09-08 Thread Sean Hogan
On 8/09/11 8:57 AM, Travis Leithead wrote: When I proposed watchSelector [2], the idea was clearly to propose an option that provided semantics similar to Option 4 as described here. The primary benefits I sought were: Pros: * batching - allow a script to operate on the DOM's cumulative

Re: DOM Mutation Events Replacement: When to deliver mutations

2011-09-07 Thread Travis Leithead
On 08/11/2011 03:44 AM, Rafael Weinstein wrote: Although everyone seems to agree that mutations should be delivered after the DOM operations which generated them complete, the question remains: When, exactly, should mutations be delivered? The four options I'm aware of are: 1)

Re: DOM Mutation Events Replacement: Findings from implementing net-effect projections

2011-08-22 Thread Ryosuke Niwa
On Wed, Aug 17, 2011 at 3:17 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 08/17/2011 04:54 AM, Rafael Weinstein wrote: TL;DR; 1) ObserveSubtree semantics doesn't provide a robust mechanism for observing a tree/fragment, and if we don't provide something more complete, libraries will

Re: DOM Mutation Events Replacement: Findings from implementing net-effect projections

2011-08-17 Thread Olli Pettay
On 08/17/2011 04:54 AM, Rafael Weinstein wrote: TL;DR; 1) ObserveSubtree semantics doesn't provide a robust mechanism for observing a tree/fragment, and if we don't provide something more complete, libraries will likely register observers at every node in the document. ModificationBatch

Re: DOM Mutation Events Replacement: Findings from implementing net-effect projections

2011-08-17 Thread Rafael Weinstein
On Wed, Aug 17, 2011 at 3:17 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 08/17/2011 04:54 AM, Rafael Weinstein wrote: TL;DR; 1) ObserveSubtree semantics doesn't provide a robust mechanism for observing a tree/fragment, and if we don't provide something more complete, libraries will

Re: Mutation events replacement

2011-08-17 Thread Olli Pettay
implementation. -Olli On 08/04/2011 04:38 PM, Olli Pettay wrote: Hi all, here is a bit different proposal for mutation events replacement. This is using the mostly-sync approach, and batching can make it easier to use with several simultaneous script libraries; each one would use their own batch

Re: DOM Mutation Events Replacement: When to deliver mutations

2011-08-16 Thread Anne van Kesteren
On Mon, 15 Aug 2011 14:23:10 +0200, Anne van Kesteren ann...@opera.com wrote: Since there seems to be consensus to not do either Immediately or New task should I remove those from http://wiki.whatwg.org/wiki/Modifications now? It is fine with me if someone else does it too. I instead

Re: DOM Mutation Events Replacement: When to deliver mutations

2011-08-16 Thread Ryosuke Niwa
On Mon, Aug 15, 2011 at 5:23 AM, Anne van Kesteren ann...@opera.com wrote: Since there seems to be consensus to not do either Immediately or New task should I remove those from http://wiki.whatwg.org/wiki/** Modifications http://wiki.whatwg.org/wiki/Modifications now? It is fine with me if

DOM Mutation Events Replacement: Findings from implementing net-effect projections

2011-08-16 Thread Rafael Weinstein
TL;DR; 1) ObserveSubtree semantics doesn't provide a robust mechanism for observing a tree/fragment, and if we don't provide something more complete, libraries will likely register observers at every node in the document. 2) Not providing position information (e.g childlistIndex) in

Re: DOM Mutation Events Replacement: When to deliver mutations

2011-08-15 Thread Anne van Kesteren
On Sat, 13 Aug 2011 17:41:32 +0200, Anne van Kesteren ann...@opera.com wrote: I created http://wiki.whatwg.org/wiki/Modifications based on your email and the reply from Olli. It probably needs a bit more context. I will try to contact the relevant people at Opera to see if we have any

Re: DOM Mutation Events Replacement: When to deliver mutations

2011-08-13 Thread Anne van Kesteren
On Thu, 11 Aug 2011 02:44:32 +0200, Rafael Weinstein rafa...@google.com wrote: Although everyone seems to agree that mutations should be delivered after the DOM operations which generated them complete, the question remains: When, exactly, should mutations be delivered? I created

Re: DOM Mutation Events Replacement: When to deliver mutations

2011-08-11 Thread Olli Pettay
On 08/11/2011 03:44 AM, Rafael Weinstein wrote: Although everyone seems to agree that mutations should be delivered after the DOM operations which generated them complete, the question remains: When, exactly, should mutations be delivered? The four options I'm aware of are: 1) Immediately

Re: DOM Mutation Events Replacement: When to deliver mutations

2011-08-11 Thread Rafael Weinstein
Thanks Olli. I think this is now a fairly complete summary of the issues identified thus far. It'd be great to get some additional views -- in particular from folks representing UAs that haven't yet registered any observations or opinons. Note: I think what Olli has listed is fair, but I'm

Re: DOM Mutation Events Replacement: When to deliver mutations

2011-08-11 Thread Olli Pettay
On 08/11/2011 06:13 PM, Rafael Weinstein wrote: Con: Since the approach is bound to tasks, it is not clear what should happen if event loop spins while handling the task. What if some other task modifies the DOM[1], when should the mutation callbacks fire? Because of this issue, tasks, which may

Re: DOM Mutation Events Replacement: When to deliver mutations

2011-08-11 Thread Rafael Weinstein
On Thu, Aug 11, 2011 at 9:12 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 08/11/2011 06:13 PM, Rafael Weinstein wrote: Con: Since the approach is bound to tasks, it is not clear what should happen if event loop spins while handling the task. What if some other task modifies the DOM[1],

Re: Mutation events replacement

2011-08-10 Thread Olli Pettay
, here is a bit different proposal for mutation events replacement. This is using the mostly-sync approach, and batching can make it easier to use with several simultaneous script libraries; each one would use their own batch. For performance reasons it might be useful to have an attribute name filter

Re: Mutation events replacement

2011-08-10 Thread Rafael Weinstein
prefixed API) so that I can create tryserver builds. I'll post the links to builds here later, hopefully in a few days, when I find the time to do the actual implementation. -Olli On 08/04/2011 04:38 PM, Olli Pettay wrote: Hi all, here is a bit different proposal for mutation events

DOM Mutation Events Replacement: The Story So Far / Existing Points of Consensus

2011-08-10 Thread Rafael Weinstein
What follows is an attempt to summarize the (relatively recent) discussions regarding replacing DOM Mutation Events. My goals here are to: -Provide a quick primer for those who haven't read all hundred or so emails. -Reiterate the aspects of a solution which seem to have broad support. -Identify

DOM Mutation Events Replacement: When to deliver mutations

2011-08-10 Thread Rafael Weinstein
Although everyone seems to agree that mutations should be delivered after the DOM operations which generated them complete, the question remains: When, exactly, should mutations be delivered? The four options I'm aware of are: 1) Immediately - i.e. while the operation is underway. [Note: This

Re: DOM Mutation Events Replacement: When to deliver mutations

2011-08-10 Thread Rafael Weinstein
Ok. Being a proponent, here's my further (opinionated) support for Option 3 and criticism for Option 2. On Wed, Aug 10, 2011 at 5:44 PM, Rafael Weinstein rafa...@google.com wrote: Although everyone seems to agree that mutations should be delivered after the DOM operations which generated them

Re: Mutation events replacement

2011-08-10 Thread Ryosuke Niwa
On Wed, Aug 10, 2011 at 12:49 PM, Olli Pettay olli.pet...@helsinki.fiwrote: FYI, I'm planning to implement the proposal (using vendor prefixed API) so that I can create tryserver builds. I'll post the links to builds here later, hopefully in a few days, when I find the time to do the actual

Re: Mutation events replacement

2011-08-10 Thread Boris Zbarsky
On 8/10/11 9:06 PM, Ryosuke Niwa wrote: On Wed, Aug 10, 2011 at 12:49 PM, Olli Pettay olli.pet...@helsinki.fi mailto:olli.pet...@helsinki.fi wrote: FYI, I'm planning to implement the proposal (using vendor prefixed API) so that I can create tryserver builds. I'll post the links to

Re: Mutation events replacement

2011-08-10 Thread Ryosuke Niwa
On Wed, Aug 10, 2011 at 8:32 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 8/10/11 9:06 PM, Ryosuke Niwa Software Engineer Google Inc. wrote: On Wed, Aug 10, 2011 at 12:49 PM, Olli Pettay olli.pet...@helsinki.fi mailto:Olli.Pettay@helsinki.**fi olli.pet...@helsinki.fi wrote: FYI,

Re: Mutation events replacement

2011-08-04 Thread Olli Pettay
Hi all, here is a bit different proposal for mutation events replacement. This is using the mostly-sync approach, and batching can make it easier to use with several simultaneous script libraries; each one would use their own batch. For performance reasons it might be useful to have

Re: Mutation events replacement

2011-08-04 Thread Olli Pettay
/** * The name of the attribute which was changed, or null. */ readonly attribute DOMString attrName; There should be probably also attribute namespace void batchAttrChanges(in Node aNode); A filter could be added here -void batchAttrChanges(in Node aNode); +void batchAttrChanges(in Node

Re: Mutation events replacement

2011-08-04 Thread Olli Pettay
On 08/04/2011 10:14 PM, David Flanagan wrote: On 8/4/11 6:38 AM, Olli Pettay wrote: Hi all, here is a bit different proposal for mutation events replacement. This is using the mostly-sync approach, and batching can make it easier to use with several simultaneous script libraries; each one

Re: More use-cases for mutation events replacement

2011-07-26 Thread Aryeh Gregor
On Mon, Jul 25, 2011 at 11:12 PM, Sean Hogan shogu...@westnet.com.au wrote: I assume you are referring to the NodeWatch proposal from Microsoft. 1st draft:    http://www.w3.org/2008/webapps/wiki/Selector-based_Mutation_Events 2nd draft:  

Re: Mutation events replacement

2011-07-25 Thread Dave Raggett
On 24/07/11 16:18, Aryeh Gregor wrote: On Fri, Jul 22, 2011 at 6:58 PM, Jonas Sicking jo...@sicking.cc wrote: We should have much richer events to aid with rich text editing. Using mutation notifications for this is will not create a good experience for the page author. Agreed. I'd be really

Re: More use-cases for mutation events replacement

2011-07-25 Thread Sean Hogan
, or it could be semi-synchronous, or whatever, as long as it runs before paint. Then I could easily solve all the use-cases: snip It seems to me this dovetails pretty nicely with some of the proposed mutation events replacement APIs. Specifically, people have been talking about allowing

Re: Mutation events replacement

2011-07-24 Thread Aryeh Gregor
On Fri, Jul 22, 2011 at 11:54 AM, Boris Zbarsky bzbar...@mit.edu wrote: Actually, you can pretty easily do it in the other order (move the text into the b, and then put the b in the DOM), and may want to so as to minimize the number of changes the the live DOM; that's something that's often

More use-cases for mutation events replacement

2011-07-24 Thread Aryeh Gregor
or whatever that calls focus(). It seems to me this dovetails pretty nicely with some of the proposed mutation events replacement APIs. Specifically, people have been talking about allowing filtering of events, so this use-case should be solved easily enough if you can use CSS selectors as filters

Re: Mutation events replacement

2011-07-22 Thread Dave Raggett
On 22/07/11 02:26, Adam Klein wrote: This is only complex because you're coalescing the mutations, right? In Rafael's original proposal, each mutation would result in a single immutable mutation record, so the semantics would be to deliver (by appending to a queue associated with each observer)

Re: Mutation events replacement

2011-07-22 Thread Aryeh Gregor
On Thu, Jul 21, 2011 at 4:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: I'd really like numbers.  Having looked at the Gecko editor code in the past, I don't share your assurance that this is how it works That said, if you point to a workload, I (or anyone else; it's open source!) can

Re: Mutation events replacement

2011-07-22 Thread Boris Zbarsky
On 7/22/11 11:44 AM, Aryeh Gregor wrote: Pretty much any formatting command is going to involve adding and removing wrapper elements. To add a wrapper element, say adding ab around some text to make it bold, you first have to insert the wrapper before or after the thing you want to wrap, then

Re: Mutation events replacement

2011-07-22 Thread Dave Raggett
On 22/07/11 16:54, Boris Zbarsky wrote: I don't need software that uses mutation events. I need software that triggers editing operations, so I can them actually measure what DOM mutations are performed in the course of these editing operations. How about: * The many blogging tools with

Re: Mutation events replacement

2011-07-22 Thread Boris Zbarsky
On 7/22/11 12:32 PM, Dave Raggett wrote: On 22/07/11 16:54, Boris Zbarsky wrote: I don't need software that uses mutation events. I need software that triggers editing operations, so I can them actually measure what DOM mutations are performed in the course of these editing operations. How

Re: Mutation events replacement

2011-07-22 Thread Jonas Sicking
On Thu, Jul 21, 2011 at 6:26 PM, Adam Klein ad...@chromium.org wrote: On Thu, Jul 21, 2011 at 4:30 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 07/21/2011 06:01 PM, Boris Zbarsky wrote: On 7/21/11 5:08 AM, Dave

Re: Mutation events replacement

2011-07-22 Thread Rafael Weinstein
On Tue, Jul 19, 2011 at 4:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa rn...@webkit.org wrote: Thanks for the new proposal, Jonas.  I'm very excited about the progress we're making towards a saner world! On Tue, Jul 19, 2011 at 4:01 PM, Jonas

Re: Mutation events replacement

2011-07-22 Thread Jonas Sicking
On Fri, Jul 22, 2011 at 2:08 AM, Dave Raggett d...@w3.org wrote: On 22/07/11 02:26, Adam Klein wrote: This is only complex because you're coalescing the mutations, right? In Rafael's original proposal, each mutation would result in a single immutable mutation record, so the semantics would be

Re: Mutation events replacement

2011-07-22 Thread Jonas Sicking
On Fri, Jul 22, 2011 at 9:32 AM, Dave Raggett d...@w3.org wrote: On 22/07/11 16:54, Boris Zbarsky wrote: I don't need software that uses mutation events.  I need software that triggers editing operations, so I can them actually measure what DOM mutations are performed in the course of these

Re: Mutation events replacement

2011-07-22 Thread Jonas Sicking
On Thu, Jul 21, 2011 at 4:30 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 07/21/2011 06:01 PM, Boris Zbarsky wrote: On 7/21/11 5:08 AM, Dave Raggett wrote: Thanks for the explanation. Apps would need a way to disable

Re: Mutation events replacement

2011-07-22 Thread Ryosuke Niwa
On Fri, Jul 22, 2011 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote: We should have much richer events to aid with rich text editing. Using mutation notifications for this is will not create a good experience for the page author. But this is a big use case of mutation events today. If we

Re: Mutation events replacement

2011-07-22 Thread Jonas Sicking
On Fri, Jul 22, 2011 at 4:44 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Jul 22, 2011 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote: We should have much richer events to aid with rich text editing. Using mutation notifications for this is will not create a good experience for the page

Re: Mutation events replacement

2011-07-21 Thread Dave Raggett
On 20/07/11 18:23, Boris Zbarsky wrote: It's pretty common to have situations where lots (10-20) of properties are set in inline style, especially in cases where the inline style is being changed via CSS2Properties from script (think animations and the like, where the objects being animated

Re: Mutation events replacement

2011-07-21 Thread Olli Pettay
On 07/21/2011 01:56 AM, Jonas Sicking wrote: On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettayolli.pet...@helsinki.fi wrote: On 07/20/2011 06:46 PM, Jonas Sicking wrote: Hence I'm leaning towards using the almost-asynchronous proposal for now. If we end up getting the feedback from people that

Re: Mutation events replacement

2011-07-21 Thread Boris Zbarsky
On 7/21/11 5:08 AM, Dave Raggett wrote: Thanks for the explanation. Apps would need a way to disable notifications during such animation sequences, and would be able to find another means to serialize the animation (at a higher level). I'm not sure I trust apps to do that, which is why I think

Re: Mutation events replacement

2011-07-21 Thread Olli Pettay
On 07/21/2011 06:01 PM, Boris Zbarsky wrote: On 7/21/11 5:08 AM, Dave Raggett wrote: Thanks for the explanation. Apps would need a way to disable notifications during such animation sequences, and would be able to find another means to serialize the animation (at a higher level). I'm not sure

Re: Mutation events replacement

2011-07-21 Thread Aryeh Gregor
all the contents of an element next to it before you remove it, etc. Editors of various types seem like they're one of the big use-cases for a mutation events replacement anyway, so my guess is it's important. But nobody's even made a list of use-cases for mutation listeners, have they? I don't

Re: Mutation events replacement

2011-07-21 Thread Boris Zbarsky
On 7/21/11 4:15 PM, Aryeh Gregor wrote: I can say that it's very common and critical for editors. I'd really like numbers. Having looked at the Gecko editor code in the past, I don't share your assurance that this is how it works That said, if you point to a workload, I (or anyone

Re: Mutation events replacement

2011-07-21 Thread Jonas Sicking
On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 07/21/2011 06:01 PM, Boris Zbarsky wrote: On 7/21/11 5:08 AM, Dave Raggett wrote: Thanks for the explanation. Apps would need a way to disable notifications during such animation sequences, and would be able to

Re: Mutation events replacement

2011-07-21 Thread Adam Klein
On Thu, Jul 21, 2011 at 4:30 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 07/21/2011 06:01 PM, Boris Zbarsky wrote: On 7/21/11 5:08 AM, Dave Raggett wrote: Thanks for the explanation. Apps would need a way to disable

Re: Mutation events replacement

2011-07-20 Thread Dave Raggett
Thanks Jonas for the proposal. For changes to attributes and changes to the value of text nodes, it should be possible to applications to request to see the before/after values. You note that style attributes may be long as an argument against permitting applications to see the before value.

Re: Mutation events replacement

2011-07-20 Thread Dave Raggett
On 20/07/11 00:56, Jonas Sicking wrote: On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwarn...@webkit.org wrote: For editing purposes, it's also crucial to know from/to where nodes are removed/inserted. It seems like adding an offset trivially solves this problem without much overhead. I'm not

Re: Mutation events replacement

2011-07-20 Thread Olli Pettay
On 07/20/2011 02:01 AM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 6:38 PM, Jonas Sickingjo...@sicking.cc wrote: On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinsteinrafa...@google.com wrote: So yes, my proposal only solves the usecase outside mutation handlers. However this is arguably better

Re: Mutation events replacement

2011-07-20 Thread Boris Zbarsky
On 7/20/11 4:26 AM, Dave Raggett wrote: You note that style attributes may be long as an argument against permitting applications to see the before value. The problem is not the length per se. The problem is that the value is not stored anywhere and has to be generated based on other data

Re: Mutation events replacement

2011-07-20 Thread Dave Raggett
On 20/07/11 16:32, Boris Zbarsky wrote: On 7/20/11 4:26 AM, Dave Raggett wrote: You note that style attributes may be long as an argument against permitting applications to see the before value. The problem is not the length per se. The problem is that the value is not stored anywhere and

Re: Mutation events replacement

2011-07-20 Thread Jonas Sicking
On Wed, Jul 20, 2011 at 5:20 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 07/20/2011 02:01 AM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 6:38 PM, Jonas Sickingjo...@sicking.cc  wrote: On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinsteinrafa...@google.com  wrote: So yes, my proposal only

Re: Mutation events replacement

2011-07-20 Thread Ryosuke Niwa
On Wed, Jul 20, 2011 at 8:43 AM, Dave Raggett d...@w3.org wrote: Perhaps we need to distinguish auto generated attributes from those that are set by markup or scripts. Could you please clarify for me the difference between the html style attribute and the one you are referring to? My

Re: Mutation events replacement

2011-07-20 Thread Dave Raggett
On 20/07/11 17:05, Ryosuke Niwa wrote: On Wed, Jul 20, 2011 at 8:43 AM, Dave Raggett d...@w3.org mailto:d...@w3.org wrote: Perhaps we need to distinguish auto generated attributes from those that are set by markup or scripts. Could you please clarify for me the difference between

Re: Mutation events replacement

2011-07-20 Thread Ryosuke Niwa
On Wed, Jul 20, 2011 at 9:32 AM, Dave Raggett d...@w3.org wrote: Isn't there a cheap way to distinguish changes to the DOM (setAttribute) from indirect changes to how CSSMutableStyleDeclaration is formatted to text? It sounds as if you already have a setter function that knows how to update

Re: Mutation events replacement

2011-07-20 Thread Bjoern Hoehrmann
* Dave Raggett wrote: Perhaps we need to distinguish auto generated attributes from those that are set by markup or scripts. Could you please clarify for me the difference between the html style attribute and the one you are referring to? My understanding is that the html style attribute is

Re: Mutation events replacement

2011-07-20 Thread Boris Zbarsky
On 7/20/11 11:43 AM, Dave Raggett wrote: Perhaps we need to distinguish auto generated attributes from those that are set by markup or scripts. I'm not sure what you mean. Could you please clarify for me the difference between the html style attribute and the one you are referring to?

Re: Mutation events replacement

2011-07-20 Thread Olli Pettay
On 07/20/2011 06:46 PM, Jonas Sicking wrote: Hence I'm leaning towards using the almost-asynchronous proposal for now. If we end up getting the feedback from people that use mutation events today that they won't be able to solve the same use cases, then we can consider using the synchronous

Re: Mutation events replacement

2011-07-20 Thread Bjoern Hoehrmann
* Boris Zbarsky wrote: It's pretty common to have situations where lots (10-20) of properties are set in inline style, especially in cases where the inline style is being changed via CSS2Properties from script (think animations and the like, where the objects being animated tend to have width,

Re: Mutation events replacement

2011-07-20 Thread Boris Zbarsky
On 7/20/11 2:19 PM, Bjoern Hoehrmann wrote: It's pretty common to have situations where lots (10-20) of properties are set in inline style, especially in cases where the inline style is being changed via CSS2Properties from script (think animations and the like, where the objects being animated

Re: Mutation events replacement

2011-07-20 Thread Aryeh Gregor
On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan dflana...@mozilla.com wrote: Finally, I still think it is worth thinking about trying to model the distinction between removing nodes from the document tree and moving them (atomically) within the tree. I'll chip in that I think this is useful.

Re: Mutation events replacement

2011-07-20 Thread Bjoern Hoehrmann
* Boris Zbarsky wrote: On 7/20/11 2:19 PM, Bjoern Hoehrmann wrote: Depending on the design of the mutation notification system and what level of complexity people find palatable, it would naturally also be possible to serialize lazily The only way to do that is to make sure the pre-mutation

Re: Mutation events replacement

2011-07-20 Thread Ryosuke Niwa
On Wed, Jul 20, 2011 at 12:53 PM, David Flanagan dflana...@mozilla.comwrote: On 7/20/11 12:11 PM, Ryosuke Niwa wrote: But internally, a node movement is a removal then an insertion. There's always possibility that a node gets removed then inserted again after mutation observers are

Re: Mutation events replacement

2011-07-20 Thread David Flanagan
On 7/20/11 12:11 PM, Ryosuke Niwa wrote: On Wed, Jul 20, 2011 at 11:56 AM, Aryeh Gregor simetrical+...@gmail.com mailto:simetrical%2b...@gmail.com wrote: On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan dflana...@mozilla.com mailto:dflana...@mozilla.com wrote: Finally, I still

Re: Mutation events replacement

2011-07-20 Thread Ryosuke Niwa
On Tue, Jul 19, 2011 at 8:23 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/19/11 7:18 PM, Ryosuke Niwa Software Engineer Google Inc. wrote: For editing purposes, it's also crucial to know from/to where nodes are removed/inserted. It seems like adding an offset trivially solves this

Re: Mutation events replacement

2011-07-20 Thread David Flanagan
On 7/19/11 4:01 PM, Jonas Sicking wrote: 'listener' above would be a function which receives a single argument when notifications fire. The value of this argument would be an Array which could look something like this: [ { target: node1, type: childlist, added: [a, b, c, d], removed: [x, y] },

Re: Mutation events replacement

2011-07-20 Thread Ojan Vafai
On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 07/20/2011 06:46 PM, Jonas Sicking wrote: Hence I'm leaning towards using the almost-asynchronous proposal for now. If we end up getting the feedback from people that use mutation events today that they won't be

Re: Mutation events replacement

2011-07-20 Thread Jonas Sicking
On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 07/20/2011 06:46 PM, Jonas Sicking wrote: Hence I'm leaning towards using the almost-asynchronous proposal for now. If we end up getting the feedback from people that use mutation events today that they won't be

Re: Mutation events replacement

2011-07-20 Thread Sean Hogan
On 21/07/11 6:18 AM, David Flanagan wrote: On 7/20/11 12:11 PM, Ryosuke Niwa wrote: On Wed, Jul 20, 2011 at 11:56 AM, Aryeh Gregor simetrical+...@gmail.com mailto:simetrical%2b...@gmail.com wrote: On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan dflana...@mozilla.com

Re: Mutation events replacement

2011-07-20 Thread Boris Zbarsky
On 7/20/11 4:10 PM, Bjoern Hoehrmann wrote: Simple example: you get a notification whenever a script could observe the .getAttribute value changes, and you get it before the change is applied. Right, the synchronous will mutate notification. Having that does simplify things. As discussed on

Re: Mutation events replacement

2011-07-20 Thread Boris Zbarsky
On 7/20/11 4:14 PM, Ryosuke Niwa wrote: I'm not sure if we can have a concept of atomicity in DOM. Boris might have a strong opinion on this. I don't yet. What I do have a strong opinion on is that it would be good to have some data on how common move operations are compared to remove and

Re: Mutation events replacement

2011-07-20 Thread David Flanagan
On 7/20/11 7:17 PM, Boris Zbarsky wrote: On 7/20/11 4:14 PM, Ryosuke Niwa wrote: I'm not sure if we can have a concept of atomicity in DOM. Boris might have a strong opinion on this. I don't yet. What I do have a strong opinion on is that it would be good to have some data on how common

Re: Mutation events replacement

2011-07-19 Thread Jonas Sicking
On Thu, Jul 7, 2011 at 6:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein rafa...@google.com wrote: So yes, my proposal only solves the usecase outside mutation handlers. However this is arguably better than never solving the use case as in your

Re: Mutation events replacement

2011-07-19 Thread Ryosuke Niwa
Thanks for the new proposal, Jonas. I'm very excited about the progress we're making towards a saner world! On Tue, Jul 19, 2011 at 4:01 PM, Jonas Sicking jo...@sicking.cc wrote: [ { target: node1, type: childlist, added: [a, b, c, d], removed: [x, y] }, { target: node1, type: attributes,

Re: Mutation events replacement

2011-07-19 Thread Jonas Sicking
On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa rn...@webkit.org wrote: Thanks for the new proposal, Jonas.  I'm very excited about the progress we're making towards a saner world! On Tue, Jul 19, 2011 at 4:01 PM, Jonas Sicking jo...@sicking.cc wrote: [ { target: node1, type: childlist, added:

Re: Mutation events replacement

2011-07-19 Thread Ryosuke Niwa
On Tue, Jul 19, 2011 at 4:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa rn...@webkit.org wrote: For editing purposes, it's also crucial to know from/to where nodes are removed/inserted. It seems like adding an offset trivially solves this

Re: Mutation events replacement

2011-07-19 Thread Boris Zbarsky
On 7/19/11 7:18 PM, Ryosuke Niwa wrote: For editing purposes, it's also crucial to know from/to where nodes are removed/inserted. It seems like adding an offset trivially solves this problem without much overhead. I'm not convinced about without much overhead. In general, adding an offset

Re: Mutation events replacement

2011-07-19 Thread David Flanagan
On 7/19/11 4:01 PM, Jonas Sicking wrote: [ { target: node1, type: childlist, added: [a, b, c, d], removed: [x, y] }, { target: node1, type: attributes, changed: [class, bgcolor, href] }, { target: node2, type: characterdata }, { target: node3, type: childlist, added: [r, s, t, x],

Re: Mutation events replacement

2011-07-09 Thread Sean Hogan
On 9/07/11 1:12 AM, Ryosuke Niwa wrote: On Fri, Jul 8, 2011 at 5:21 AM, Sean Hogan shogu...@westnet.com.au mailto:shogu...@westnet.com.au wrote: - MathJax (http://mathjax.org) is a JS lib that facilitates putting math onto the web by converting LaTeX or MathML markup in a page to

Re: Mutation events replacement

2011-07-08 Thread Sean Hogan
On 8/07/11 8:28 AM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 3:21 PM, John J Barton johnjbar...@johnjbarton.com wrote: Jonas Sicking wrote: We are definitely short on use cases for mutation events in general which is a problem. 3. Client side dynamic translation. Intercept mutations

Re: Mutation events replacement

2011-07-08 Thread timeless
On Thu, Jul 7, 2011 at 6:21 PM, John J Barton johnjbar...@johnjbarton.com wrote: 1. Graphical breakpoints. The user marks some DOM element or attribute to trigger break. The debugger inserts mutation listeners to watch for the event that causes that element/attribute to be created/modified.

Re: Mutation events replacement

2011-07-08 Thread Sean Hogan
On 8/07/11 10:21 PM, Sean Hogan wrote: On 8/07/11 8:28 AM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 3:21 PM, John J Barton johnjbar...@johnjbarton.com wrote: Jonas Sicking wrote: We are definitely short on use cases for mutation events in general which is a problem. 3. Client side

Re: Mutation events replacement

2011-07-08 Thread Ryosuke Niwa
On Fri, Jul 8, 2011 at 5:21 AM, Sean Hogan shogu...@westnet.com.au wrote: - MathJax (http://mathjax.org) is a JS lib that facilitates putting math onto the web by converting LaTeX or MathML markup in a page to HTML. By default MathJax triggers off the onload event to run this conversion on the

Re: Mutation events replacement

2011-07-08 Thread Jonas Sicking
On Fri, Jul 8, 2011 at 5:21 AM, Sean Hogan shogu...@westnet.com.au wrote: On 8/07/11 8:28 AM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 3:21 PM, John J Barton johnjbar...@johnjbarton.com  wrote: Jonas Sicking wrote:  We are definitely short on use cases for mutation events in general

Re: Mutation events replacement

2011-07-08 Thread Tab Atkins Jr.
On Fri, Jul 8, 2011 at 6:55 AM, Sean Hogan shogu...@westnet.com.au wrote: On 8/07/11 10:21 PM, Sean Hogan wrote: - ARIA support in JS libs currently involves updating aria-attributes to be appropriate to behavior the lib is implementing. Attribute mutation listeners would allow an inverse

Re: Mutation events replacement

2011-07-07 Thread Jonas Sicking
Hi All, I've finally caught up on all the emails in this thread. Here are my impressions so far. I don't think John J Barton's proposal to fire before mutation notifications is doable. Trying to make all APIs that would, or could, mutate the DOM throw or otherwise fail would be much too complex

Re: Mutation events replacement

2011-07-07 Thread Ryosuke Niwa
On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking jo...@sicking.cc wrote: I don't think John J Barton's proposal to fire before mutation notifications is doable. I concur. Being synchronous was one of the reasons why the existing DOM mutation events don't work. We shouldn't adding yet-another

Re: Mutation events replacement

2011-07-07 Thread Ryosuke Niwa
On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa rn...@webkit.org wrote: Right. But on the other hand, if this code were to run inside a mutation observer, it won't work in your proposal either. So the questions is whether writing a function that depends on state updated by the mutation

Re: Mutation events replacement

2011-07-07 Thread Olli Pettay
On 07/07/2011 10:18 PM, Jonas Sicking wrote: Hi All, I've finally caught up on all the emails in this thread. Here are my impressions so far. I don't think John J Barton's proposal to fire before mutation notifications is doable. Trying to make all APIs that would, or could, mutate the DOM

Re: Mutation events replacement

2011-07-07 Thread Rafael Weinstein
On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking jo...@sicking.cc wrote: I don't think John J Barton's proposal to fire before mutation notifications is doable. I concur.  Being synchronous was one of the reasons why the

Re: Mutation events replacement

2011-07-07 Thread Olli Pettay
On 07/08/2011 12:29 AM, Olli Pettay wrote: On 07/07/2011 10:18 PM, Jonas Sicking wrote: Hi All, I've finally caught up on all the emails in this thread. Here are my impressions so far. I don't think John J Barton's proposal to fire before mutation notifications is doable. Trying to make all

Re: Mutation events replacement

2011-07-07 Thread Jonas Sicking
On Thu, Jul 7, 2011 at 2:32 PM, Rafael Weinstein rafa...@google.com wrote: On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking jo...@sicking.cc wrote: I don't think John J Barton's proposal to fire before mutation notifications

Re: Mutation events replacement

2011-07-07 Thread John J Barton
Jonas Sicking wrote: We are definitely short on use cases for mutation events in general which is a problem. 1. Graphical breakpoints. The user marks some DOM element or attribute to trigger break. The debugger inserts mutation listeners to watch for the event that causes that

Re: Mutation events replacement

2011-07-07 Thread Jonas Sicking
On Thu, Jul 7, 2011 at 3:21 PM, John J Barton johnjbar...@johnjbarton.com wrote: Jonas Sicking wrote:  We are definitely short on use cases for mutation events in general which is a problem. 1. Graphical breakpoints. The user marks some DOM element or attribute to trigger break. The

Re: Mutation events replacement

2011-07-07 Thread John J Barton
Rafael Weinstein wrote: On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking jo...@sicking.cc wrote: I don't think John J Barton's proposal to fire before mutation notifications is doable. I concur. Being

  1   2   3   >