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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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],
,
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
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
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
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
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
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
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
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,
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
/**
* 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
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
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:
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
, 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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
* 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
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?
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
* 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,
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.
* 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
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
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
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
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] },
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
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
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
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
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
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
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
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,
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:
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
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
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],
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On 7/7/11 6:28 PM, Jonas Sicking wrote:
In gecko you can for example use the nsIMutationObserver notification
to implement this.
Maybe you can, and maybe not. Those fire at unsafe times and are
limited in what you can do from them. Arbitrary debugging doesn't fit
the bill.
But yes, in
1 - 100 of 235 matches
Mail list logo
