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.
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
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
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:
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
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
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
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
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
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
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 {
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
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
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
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
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
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
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
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
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
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
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
22 matches
Mail list logo
