Re: [whatwg] will all event types bubble? e.g. focus
Peter Michaux wrote: Using delegate listeners in JavaScript is a technique that has grown quite popular. Not sure what you mean here - I may guess it right or wrong. A minimal example would be always useful. Not all event types bubble, however, so using pure delegate solutions is impossible. So this 'delegate' technique doesn't work well with capturing event listeners? Will the DOM2 non-bubbling event types, like focus, bubble in the new DOM standard? Why you ask this here? W3C is producing the next DOM 3 Events spec. http://www.w3.org/TR/DOM-Level-3-Events/ -Olli Thanks, Peter
Re: [whatwg] [Whatwg] Parsing: Greater-than characters in doctype
On Thu, 14 Feb 2008 06:18:58 +0100, Ian Hickson [EMAIL PROTECTED] wrote: I looked into these, and frankly, I'm reluctant to add them to the spec. I haven't seen a huge number of sites that depend on these, and the other browsers don't seem to particularly require it. Unless someone has a good reason to do otherwise, I say we skip this. That makes sense, but, then I'd like doctypes to be closed at the first even if it's in a FPI or SI, to match Opera, Safari and Firefox, and to allow implementations to do doctype analysis in the parser stage instead of in the tokenizer stage should they so wish, or skip doctype analysis altogether if it is of no interest to them... i.e., I'd like the character in these states: DOCTYPE public identifier (double-quoted) state DOCTYPE public identifier (single-quoted) state DOCTYPE system identifier (double-quoted) state DOCTYPE system identifier (single-quoted) state ...to be a parse error, mark the doctype as incorrect, emit the token, and switch to the data state. -- Simon Pieters Opera Software
[whatwg] reply() extension to postMessage()
Hi, Given that everyone is now updating their postMessage() code anyway, I wonder if it's possible to quickly make another minor tweak. The proposal is to remove the source attribute from MessageEvent and replace it with a reply() method. The semantics of the reply() are probably best described in terms of equivalence. That is, e.reply(message) is equivalent to e.source.postMessage(message, e.origin) except that the latter won't work anymore when reply() is added. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] reply() extension to postMessage()
On Thu, 14 Feb 2008 17:30:15 +0100, Aaron Boodman [EMAIL PROTECTED] wrote:
If we're going to add reply, I would like to easily be able to get
replies to a specific message. So extend postMessage to accept a
callback, and then either have reply() call this callback. Like this:
// sender:
someWindow.postMessage(hello!, function(response) {
alert(got response: + response);
});
// receiver
window.addEventListener(message, function(e) {
alert(got message: + e.message);
e.reply(good day);
});
You really want reply() to have that callback too (for longer
conversations) and at that point it starts getting icky.
I came up with another idea to address the issue you mention. We let
postMessage() return a UUID and give MessageEvent an id attribute. When
postMessage() is invoked a UUID is generated and returned. This same UUID
is set on the event that is dispatched. When reply is invoked on that
event object it creates an event that again has the same UUID. Both
parties can have multiple conversations that way by checking the UUID of
the message.
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: [whatwg] reply() extension to postMessage()
On Thu, Feb 14, 2008 at 8:58 AM, Anne van Kesteren [EMAIL PROTECTED] wrote: You really want reply() to have that callback too (for longer conversations) and at that point it starts getting icky. Ah, good point. I came up with another idea to address the issue you mention. We let postMessage() return a UUID and give MessageEvent an id attribute. When postMessage() is invoked a UUID is generated and returned. This same UUID is set on the event that is dispatched. When reply is invoked on that event object it creates an event that again has the same UUID. Both parties can have multiple conversations that way by checking the UUID of the message. I'm trying to get away from checking IDs because the common case I have seen is either one-way (tell the widget to do something), or two-way (ask the widget for some piece of information). Having to match up IDs is a pain for a simple question/answer. Perhaps there could be a conversation object or something. Maybe that's getting too weird though... - a
[whatwg] IE6 vs XHR vs XMLNS
Seen in http://krijnhoetmer.nl/irc-logs/whatwg/20080214#l-339: # # [16:49] hsivonen on a second though, that won't work for XHR # # [16:49] hsivonen so, no # # [16:50] hsivonen since IE XHR is DOM Level 1, stuff like the Flickr API have to be XML 1.0 without XMLNS # # [16:50] hsivonen yay for XMLNS # # [16:51] annevk i don't understand # # [16:51] annevk xhr requires a conforming xmlns parser # # [16:52] hsivonen IE6 doesn't expose a namespace-aware API for XHR-loaded docs, IIRC # # [16:53] hsivonen and Safari as shipped with Panther missealized namespaced XML # # [16:53] hsivonen so RESTful XML APIs that want to be XHR-compatible have to live in the namespaceless XML 1.0 ( 5th ed.) world That is incorrect. IE6 XHR is part of MSXML, which deals just fine with XMLNS, except for the absence of some DOM L2 methods. Keep in mind that XHR has been invented for the purpose of Outlook Web Access talking WebDAV to MS Exchange, which certainly would not be possible without support for XML namespaces. BR, Julian
Re: [whatwg] IE6 vs XHR vs XMLNS
On Feb 14, 2008, at 19:45, Julian Reschke wrote: Seen in http://krijnhoetmer.nl/irc-logs/whatwg/20080214#l-339: # # [16:49] hsivonen on a second though, that won't work for XHR # # [16:49] hsivonen so, no # # [16:50] hsivonen since IE XHR is DOM Level 1, stuff like the Flickr API have to be XML 1.0 without XMLNS # # [16:50] hsivonen yay for XMLNS # # [16:51] annevk i don't understand # # [16:51] annevk xhr requires a conforming xmlns parser # # [16:52] hsivonen IE6 doesn't expose a namespace-aware API for XHR-loaded docs, IIRC # # [16:53] hsivonen and Safari as shipped with Panther missealized namespaced XML # # [16:53] hsivonen so RESTful XML APIs that want to be XHR- compatible have to live in the namespaceless XML 1.0 ( 5th ed.) world That is incorrect. IE6 XHR is part of MSXML, which deals just fine with XMLNS, except for the absence of some DOM L2 methods. Perhaps. I can't verify now. However, I have developed a cross-browser XHR-intensive app when IE6 was the current IE and what came with Panther was the current Safari. The problems with namespaces were very real. The practical effect of the lack of Level 2 methods in IE6 and the brokenness* of the XHR XML serializer in older WebKit is that using namespaces with cross-browser XHR is at least hard and using Level 1 DOM APIs with namespaceless XML 1.0 ( 5th ed.) is the practical single-codepath cross-browser solution. * http://bugs.webkit.org/show_bug.cgi?id=5262 -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] postMessage and serialization
On Tue, Feb 12, 2008 at 4:57 PM, Ian Hickson [EMAIL PROTECTED] wrote: This was originally how the DOM Storage API worked, but there was significant pushback on this, resulting in the current string-only approach. When I came to writing the postMessage API, I considered that feedback and decided not to bother even trying. I see. One difference between DOM Storage and postMessage is that with DOM Storage at least you had name and value separated out. For postMessage you just get a single value field. Passing booleans, numbers and strings is trivial using the current API. Passing arrays of booleans and numbers is trivial too. Passing objects, or arrays of strings, arrays, or objects, is more complex, but as you point out, it can be done using JSON libraries. Since it is likely that JSON will be supported natively by UAs in due course, it seems better to wait for that support rather than adding type support to postMessage(). I've seen performance problems using JS-based JSON libraries with Gears workers. In those cases, the developer had to revert to hacky custom message formats where what he really wanted was to pass an object. Someday, all browsers will have fast JSON support built in, but that will be awhile for IE. Gears could implement postMessage today, but we've looked into implementing fast JSON support and it seems difficult to do much better than you can do with script without access to the script engine internals. It seems that most messages will consist either of simple strings, or of complex data structures (objects). Reconstructing JS objects is not a trivial operation; you have to worry about references into other parts of the structure, getters and setters that hang or throw or return infinite arrays, functions, members that aren't enumerable, etc. I'd rather not go down that rat hole with v1. You'll have these problems with JSON too though, right? Whatever the rules are, we'll have to figure them out eventually. - a
Re: [whatwg] IE6 vs XHR vs XMLNS
Henri Sivonen wrote: On Feb 14, 2008, at 19:45, Julian Reschke wrote: Seen in http://krijnhoetmer.nl/irc-logs/whatwg/20080214#l-339: # # [16:49] hsivonen on a second though, that won't work for XHR # # [16:49] hsivonen so, no # # [16:50] hsivonen since IE XHR is DOM Level 1, stuff like the Flickr API have to be XML 1.0 without XMLNS # # [16:50] hsivonen yay for XMLNS # # [16:51] annevk i don't understand # # [16:51] annevk xhr requires a conforming xmlns parser # # [16:52] hsivonen IE6 doesn't expose a namespace-aware API for XHR-loaded docs, IIRC # # [16:53] hsivonen and Safari as shipped with Panther missealized namespaced XML # # [16:53] hsivonen so RESTful XML APIs that want to be XHR-compatible have to live in the namespaceless XML 1.0 ( 5th ed.) world That is incorrect. IE6 XHR is part of MSXML, which deals just fine with XMLNS, except for the absence of some DOM L2 methods. Perhaps. I can't verify now. However, I have developed a cross-browser XHR-intensive app when IE6 was the current IE and what came with Panther was the current Safari. The problems with namespaces were very real. In which case blame Safari, not IE. The practical effect of the lack of Level 2 methods in IE6 and the The only problem in IE6 I'm aware of is the lack of createElementNS and createAttributeNS, for which there's a simple workaround. (No, I'm not defending MS, just clarifying; the lack of these methods has caused thousands of postings in mailing lists and news groups, and is a nice indicator about how MS thinks (or use to think) of their developers). brokenness* of the XHR XML serializer in older WebKit is that using namespaces with cross-browser XHR is at least hard and using Level 1 DOM APIs with namespaceless XML 1.0 ( 5th ed.) is the practical single-codepath cross-browser solution. * http://bugs.webkit.org/show_bug.cgi?id=5262 XMLSerializer is neither part of DOM level 2 nor XHR, right? BR, Julian
Re: [whatwg] reply() extension to postMessage()
On Thu, 14 Feb 2008, Anne van Kesteren wrote:
Given that everyone is now updating their postMessage() code anyway, I
wonder if it's possible to quickly make another minor tweak. The
proposal is to remove the source attribute from MessageEvent and replace
it with a reply() method. The semantics of the reply() are probably best
described in terms of equivalence. That is,
e.reply(message)
is equivalent to
e.source.postMessage(message, e.origin)
except that the latter won't work anymore when reply() is added.
You might still need the source in order to navigate it, depending on what
you're doing. (You can always get a hold of the relevant Window object if
it can send you messages, since access to Windows is symmetric.)
In general I think a better way to do this would be to use a pipe concept,
as Dimitri suggests lower down.
On Thu, 14 Feb 2008, Aaron Boodman wrote:
If we're going to add reply, I would like to easily be able to get
replies to a specific message. So extend postMessage to accept a
callback, and then either have reply() call this callback. Like this:
This could get really confusing from a GC perspective if a script starts
keeping track of all its Event objects, since they then each have to keep
a function alive on the other side, and Events in browsers probably
aren't set up to do that today. It also seems somewhat odd that this sets
up an asymmetric relationship.
On Thu, 14 Feb 2008, Henry Mason wrote:
Ooo, I like that idea. I have one concern, however. Presumably, the
message event that is sent as a reply could itself be replied. Since
postMessage's spec currently says:
The postMessage() method must only return once the event dispatch has
been completely processed by the target document (i.e. all three of the
capture, target, and bubble phases have been done, and event listeners
have been executed as appropriate).
...this behavior could cause some somewhat nasty infinite recursion. So
what if we made reply() asynchronous so that the the reply message event
doesn't need to be dispatched on the original message posting document
until after the original postMessage from the sender is finished
processing?
This problem exists today with postMessage() too. Do people think we
should go fully asynchronous?
On Thu, 14 Feb 2008, Anne van Kesteren wrote:
You really want reply() to have that callback too (for longer
conversations) and at that point it starts getting icky.
Indeed.
I came up with another idea to address the issue you mention. We let
postMessage() return a UUID and give MessageEvent an id attribute.
When postMessage() is invoked a UUID is generated and returned. This
same UUID is set on the event that is dispatched. When reply is invoked
on that event object it creates an event that again has the same UUID.
Both parties can have multiple conversations that way by checking the
UUID of the message.
I don't thikn we want to be doing ID checking. That's icky too. :-)
On Thu, 14 Feb 2008, Aaron Boodman wrote:
I'm trying to get away from checking IDs because the common case I have
seen is either one-way (tell the widget to do something), or two-way
(ask the widget for some piece of information). Having to match up IDs
is a pain for a simple question/answer.
Perhaps there could be a conversation object or something. Maybe that's
getting too weird though...
No, I think that's the direction to go in.
On Thu, 14 Feb 2008, Dimitri Glazkov wrote:
Speaking of a conversation object: I've been using a Pipe abstraction
with Gears workers to some degree of success. I am wondering if/how
something like this could exist at a spec level.
Over the past few days I've been working on something similar:
http://hixie.ch/specs/dom/messages/0.9
Would this address the problem?
It would make the earlier example look like this:
// sender:
var pipe = window.getNewEndPoints();
pipe.endPoint1.onmessage = function(e) {
alert(got response: + e.message);
};
someWindow.postMessage(hello!, pipe.endPoint2);
// receiver
window.addEventListener(message, function(e) {
alert(got message: + e.message);
e.endPoint.postMessage(good day);
});
...except that the receiver could be extended to expect messages back:
// receiver
window.addEventListener(message, function(e) {
alert(got message: + e.message);
e.endPoint.onmessage = function (e) {
alert(got a specific message: + e.message);
};
e.endPoint.postMessage(good day);
});
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
Since postMessage API is looking more an more like the Gears worker
messaging API (or better), can we go one step further and introduce
workers into the HTML5, defined as invisible windows with limited
capabilities:
WorkerWindow openWorker(in DOMString url);
with:
interface WorkerWindow {
// for consistency with Window
readonly attribute Window window;
readonly attribute Window self;
// caps
readonly attribute ClientInformation navigator;
// session/local storage
readonly attribute Storage sessionStorage;
...
// database stuff
Database openDatabase(...)
// to open new worker windows
WorkerWindow openWorker(in DOMString url);
// messaging
void postMessage(...)
// some events
attribute EventListener onabort;
attribute EventListener onload;
attribute EventListener onunload;
}
or something like that?
:DG
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
Well, as long as you've brought it up, I was working on a proposal too:
http://code.google.com/p/google-gears/wiki/HTML5WorkerProposal
- a
On Thu, Feb 14, 2008 at 11:34 AM, Dimitri Glazkov
[EMAIL PROTECTED] wrote:
Since postMessage API is looking more an more like the Gears worker
messaging API (or better), can we go one step further and introduce
workers into the HTML5, defined as invisible windows with limited
capabilities:
WorkerWindow openWorker(in DOMString url);
with:
interface WorkerWindow {
// for consistency with Window
readonly attribute Window window;
readonly attribute Window self;
// caps
readonly attribute ClientInformation navigator;
// session/local storage
readonly attribute Storage sessionStorage;
...
// database stuff
Database openDatabase(...)
// to open new worker windows
WorkerWindow openWorker(in DOMString url);
// messaging
void postMessage(...)
// some events
attribute EventListener onabort;
attribute EventListener onload;
attribute EventListener onunload;
}
or something like that?
:DG
Re: [whatwg] reply() extension to postMessage()
On Thu, Feb 14, 2008 at 11:16 AM, Adam Barth [EMAIL PROTECTED] wrote: On Thu, Feb 14, 2008 at 10:46 AM, Ian Hickson [EMAIL PROTECTED] wrote: This problem exists today with postMessage() too. Do people think we should go fully asynchronous? I had assumed it was asynchronous (and I think others might make the same assumption) because the PostMessage API in Windows is asynchronous. The synchronous version in the Windows API is called SendMessage. I assumed it was asynchronous too. - a
Re: [whatwg] reply() extension to postMessage()
On Thu, Feb 14, 2008 at 10:46 AM, Ian Hickson [EMAIL PROTECTED] wrote: This problem exists today with postMessage() too. Do people think we should go fully asynchronous? I had assumed it was asynchronous (and I think others might make the same assumption) because the PostMessage API in Windows is asynchronous. The synchronous version in the Windows API is called SendMessage. Adam
Re: [whatwg] reply() extension to postMessage()
On Feb 14, 2008, at 1:46 PM, Ian Hickson wrote: This problem exists today with postMessage() too. Do people think we should go fully asynchronous? No objections from me... -Henry
Re: [whatwg] IE6 vs XHR vs XMLNS
Henri Sivonen wrote: The practical effect of the lack of Level 2 methods in IE6 and the The only problem in IE6 I'm aware of is the lack of createElementNS and createAttributeNS, for which there's a simple workaround. Well, those methods are rather central to synthesizing namespaced DOM trees. and there's a simple workaround. brokenness* of the XHR XML serializer in older WebKit is that using namespaces with cross-browser XHR is at least hard and using Level 1 DOM APIs with namespaceless XML 1.0 ( 5th ed.) is the practical single-codepath cross-browser solution. * http://bugs.webkit.org/show_bug.cgi?id=5262 XMLSerializer is neither part of DOM level 2 nor XHR, right? void send(in Document data); is part of XHR and causes a serializer to run. It wasn't clear to me that it's the same serializer (in Safari). Yes, it appears that's a problem which makes that version of Safari unusable for API using XML namespaces. Has it been fixed since then? It isn't clear to me how you want the editor to take what you are saying into account in a WHATWG deliverable. The relevance of my IRC remarks was that unnamespaced XML is alive in XHR APIs due to browser problems and, therefore, we can't unconditionally make createElement(foo) equivalent to createElementNS(http://www.w3.org/1999/xhtml;, foo) in DOM5. Is wasn't aware of the context; I just wanted to correct an incorrect statement about IE6. BR, Julian
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
LOL. Who else has been quietly concocting a worker spec? This very much along the lines of what I was thinking. Equating worker to (or drawing parallels with) a window object is the approach that would make workers easier to understand for developers, IMHO. I am not quite sure yet about DOM access/interaction. On 2/14/08, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 14 Feb 2008, Aaron Boodman wrote: Well, as long as you've brought it up, I was working on a proposal too: http://code.google.com/p/google-gears/wiki/HTML5WorkerProposal As was I. :-) http://www.hixie.ch/specs/dom/workers/0.9 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
Since postMessage API is looking more an more like the Gears worker messaging API (or better), can we go one step further and introduce workers into the HTML5, defined as invisible windows with limited capabilities: Why call these windows at all? They seem to have no relationship physical windows, or the JavaScript window object. WorkerWindow openWorker(in DOMString url); Can I supply a URL to an HTML file here? Does the file load and parse as an HTML document? Is the document accessible to the worker? Since the whole point of the worker is to do JavaScript work, should this string be a script instead of a URL? How do I pass data to a worker? Is there an API contract regarding synchronization and/or order of execution? // some events attribute EventListener onabort; attribute EventListener onload; attribute EventListener onunload; Why these events? When is a worker considered loaded? Unloaded? Aborted? Thanks, Geoff
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
On Thu, Feb 14, 2008 at 11:34 AM, Dimitri Glazkov [EMAIL PROTECTED] wrote: // caps readonly attribute ClientInformation navigator; I forgot about navigator in my proposal. That is another one that has been asked for in Gears workers. Added! - a
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
On Thu, 14 Feb 2008, Aaron Boodman wrote: Well, as long as you've brought it up, I was working on a proposal too: http://code.google.com/p/google-gears/wiki/HTML5WorkerProposal As was I. :-) http://www.hixie.ch/specs/dom/workers/0.9 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
On Thu, Feb 14, 2008 at 3:05 PM, Geoffrey Garen [EMAIL PROTECTED] wrote: Since postMessage API is looking more an more like the Gears worker messaging API (or better), can we go one step further and introduce workers into the HTML5, defined as invisible windows with limited capabilities: Why call these windows at all? They seem to have no relationship physical windows, or the JavaScript window object. No relation. It might be easier for some developers to get it if associated with the window. I think it's a bit of a rough metaphor myself, and did not call the object Window in my proposal, but WorkerContext. WorkerWindow openWorker(in DOMString url); Can I supply a URL to an HTML file here? Does the file load and parse as an HTML document? Is the document accessible to the worker? No the content of the URL must be JavaScript. In fact it must be JavaScript intended to be used in a worker to do anything useful. Since the whole point of the worker is to do JavaScript work, should this string be a script instead of a URL? This is how Gears used to work and it was very inconvenient. Web apps do not really have access to their source code as a string conveniently. They could use XHR to request a script file and then send it into the worker,but why make them do this? How do I pass data to a worker? Please see either Ian's or my proposal earlier in this thread for an example of how this could work. Basically, like postMessage(). Is there an API contract regarding synchronization and/or order of execution? I think that the API should guarantee that the script is executed on another thread. I don't think that the API should guarantee that anything has happened when createWorker*() returns, as UA's will want to load the script file asynchronously. However, I think that developers should be able to start sending messages to workers immediately, before the worker has loaded. These messages should be queued and delivered when the worker loads. - a
Re: [whatwg] Meaning of the title= attribute
On Wed, 29 Nov 2006, Matthew Paul Thomas wrote: On Nov 27, 2006, at 2:26 PM, Matthew Raymond wrote: Alexey Feldgendler wrote: ... In your opinion, if %Text attributes (title, alt) in HTML allowed nested markup somehow, wouldn't the title attribute sufficient for fulfilling the use case of captions? No, because a caption is not necessarily advisory information[1], which is what the |title| attribute is defined as containing. ... As in, html title=PG-13? Eh, that's not really what title= is for. title= is for please use this for tooltips so alt= isn't ruined. :-) A useful medium-independent description of title= might be Supplemental text that is relevant only when concentrating on the element to which it applies. It's not clear to me that this is especially better than what it says now. In fact, it might be worse (what's supplemental about an image credit?). I've left the text as is for now. Please do detail any concerns you have with the current text, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
