Re: DOM Mutation Events Replacement: When to deliver mutations

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 changes,

Re: DOM Mutation Events Replacement: When to deliver mutations

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

On Wed, Aug 17, 2011 at 3:17 AM, Olli Pettay 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 likely registe

Re: Mutation events replacement

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 replacement. This is using the mostly-sync approach, and batching can make it easier to use with several simultaneous script libraries; each one would

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

On Wed, Aug 17, 2011 at 3:17 AM, Olli Pettay 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 likely regist

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

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 approa

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

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 "ChildlistCha

Re: DOM Mutation Events Replacement: When to deliver mutations

On Mon, Aug 15, 2011 at 5:23 AM, Anne van Kesteren 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

Re: DOM Mutation Events Replacement: When to deliver mutations

On Mon, 15 Aug 2011 14:23:10 +0200, Anne van Kesteren 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 added a new sect

Re: DOM Mutation Events Replacement: When to deliver mutations

On Sat, 13 Aug 2011 17:41:32 +0200, Anne van Kesteren 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 input in the matter.

Re: DOM Mutation Events Replacement: When to deliver mutations

On Thu, 11 Aug 2011 02:44:32 +0200, 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? I created http://wiki.whatwg.org/wiki/

Re: DOM Mutation Events Replacement: When to deliver mutations

On Thu, Aug 11, 2011 at 9:12 AM, Olli Pettay 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], when sho

Re: DOM Mutation Events Replacement: When to deliver mutations

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

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 concer

Re: DOM Mutation Events Replacement: When to deliver mutations

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: Mutation events replacement

On Wed, Aug 10, 2011 at 8:32 PM, Boris Zbarsky 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 > > wrote: >> >>FYI, I'm planning to implement the proposal (using ve

Re: Mutation events replacement

On 8/10/11 9:06 PM, Ryosuke Niwa wrote: On Wed, Aug 10, 2011 at 12:49 PM, Olli Pettay 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 builds here later, hop

Re: Mutation events replacement

On Wed, Aug 10, 2011 at 12:49 PM, Olli Pettay 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 builds here later, hopefully in a few days, when > I find the time to do the actual implementation. >

Re: DOM Mutation Events Replacement: When to deliver mutations

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 wrote: > Although everyone seems to agree that mutations should be delivered > after the DOM operations which generated them complete, the ques

DOM Mutation Events Replacement: When to deliver mutations

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

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

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

Re: Mutation events replacement

ng 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 implementation. > > > -Olli > > > On 08/04/2011 04:38 PM, Olli Pettay wrote: &g

Re: Mutation events replacement

ettay 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. For performance reasons it might be useful to have an a

Re: Mutation events replacement

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: Mutation events replacement

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 would use their own batch. For performance

Re: Mutation events replacement

