On 9/4/11 6:39 AM, Anne van Kesteren wrote:
On Sun, 04 Sep 2011 15:12:45 +0200, Arthur Barstow
art.bars...@nokia.com wrote:
The CfC to publish a new WD of DOM Core was blocked by this RfC. I
will proceed with a request to publish a new WD of DOM Core in TR/.
The name DOM Core will be used for
On 8/8/11 5:13 PM, Jonas Sicking wrote:
To solve this I propose we add two new values to .responseType:
streaming-text and streaming-arraybuffer.
I think this would be a very useful feature. I only have naming nits:
1) What do you think of textstream instead of streaming-text?
Similarly for
On 8/4/11 12:21 PM, Anne van Kesteren wrote:
On Thu, 04 Aug 2011 21:06:58 +0200, Adrian Bateman
adria...@microsoft.com wrote:
The name was changed. We weren't terribly keen on the change. It is now
causing problems. I've had multiple people contact me confused about
this. We should fix the
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 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 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 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 7/4/11 2:22 PM, Olli Pettay wrote:
Handling of insertedNodes/removedNodes becomes tricky if there are
several listeners and the first one of those adds or removes child
nodes. Should the listeners which will be called later get the same
insertedNodes/removedNodes as the first listener, or
On 7/5/11 12:12 PM, Boris Zbarsky wrote:
On 7/5/11 3:00 PM, David Flanagan wrote:
Boris, you have hinted that making the DOM readonly would cause all
kinds of problems, such as: a mutation listener that attempted to set
certain global variables would throw an exception. I'm coming at this
from
On 6/30/11 5:43 PM, Ryosuke Niwa wrote:
On Thu, Jun 30, 2011 at 5:16 PM, Boris Zbarsky bzbar...@mit.edu
mailto:bzbar...@mit.edu wrote:
On 6/30/11 7:01 PM, Ryosuke Niwa wrote:
What do you mean by it being partially inserted? Like document
relationship, etc... aren't
On 7/1/11 12:13 PM, Boris Zbarsky wrote:
On 7/1/11 3:05 PM, David Flanagan wrote:
I don't think I really explained my use case on this list. See
https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c23 and
https://bugzilla.mozilla.org/show_bug.cgi?id=641821#c25
And https://bugzilla.mozilla.org
On 7/1/11 2:06 PM, Rafael Weinstein wrote:
On Fri, Jul 1, 2011 at 12:43 PM, David Flanagandflana...@mozilla.com wrote:
As I see it, the test of sufficiency of set of mutation event is if you can
use them to mirror a document tree. And in my case I'm trying to do that
across a process boundary
On 7/1/11 3:06 PM, Olli Pettay wrote:
On 07/02/2011 12:59 AM, David Flanagan wrote:
But, and I think this is an interesting but, what happens if a node is
removed from the document, has its attributes or data or children
changed and is then re-inserted into the document? If the node has
On 7/1/11 4:09 PM, Ryosuke Niwa wrote:
On Fri, Jul 1, 2011 at 3:47 PM, Rafael Weinstein rafa...@google.com
mailto:rafa...@google.com wrote:
If you want to discover mutations to nodes while outside the tree,
then having a single subtree observer isn't sufficient. You'll need an
a method of the node to
which the listener was added? That is, inside the callback function
won't the value of 'this' be the same as the value of the aNode argument?
David Flanagan
Aryeh Gregor wrote:
Maybe this is a stupid question, since I'm not familiar at all with
the use-cases involved, but why can't we delay firing the
notifications until the event loop spins? If we're already delaying
them such that there are no guarantees about what the DOM will look
like by the
On 6/30/11 12:26 PM, Boris Zbarsky wrote:
On 6/30/11 2:56 PM, David Flanagan wrote:
I'll add my own possibly stupid question... Can we go in the opposite
direction and fire mutation events immediately without queuing, but
forbid any DOM modifications from the event callbacks?
Forbid DOM
On 6/30/11 1:45 PM, James Robinson wrote:
On Thu, Jun 30, 2011 at 1:15 PM, David Flanagan dflana...@mozilla.com
mailto:dflana...@mozilla.com wrote:
This is actually a pretty hard problem to solve, and still
wouldn't really solve the performance issues for DOM events
On 02/17/2011 06:55 AM, Arun Ranganathan wrote:
- Original Message -
Step 7 of the FileReader.readAsDataURL() algorithm currently just
says:
Set the result attribute to be blob's data content represented as a
Data URL
It should, I think, say something about the using the type of
Step 7 of the FileReader.readAsDataURL() algorithm currently just says:
Set the result attribute to be blob's data content represented as a Data URL
It should, I think, say something about the using the type of the blob
as well as the content of the blob when forming the data:// URL.
And
I just noticed this in the XHR2 spec:
If data is a Blob
If the object is of type File and its mediaType attribute is not the empty
string let mime type be its value.
I think this must reference an out-of-date version of the File spec.
Currently all Blobs have a type attribute and there
On 11/10/2010 03:00 PM, Tab Atkins Jr. wrote:
So you prefer that .responseType take a string value as opposed to an
integer enum value? Darin Fisher had the idea that introspection of the
supported values would be easier as an enum.
Yes, I think using an enum would be *extremely* verbose,
about David's proposal?
Chris
On Wed, Nov 3, 2010 at 10:47 AM, David Flanagan da...@davidflanagan.com
mailto:da...@davidflanagan.com wrote:
On 11/02/2010 07:06 PM, Boris Zbarsky wrote:
On 11/2/10 4:04 PM, David Flanagan wrote:
Boris (Mozilla) worries that creating a new
On 11/02/2010 07:06 PM, Boris Zbarsky wrote:
On 11/2/10 4:04 PM, David Flanagan wrote:
Boris (Mozilla) worries that creating a new mode in which responseText
is unavailable will break jQuery applications.
And various others where the consumer of the data and the XHR creator
are not the same
Is this a fair summary of this thread?
Chris (Apple) worries that having to support both responseText and
responseArrayBuffer will be memory inefficient because implementations
will end up with both representations in memory.
James (Google) worries that synchronously reading bytes from the
On 11/02/2010 01:30 PM, James Robinson wrote:
On Tue, Nov 2, 2010 at 1:04 PM, David Flanagan da...@davidflanagan.com
mailto:da...@davidflanagan.com wrote:
Is this a fair summary of this thread?
Chris (Apple) worries that having to support both responseText and
responseArrayBuffer
the nature of
Blobs... I'd love to know what it is!)
David Flanagan
On 10/28/2010 06:24 PM, Boris Zbarsky wrote:
On 10/28/10 5:22 PM, David Flanagan wrote:
In fact, I'd go further and ask why the blob case needs to be special
cased at all. The bytes are stored somewhere. Returning them as a blob
doesn't seem any harder than returning them as an ArrayBuffer
Just a minor nit: in the 2nd sentence of 3.1.4, the spec uses MAY in
red where I believe you mean just an ordinary non-normative may.
David Flanagan
29 matches
Mail list logo
