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: DOM4 not compatible with ACID3 tests

On Thu, Sep 8, 2011 at 1:13 PM, Ian Hickson wrote: > On Thu, 8 Sep 2011, Jonas Sicking wrote: >> >> The new DOM-Core specification changes some of the behavior for DocType >> nodes to make them act more like all other nodes in the DOM. >> Specifically: >> >> 1. They always have a ownerDocument >>

[Bug 14094] New: add example where you listen for and use an event other than 'message'. see

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14094 Summary: add example where you listen for and use an event other than 'message'. see

[Bug 14093] New: Just to throw out an idea, to allow use of the XML parser, and alert() for debugging, one could implement web workers as simply another open page in the browser, with full access to

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14093 Summary: Just to throw out an idea, to allow use of the XML parser, and alert() for debugging, one could implement web workers as simply another open page in the browser, with

Re: DOM4 not compatible with ACID3 tests

On Thu, 8 Sep 2011, Jonas Sicking wrote: > > The new DOM-Core specification changes some of the behavior for DocType > nodes to make them act more like all other nodes in the DOM. > Specifically: > > 1. They always have a ownerDocument > 2. They can move between, both using explicit calls to Ad

Re: [EventSource] Is the field name "event" supported in current browsers?

Thanks for the explanation and examples. I've got it now. I agree it would help if the spec was clearer and had some more examples. I will see what I can offer. Bryan On Thu, Sep 8, 2011 at 12:41 PM, Glenn Maynard wrote: > On Thu, Sep 8, 2011 at 3:24 PM, Bryan Sullivan wrote: > >> I am trying

Re: [EventSource] Question on event type

OK, maybe I'm getting closer to understanding this. From your example, when the "event" field is set, it's not a "message" event that is dispatched but an event of type "event name", so in order to see those events, I need to use the addEventListener interface for the eventsource object (they will

Re: [EventSource] Is the field name "event" supported in current browsers?

On Thu, Sep 8, 2011 at 3:24 PM, Bryan Sullivan wrote: > I am trying to develop a test for eventsource, and am finding that when I > include an "event" field in an eventsource stream, the onmessage events are > never fired (if I don't send the "event" field, just "data" fields, the > events *are*

Re: [EventSource] Question on event type

On Thu, Sep 8, 2011 at 3:13 PM, Bryan Sullivan wrote: > That would seem to be the obvious way to access it, but does not seem to be > working for current implementations of eventsource. That's why I was unsure > of how to access it. I guess there are some other issues at hand here. I > need to fi

[EventSource] Is the field name "event" supported in current browsers?

Hi all, I am trying to develop a test for eventsource, and am finding that when I include an "event" field in an eventsource stream, the onmessage events are never fired (if I don't send the "event" field, just "data" fields, the events *are* fired). This occurs in FF, Safari, and Chrome (latest e

Re: [EventSource] Question on event type

That would seem to be the obvious way to access it, but does not seem to be working for current implementations of eventsource. That's why I was unsure of how to access it. I guess there are some other issues at hand here. I need to figure out what they are first, and will start another thread for

Re: [EventSource] Question on event type

On Thu, Sep 8, 2011 at 1:56 PM, Bryan Sullivan wrote: > Thanks for the help. > > So when you say "the name of the event", how in JavaScript do I access the > name of the event, e.g. to test it? Accessing the data (event.data) works, > but how do access the name? > The type (or name) of the even

Re: [EventSource] Question on event type

Thanks for the help. So when you say "the name of the event", how in JavaScript do I access the name of the event, e.g. to test it? Accessing the data (event.data) works, but how do access the name? In your example, event.data is output but I don't see you accessing or using the event name. Tha

RE: rename DOM Core to DOM4; deadline Sept 9

On Wednesday, September 07, 2011 9:53 AM, Arthur Barstow wrote: > It appears the majority of the people that voiced an opinion on this > thread prefer "DOM4". > > If anyone objects to DOM4, please speak up by September 9 at the latest > and include the rationale for your objection as well as an a

Re: [EventSource] Question on event type

On Thu, Sep 8, 2011 at 1:16 PM, Bryan Sullivan wrote: > The event type for the MessageEvent is "message" (in all browsers I have tested, and there is no other "type" attribute defined for MessageEvent. So if I send from my server a line "event: foo\n", I would expect from reading above that the ev

[EventSource] Question on event type

Hi all, Trying to implement a test for eventsource, it's unclear to me in the sequence below, how item 4 is to be implemented and coded for by a developer: (extract from http://www.w3.org/TR/eventsource/) When the user agent is required to *dispatch the event*, then the user agent must act as fo

[Bug 14086] New: When performing AJAX type queries, they are already asynchronous and already occur in another thread. However, I have found that parsing the XML reply and converting that to a repr

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14086 Summary: When performing AJAX type queries, they are already asynchronous and already occur in another thread. However, I have found that parsing the XML reply and converting

[Bug 14084] New: Hi! Returning a null from getItem() if the key does not exist is downright semantically wrong. null is a full-fledged value which can be serialized (JSONed), and is NOT the value we

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14084 Summary: Hi! Returning a null from getItem() if the key does not exist is downright semantically wrong. null is a full-fledged value which can be serialized (JSONed), and is N

[Bug 14083] New: status box is too big. wrong id?

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14083 Summary: status box is too big. wrong id? Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#cro ssDocument

Re: DOM4 not compatible with ACID3 tests

On 09/08/2011 10:23 AM, Jonas Sicking wrote: Hi All, The new DOM-Core specification changes some of the behavior for DocType nodes to make them act more like all other nodes in the DOM. Specifically: 1. They always have a ownerDocument 2. They can move between, both using explicit calls to Adop

DOM4 not compatible with ACID3 tests

Hi All, The new DOM-Core specification changes some of the behavior for DocType nodes to make them act more like all other nodes in the DOM. Specifically: 1. They always have a ownerDocument 2. They can move between, both using explicit calls to AdoptNode, and implicit adoption during for example