/** * 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 a

Re: Mutation events replacement

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 an

Re: More use-cases for mutation events replacement

On Mon, Jul 25, 2011 at 11:12 PM, Sean Hogan 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: > >  http://www.w3.org/2008/webapps/wiki/MutationReplacement#NodeWatch_.2

Re: More use-cases for mutation events replacement

any opportunity to paint, or it could be semi-synchronous, or whatever, as long as it runs before paint. Then I could easily solve all the use-cases: It seems to me this dovetails pretty nicely with some of the proposed mutation events replacement APIs. Specifically, people have been talking ab

Re: Mutation events replacement

On 24/07/11 16:18, Aryeh Gregor wrote: On Fri, Jul 22, 2011 at 6:58 PM, Jonas Sicking 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 interested in spe

More use-cases for mutation events replacement

When discussing mutation events use-cases, mostly so far people have been talking about editors. However, I think mutation event replacements would have a much more general appeal if they were easily usable in certain cases with little performance impact. Specifically, one use-case I've run into

Re: Mutation events replacement

On Fri, Jul 22, 2011 at 11:54 AM, Boris Zbarsky wrote: > Actually, you can pretty easily do it in the other order (move the text into > the , and then put the 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 > recommended as a

Re: Mutation events replacement

On Fri, Jul 22, 2011 at 4:44 PM, Ryosuke Niwa wrote: > On Fri, Jul 22, 2011 at 3:58 PM, Jonas Sicking 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

Re: Mutation events replacement

On Fri, Jul 22, 2011 at 3:58 PM, Jonas Sicking 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 were to repl

Re: Mutation events replacement

On Thu, Jul 21, 2011 at 4:30 PM, Jonas Sicking wrote: > On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay 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 dur

Re: Mutation events replacement

On Fri, Jul 22, 2011 at 9:32 AM, 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 edit

Re: Mutation events replacement

On Tue, Jul 19, 2011 at 4:56 PM, Jonas Sicking wrote: > On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa 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 wrote: >>> >>> [ { tar

Re: Mutation events replacement

On Fri, Jul 22, 2011 at 2:08 AM, Dave Raggett 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 to

Re: Mutation events replacement

On Thu, Jul 21, 2011 at 6:26 PM, Adam Klein wrote: > On Thu, Jul 21, 2011 at 4:30 PM, Jonas Sicking wrote: >> On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay wrote: >>> On 07/21/2011 06:01 PM, Boris Zbarsky wrote: On 7/21/11 5:08 AM, Dave Raggett wrote: > > Thanks for the explanat

Re: Mutation events replacement

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 abo

Re: Mutation events replacement

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 ric

Re: Mutation events replacement

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 a around some text to make it bold, you first have to insert the wrapper before or after the thing you want to wrap, then mov

Re: Mutation events replacement

On Thu, Jul 21, 2011 at 4:21 PM, Boris Zbarsky 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 probably generat

Re: Mutation events replacement

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

On Thu, Jul 21, 2011 at 4:30 PM, Jonas Sicking wrote: > On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay 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 dur

Re: Mutation events replacement

On Thu, Jul 21, 2011 at 8:19 AM, Olli Pettay 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 find >>> ano

Re: Mutation events replacement

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 else;

Re: Mutation events replacement

up text nodes and wrapping bits of them in new elements that you just inserted before them, moving 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 i

Re: Mutation events replacement

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

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

On 20/07/11 21:34, David Flanagan wrote: 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

Re: Mutation events replacement

On 07/21/2011 01:56 AM, Jonas Sicking wrote: On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay 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

Re: Mutation events replacement

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 ten

Re: Mutation events replacement

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 "mo

Re: Mutation events replacement

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" an

Re: Mutation events replacement

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

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 mailto:simetrical%2b...@gmail.com>> wrote: On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan mailto:dflana...@mozilla.com>> wrote: > Finally, I still thi

Re: Mutation events replacement

On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay 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 able to sol

Re: Mutation events replacement

On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettay 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 able to solve

Re: Mutation events replacement

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

On Tue, Jul 19, 2011 at 8:23 PM, Boris Zbarsky 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 >> prob

Re: Mutation events replacement

On 7/20/11 12:11 PM, Ryosuke Niwa wrote: On Wed, Jul 20, 2011 at 11:56 AM, Aryeh Gregor mailto:simetrical%2b...@gmail.com>> wrote: On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan mailto:dflana...@mozilla.com>> wrote: > Finally, I still think it is worth thinking about trying to

Re: Mutation events replacement

On Wed, Jul 20, 2011 at 12:53 PM, David Flanagan wrote: > 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 invoked. Also, what ha

Re: Mutation events replacement

* 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-mut

Re: Mutation events replacement

On Wed, Jul 20, 2011 at 11:56 AM, Aryeh Gregor wrote: > On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan > 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

Re: Mutation events replacement

On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan 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. It makes things som

Re: Mutation events replacement

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 t

Re: Mutation events replacement

* 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 widt

Re: Mutation events replacement

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 noti

Re: Mutation events replacement

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? The

Re: Mutation events replacement

* 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

Re: Mutation events replacement

On Wed, Jul 20, 2011 at 9:32 AM, Dave Raggett 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 the CS

Re: Mutation events replacement

On 20/07/11 17:05, Ryosuke Niwa wrote: On Wed, Jul 20, 2011 at 8:43 AM, 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 "st

Re: Mutation events replacement

On Wed, Jul 20, 2011 at 8:43 AM, 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 > understandin

Re: Mutation events replacement

On Wed, Jul 20, 2011 at 5:20 AM, Olli Pettay wrote: > On 07/20/2011 02:01 AM, Jonas Sicking wrote: >> >> On Thu, Jul 7, 2011 at 6:38 PM, Jonas Sicking  wrote: >>> >>> On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein >>>  wrote: > > So yes, my proposal only solves the usecase outside mutati

Re: Mutation events replacement

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 h

Re: Mutation events replacement

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 s

Re: Mutation events replacement

On 07/20/2011 02:01 AM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 6:38 PM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein wrote: So yes, my proposal only solves the usecase outside mutation handlers. However this is arguably better than never solving the use case as i

Re: Mutation events replacement

On 20/07/11 00:56, Jonas Sicking wrote: On Tue, Jul 19, 2011 at 4: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 really sure how yo

Re: Mutation events replacement

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. B

Re: Mutation events replacement

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,

Re: Mutation events replacement

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

On Tue, Jul 19, 2011 at 4:56 PM, Jonas Sicking wrote: > On Tue, Jul 19, 2011 at 4: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.

Re: Mutation events replacement

On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwa 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 wrote: >> >> [ { target: node1, type: "childlist", added: [a, b, c, d], removed: [

Re: Mutation events replacement

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 wrote: > > [ { target: node1, type: "childlist", added: [a, b, c, d], removed: [x, y] > }, > { target: node1, type: "attributes", changed: [

Re: Mutation events replacement

On Thu, Jul 7, 2011 at 6:38 PM, Jonas Sicking wrote: > On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein 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 proposal. I'm sure people wi

Re: Mutation events replacement

On 9/07/11 1:12 AM, Ryosuke Niwa wrote: On Fri, Jul 8, 2011 at 5:21 AM, Sean Hogan > 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

Re: Mutation events replacement

On Fri, Jul 8, 2011 at 6:55 AM, Sean Hogan 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 approach - behaviors

Re: Mutation events replacement

On Fri, Jul 8, 2011 at 5:21 AM, 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 >>  wrote: >>> >>> Jonas Sicking wrote:  We are definitely short on use cases for mutation events in general which is a problem. >>>

Re: Mutation events replacement

On Fri, Jul 8, 2011 at 5:21 AM, Sean Hogan 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 > page. When conten

Re: Mutation events replacement

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 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

Re: Mutation events replacement

On Thu, Jul 7, 2011 at 6:21 PM, John J Barton 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. Then the > debugger re-execu

Re: Mutation events replacement

On 8/07/11 8:28 AM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 3:21 PM, John J Barton 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 and replace or extend them. Th

Re: Mutation events replacement

On 7/7/2011 6:38 PM, Jonas Sicking wrote: On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein 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 proposal. I'm sure people will end up writing buggy

Re: Mutation events replacement

On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein 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 proposal. I'm sure people will end up writing buggy code, but >> ideally this will be f

Re: Mutation events replacement

On Thu, Jul 7, 2011 at 3:19 PM, Jonas Sicking wrote: > On Thu, Jul 7, 2011 at 2:32 PM, Rafael Weinstein wrote: >> On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: >>> On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: I don't think John J Barton's proposal to fire "before mutati

Re: Mutation events replacement

Olli Pettay wrote: On 07/08/2011 01:43 AM, John J Barton wrote: Rafael Weinstein wrote: On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: I don't think John J Barton's proposal to fire "before mutation notifications" is doable. I concu

Re: Mutation events replacement

On Thu, Jul 7, 2011 at 3:43 PM, John J Barton wrote: In short before spending more time on this, I'd like to see a comprehensive proposal, including a description of the use cases it solves and how it solves them. I strongly doubt that this approach is practical. > > There

Re: Mutation events replacement

On 07/08/2011 01:43 AM, John J Barton wrote: Rafael Weinstein wrote: On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: I don't think John J Barton's proposal to fire "before mutation notifications" is doable. I concur. Being synchronou

Re: Mutation events replacement

On Thu, Jul 7, 2011 at 3:43 PM, John J Barton wrote: > > On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa wrote: >> >> >>> On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking wrote: >>> >>> I don't think John J Barton's proposal to fire "before mutation notifications" is doable. >>> I

  1   2   3   >