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
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
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
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
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
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
On Thu, Sep 8, 2011 at 1:16 PM, Bryan Sullivan bls...@gmail.com 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
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
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.
On Thu, Sep 8, 2011 at 1:56 PM, Bryan Sullivan bls...@gmail.com 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
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
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
On Thu, Sep 8, 2011 at 3:13 PM, Bryan Sullivan bls...@gmail.com 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.
On Thu, Sep 8, 2011 at 3:24 PM, Bryan Sullivan bls...@gmail.com 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
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 not
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 gl...@zewt.org wrote:
On Thu, Sep 8, 2011 at 3:24 PM, Bryan Sullivan
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
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,
On Thu, Sep 8, 2011 at 1:13 PM, Ian Hickson i...@hixie.ch 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
19 matches
Mail list logo
