On Wed, 29 Jun 2011 20:17:52 +0200, Jonas Sicking jo...@sicking.cc wrote:
Just a small nit: We would also use blob for File objects with an
empty .name property, right?
Done: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-formdata-append
--
Anne van Kesteren
http://annevankesteren.nl/
On Sun, 26 Jun 2011 16:46:23 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/25/11 2:23 PM, Anne van Kesteren wrote:
So each specification that deals with custom headers of some kind (e.g.
EventSource has Last-Event-ID and Cache-Control) needs to say what
happens to them in the face of
On 01/07/11 20:13, Boris Zbarsky wrote:
Similarly, I've found it important to
be able to distinguish between nodes that are being removed from a
document tree and nodes that are being moved within the document tree,
Interesting, given that Gecko's DOM implementation does NOT make such
a
On 7/2/11 6:28 AM, Dave Raggett wrote:
My use case involves multiple people simultaneously editing the same
document. The mutations due to user actions are batched and serialized
as JSON. If you know that a given node was moved then you can avoid the
overhead of serializing a full description of
On 02/07/11 15:07, Boris Zbarsky wrote:
On 7/2/11 6:28 AM, Dave Raggett wrote:
My use case involves multiple people simultaneously editing the same
document. The mutations due to user actions are batched and serialized
as JSON. If you know that a given node was moved then you can avoid the
On Sat, Jul 2, 2011 at 7:07 AM, Boris Zbarsky bzbar...@mit.edu wrote:
The numbers above are made up, of course; it would be useful to have some
hard data on the actual use cases.
Maybe we need both sorts of APIs: one which generates a fine-grained change
list and incurs a noticeable DOM
On 02/07/11 17:51, Ryosuke Niwa wrote:
Maybe we'll have a boolean that indicates whether an observer wants a
full-list or not when the observer is attached?
That would do the trick nicely!
--
Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Olli Pettay
Tue, 28 Jun 2011 04:32:14 -0700
These are *not* DOM-Event listeners. No DOM Events are created, there
are no capture phases or bubbling phases. Instead you register a
listener on the node you are interested in being notified about, and
will get a call after a mutation takes place.
Olli Pettay
Tue, 28 Jun 2011 04:32:14 -0700
These are *not* DOM-Event listeners. No DOM Events are created, there
are no capture phases or bubbling phases. Instead you register a
listener on the node you are interested in being notified about, and
will get a call after a mutation takes
On 07/02/2011 09:27 PM, Dave Raggett wrote:
Olli Pettay
Tue, 28 Jun 2011 04:32:14 -0700
These are *not* DOM-Event listeners. No DOM Events are created, there
are no capture phases or bubbling phases. Instead you register a
listener on the node you are interested in being notified about,
On Sat, Jul 2, 2011 at 10:46 AM, John J. Barton
johnjbar...@johnjbarton.com wrote:
1) break on mutation. In Firebug we add DOM mutation listeners to
implement graphical breakpoints. The replacement would work fine for
local, element observation breakpoints like add/remove attribute.
If my goal
On 07/02/2011 08:46 PM, John J. Barton wrote:
Olli Pettay
Tue, 28 Jun 2011 04:32:14 -0700
These are *not* DOM-Event listeners. No DOM Events are created, there
are no capture phases or bubbling phases. Instead you register a
listener on the node you are interested in being notified about, and
On 7/2/11 1:46 PM, John J. Barton wrote:
2) element transformation. The replacement fires after a mutation.
Library or tools that want to transform the application dynamically want
to get notification before the mutation. A common solution then is
to bracket changes:
beforeChange or
On 7/2/11 2:27 PM, Dave Raggett wrote:
n.b. the current mutation events work nicely for the document editing
use cases.
Only if you have full control over the set of all registered listeners.
If you do not, you're SOL, because current mutation events can be
delivered out of order if
14 matches
Mail list logo
