On 07/05/2011 12:02 AM, Adam Klein wrote:
On Mon, Jul 4, 2011 at 1:45 PM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 07/04/2011 08:16 PM, Adam Klein wrote:
On Mon, Jul 4, 2011 at 9:57 AM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 07/04/2011 07:28 PM, Ojan Vafai wrote:
The only bit
On 07/04/2011 09:14 PM, John J. Barton wrote:
On 7/4/2011 9:38 AM, Olli Pettay wrote:
On 07/04/2011 07:23 PM, John J. Barton wrote:
On 7/3/2011 1:23 PM, Boris Zbarsky wrote:
On 7/3/11 2:43 PM, John J. Barton wrote:
I'm not sure what you're asking... The whole point of the proposed
model
On 07/01/2011 02:17 AM, Rafael Weinstein wrote:
On Thu, Jun 30, 2011 at 4:05 AM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 06/30/2011 12:54 AM, Rafael Weinstein wrote:
On Wed, Jun 29, 2011 at 7:13 AM, Aryeh Gregorsimetrical+...@gmail.com
wrote:
On Tue, Jun 28, 2011 at 5:24 PM, Jonas
On 07/06/2011 12:06 AM, Rafael Weinstein wrote:
Respond
On Tue, Jul 5, 2011 at 10:44 AM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 07/01/2011 02:17 AM, Rafael Weinstein wrote:
On Thu, Jun 30, 2011 at 4:05 AM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 06/30/2011 12:54 AM, Rafael
On 07/06/2011 12:18 AM, Olli Pettay wrote:
On 07/06/2011 12:06 AM, Rafael Weinstein wrote:
Respond
On Tue, Jul 5, 2011 at 10:44 AM, Olli Pettayolli.pet...@helsinki.fi
wrote:
On 07/01/2011 02:17 AM, Rafael Weinstein wrote:
On Thu, Jun 30, 2011 at 4:05 AM, Olli Pettayolli.pet...@helsinki.fi
On 07/06/2011 12:48 AM, Rafael Weinstein wrote:
On Tue, Jul 5, 2011 at 2:38 PM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 07/06/2011 12:18 AM, Olli Pettay wrote:
On 07/06/2011 12:06 AM, Rafael Weinstein wrote:
Respond
On Tue, Jul 5, 2011 at 10:44 AM, Olli Pettayolli.pet...@helsinki.fi
On 07/06/2011 08:14 AM, James Robinson wrote:
On Tue, Jul 5, 2011 at 5:51 PM, Ojan Vafai o...@chromium.org
mailto:o...@chromium.org wrote:
On Tue, Jul 5, 2011 at 5:36 PM, Ryosuke Niwa rn...@webkit.org
mailto:rn...@webkit.org wrote:
On Tue, Jul 5, 2011 at 5:27 PM, Rafael
On 07/06/2011 09:12 PM, James Robinson wrote:
On Wed, Jul 6, 2011 at 2:47 AM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 07/06/2011 08:14 AM, James Robinson wrote:
On Tue, Jul 5, 2011 at 5:51 PM, Ojan Vafai o...@chromium.org
mailto:o
On 07/07/2011 10:18 PM, Jonas Sicking wrote:
Hi All,
I've finally caught up on all the emails in this thread. Here are my
impressions so far.
I don't think John J Barton's proposal to fire before mutation
notifications is doable. Trying to make all APIs that would, or
could, mutate the DOM
On 07/08/2011 12:29 AM, Olli Pettay wrote:
On 07/07/2011 10:18 PM, Jonas Sicking wrote:
Hi All,
I've finally caught up on all the emails in this thread. Here are my
impressions so far.
I don't think John J Barton's proposal to fire before mutation
notifications is doable. Trying to make all
On 07/08/2011 01:43 AM, John J Barton wrote:
Rafael Weinstein wrote:
On Thu, Jul 7, 2011 at 1:58 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Jul 7, 2011 at 12:18 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't think John J Barton's proposal to fire before mutation
notifications is
On 07/11/2011 09:23 PM, Ian Hickson wrote:
On Mon, 11 Jul 2011, Jonas Sicking wrote:
On Mon, Jul 11, 2011 at 11:04 AM, Ian Hicksoni...@hixie.ch wrote:
On Fri, 8 Jul 2011, Jonas Sicking wrote:
On the other hand, we should [not] do things now that are likely to
create a more complicated or
On 07/20/2011 02:01 AM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 6:38 PM, Jonas Sickingjo...@sicking.cc wrote:
On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinsteinrafa...@google.com wrote:
So yes, my proposal only solves the usecase outside mutation handlers.
However this is arguably better
On 07/20/2011 06:46 PM, Jonas Sicking wrote:
Hence I'm leaning towards using the almost-asynchronous proposal for
now. If we end up getting the feedback from people that use mutation
events today that they won't be able to solve the same use cases, then
we can consider using the synchronous
On 07/21/2011 01:56 AM, Jonas Sicking wrote:
On Wed, Jul 20, 2011 at 10:30 AM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 07/20/2011 06:46 PM, Jonas Sicking wrote:
Hence I'm leaning towards using the almost-asynchronous proposal for
now. If we end up getting the feedback from people that
On 07/21/2011 06:01 PM, Boris Zbarsky wrote:
On 7/21/11 5:08 AM, Dave Raggett wrote:
Thanks for the explanation. Apps would need a way to disable
notifications during such animation sequences, and would be able to find
another means to serialize the animation (at a higher level).
I'm not sure
Hi all,
here is a bit different proposal for mutation events replacement.
This is using the mostly-sync approach, and batching can make it easier
to use with several simultaneous script libraries; each one would use
their own batch.
For performance reasons it might be useful to have an
/**
* The name of the attribute which was changed, or null.
*/
readonly attribute DOMString attrName;
There should be probably also attribute namespace
void batchAttrChanges(in Node aNode);
A filter could be added here
-void batchAttrChanges(in Node aNode);
+void batchAttrChanges(in Node
On 08/04/2011 10:14 PM, David Flanagan wrote:
On 8/4/11 6:38 AM, Olli Pettay wrote:
Hi all,
here is a bit different proposal for mutation events replacement.
This is using the mostly-sync approach, and batching can make it easier
to use with several simultaneous script libraries; each one
FYI, I'm planning to implement the proposal (using vendor prefixed API)
so that I can create tryserver builds.
I'll post the links to builds here later, hopefully in a few days, when
I find the time to do the actual implementation.
-Olli
On 08/04/2011 04:38 PM, Olli Pettay wrote:
Hi all
On 08/11/2011 03:44 AM, Rafael Weinstein wrote:
Although everyone seems to agree that mutations should be delivered
after the DOM operations which generated them complete, the question
remains:
When, exactly, should mutations be delivered?
The four options I'm aware of are:
1) Immediately
On 08/11/2011 06:13 PM, Rafael Weinstein wrote:
Con:
Since the approach is bound to tasks, it is not clear what should happen
if event loop spins while handling the task. What if some other task
modifies the DOM[1], when should the mutation callbacks fire?
Because of this issue, tasks, which may
On 08/17/2011 04:54 AM, Rafael Weinstein wrote:
TL;DR;
1) ObserveSubtree semantics doesn't provide a robust mechanism for
observing a tree/fragment, and if we don't provide something more
complete, libraries will likely register observers at every node in
the document.
ModificationBatch
be added easily.
-Olli
On 08/10/2011 10:49 PM, Olli Pettay wrote:
FYI, I'm planning to implement the proposal (using vendor prefixed API)
so that I can create tryserver builds.
I'll post the links to builds here later, hopefully in a few days, when
I find the time to do the actual
On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:
All,
Over the last few weeks, a few folks and myself have been working on
fleshing out the vision for the Component Model. Here's what we've
done so far:
* Created a general overview document for behavior attachment problem
on the Web
On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:
All,
Over the last few weeks, a few folks and myself have been working on
fleshing out the vision for the Component Model. Here's what we've
done so far:
* Created a general overview document for behavior attachment problem
on the Web
On 08/25/2011 12:54 PM, Robin Berjon wrote:
Hi all,
On Aug 25, 2011, at 10:49 , Paul Bakaus wrote:
We should definitely open it up for a broader discussion. I think
the right place for the discussion might be the new device apis WG,
which I've cc'ed.
It certainly feels like such an API would
On 08/31/2011 02:00 AM, Ryosuke Niwa wrote:
Greetings all,
During the very constructive meeting in Toronto
http://ehsanakhgari.org/blog/2011-08-31/future-editing-web, we came to
a conclusion that we want events that fire before after user editing
action and execCommand take place. Let us call
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
On 09/07/2011 05:09 PM, Aryeh Gregor wrote:
On Sun, Sep 4, 2011 at 9:12 AM, Arthur Barstowart.bars...@nokia.com wrote:
Some members of the group consider the D3E spec as the highest priority of
our DOM-related specs and they have put considerable resources into that
spec. Doug and Jacob will
On 09/24/2011 12:16 AM, Adam Klein wrote:
Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
proposal for a replacement for Mutation Events.
This proposal represents our best attempt to date at making a set
On 09/26/2011 11:47 AM, Olli Pettay wrote:
On 09/24/2011 12:16 AM, Adam Klein wrote:
Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
proposal for a replacement for Mutation Events.
This proposal represents our
On 09/24/2011 12:16 AM, Adam Klein wrote:
Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
Mozilla (Olli Pettay, Jonas Sicking) have worked together on a
proposal for a replacement for Mutation Events.
This proposal represents our best attempt to date at making a set
On 09/26/2011 09:09 PM, Adam Klein wrote:
On Mon, Sep 26, 2011 at 11:05 AM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 09/24/2011 12:16 AM, Adam Klein wrote:
Chromium (myself, Rafael Weinstein, Erik Arvidsson, Ryosuke Niwa) and
Mozilla (Olli Pettay, Jonas Sicking) have worked together
On 09/24/2011 12:16 AM, Adam Klein wrote:
For each observer, if a registration exists which requests the
matching mutation type and whose observed node set contains the target
node of the mutation, a MutationRecord is appended to the observer's
pending mutation queue. If multiple such
On 09/28/2011 07:01 PM, Adam Klein wrote:
On Tue, Sep 27, 2011 at 1:12 PM, Olli Pettayolli.pet...@helsinki.fi wrote:
On 09/24/2011 12:16 AM, Adam Klein wrote:
For each observer, if a registration exists which requests the
matching mutation type and whose observed node set contains the target
On 10/12/2011 02:00 PM, Sean Hogan wrote:
On 12/10/11 3:26 AM, Tab Atkins Jr. wrote:
On Mon, Oct 10, 2011 at 7:51 PM, Sean Hoganshogu...@westnet.com.au
wrote:
On 24/09/11 7:16 AM, Adam Klein wrote:
- Is free of the faults of the existing Mutation Events mechanism
(enumerated in detail here:
On 10/13/2011 05:51 AM, Sean Hogan wrote:
My main reservation towards the proposal is its complexity - it promises
a lot and I will be surprised if it is as trivial to implement as you
have implied. Even then, I'm expecting that it isn't the improvement
(over the status-quo) that everyone is
On 10/13/2011 11:32 AM, Sean Hogan wrote:
On 13/10/11 2:33 PM, Ryosuke Niwa wrote:
On Wed, Oct 12, 2011 at 8:14 PM, Sean Hogan shogu...@westnet.com.au
mailto:shogu...@westnet.com.au wrote:
Maybe you can provide concrete examples (i.e. with code snippets,
actual instances of use
Hi all,
I think we should strongly encourage web devs to move away from
sync XHR (in Window context, not in Workers). It is bad for UI
responsiveness.
Unfortunately sync XHR has been used quite often with the old
text/xml types. But maybe we could disable sync XHR for the new
types, and also
On 11/15/2011 09:33 PM, Jonas Sicking wrote:
On Tue, Nov 15, 2011 at 4:22 AM, Anne van Kesterenann...@opera.com wrote:
On Mon, 14 Nov 2011 17:55:25 +0100, Jonas Sickingjo...@sicking.cc wrote:
Yes, I think cross-origin should not work with sync. That is currently the
only synchronous
On 12/12/2011 03:12 PM, Jarred Nicholls wrote:
On Mon, Dec 12, 2011 at 5:37 AM, Anne van Kesteren ann...@opera.com
mailto:ann...@opera.com wrote:
On Sun, 11 Dec 2011 15:44:58 +0100, Jarred Nicholls
jar...@sencha.com mailto:jar...@sencha.com wrote:
I understand that's how you
On 11/29/2011 07:58 AM, Ryosuke Niwa wrote:
Hi all,
I've been looking into the command element
http://dev.w3.org/html5/spec/Overview.html#the-command-element and how
a toolbar might be built
http://dev.w3.org/html5/spec/Overview.html#building-menus-and-toolbars by
them in the last several
Hi all,
few comments about the API
(1)
currently
http://dvcs.w3.org/hg/webevents/raw-file/default/mouse-lock.html uses
VoidCallback which isn't defined anywhere.
I guess there should be something like
void lock (in Element target,
optional in LockSuccessCallback successCallback,
On 12/15/2011 11:27 PM, Vincent Scheib wrote:
On Thu, Dec 15, 2011 at 6:16 AM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
Hi all,
few comments about the API
(1)
currently
http://dvcs.w3.org/hg/__webevents/raw-file/default/__mouse-lock.html
On 12/16/2011 01:04 AM, Darin Fisher wrote:
On Thu, Dec 15, 2011 at 1:39 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 12/15/2011 11:27 PM, Vincent Scheib wrote:
On Thu, Dec 15, 2011 at 6:16 AM, Olli Pettay
olli.pet...@helsinki.fi
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=711276
and https://bugs.webkit.org/show_bug.cgi?id=74660
On 12/16/2011 01:49 AM, Olli Pettay wrote:
On 12/16/2011 01:04 AM, Darin Fisher wrote:
On Thu, Dec 15, 2011 at 1:39 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet
On 12/17/2011 04:30 PM, Anne van Kesteren wrote:
On Thu, 24 Nov 2011 14:08:55 +0100, Arthur Barstow
art.bars...@nokia.com wrote:
All - What are the opinions on what, if anything, to do with XBL2
vis-a-vis the charter update? Leave it on the REC track, stop work and
publish it as a WG Note,
On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren ann...@opera.com
mailto:ann...@opera.com wrote:
On Wed, 21 Dec 2011 16:25:33 +0100, Jarred Nicholls
jar...@webkit.org mailto:jar...@webkit.org wrote:
1. The spec says the timeout
On 12/21/2011 08:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 1:34 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 12/21/2011 05:59 PM, Jarred Nicholls wrote:
On Wed, Dec 21, 2011 at 10:47 AM, Anne van Kesteren
ann...@opera.com
On 01/09/2012 04:59 PM, Arthur Barstow wrote:
Hi All,
As I indicated in [1], WebApps already has a relatively large number of
specs in progress and the group has agreed to add some new specs. As
such, to review any new charter addition proposals, I think we need at
least the following:
1.
quite
small, and then add new features if/when needed.
-Olli
Thanks
-Original Message-
From: Olli Pettay [mailto:olli.pet...@helsinki.fi]
Sent: Monday, January 09, 2012 8:13 AM
To: Arthur Barstow
Cc: ext Satish S; Peter Beverloo; Glen Shires; public-webapps@w3.org;
public-xg
So, if I haven't made it clear before,
doing the initial standardization work in CG sounds ok to me.
I do expect that there will be a WG eventually, but perhaps
CG is a faster and more lightweight way to start - well continue from
what XG did.
-Olli
On 01/31/2012 06:01 PM, Glen Shires wrote:
On 02/24/2012 01:38 AM, Ryosuke Niwa wrote:
Can we disallow mutation events inside shadow DOM?
Sounds good to me.
Whatever shadow dom spec will be implemented, mutation events shouldn't
fire there. Mutation observers should work.
-Olli
There is no legacy content that depends on mutation
On 02/24/2012 02:10 AM, Brian Kardell wrote:
Just to be clear on this: what is the status of mutation observers?
They are in DOM 4. The API may still change a bit, but
there is already one implementation, and another one close to
ready.
If
there any chance shadow dom beats mutation
On 03/20/2012 06:09 PM, Gordon Williams wrote:
Hi,
I recently posted on
https://bugs.webkit.org/show_bug.cgi?id=72154
https://bugzilla.mozilla.org/show_bug.cgi?id=716765
about the change to XHR which now appears to be working its way into
Mainstream users' browsers.
As requested, I'll pursue
I think we should try to get rid of sync XHR in window context.
It takes time, and can be painful, but sync APIs in window
context are just not acceptable.
-Olli
On 03/20/2012 08:03 PM, Gordon Williams wrote:
Thanks for the suggestions...
Just so I'm certain: The #3 option is to run in a
On 04/24/2012 09:43 PM, Travis Leithead wrote:
Based on my reading of DOM4, initEvent makes it possible to transform
a trusted event into a non-trusted event and dispatch it. Is that
intentional?
AFAIK, yes
It is only currently supported in Firefox and Opera. In
IE, Chrome and Safari, the
On 04/25/2012 12:16 AM, Anne van Kesteren wrote:
On Tue, 24 Apr 2012 23:02:22 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
(DOM3's language
about default actions confuses this; I suggest reading DOM4's event
section to get a good picture of how this actually works.)
Or rather how the DOM4
I don't understand this.
The explainer doesn't look like something which should become a
recommendation.
It just, well, explains how the various proposed APIs work.
So, why do we need explainer as FPWD?
-Olli
On 05/02/2012 11:22 PM, Arthur Barstow wrote:
As discussed during WebApps' May 1
On 05/03/2012 12:48 AM, Rick Waldron wrote:
Instead of traditional DOM events being used for Other Events[1], and
considering the high frequency of Gamepad state changes, it might make
sense to provide an API similar to MutationObserver, where a
MutationRecord is created that has snapshots of
On 06/05/2012 09:31 AM, Jer Noble wrote:
On Jun 4, 2012, at 11:23 PM, Robert O'Callahan rob...@ocallahan.org wrote:
If you implemented that proposal as-is then authors would usually need a
listener on the document as well as the element, and as Chris pointed
out, it's simpler to just always
On 06/17/2012 03:03 PM, Jonas Sicking wrote:
On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com wrote:
I too thought we had intentionally spec'd them to not fire during load.
The HTML spec is clear about this WRT Mutation Events:
On 06/17/2012 10:17 PM, Ryosuke Niwa wrote:
On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking jo...@sicking.cc
mailto:jo...@sicking.cc wrote:
On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com
mailto:rafa...@google.com wrote:
I too thought we had intentionally spec'd
On 06/19/2012 11:37 PM, Adam Klein wrote:
On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa rn...@webkit.org
mailto:rn...@webkit.org wrote:
On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking jo...@sicking.cc
mailto:jo...@sicking.cc wrote:
On Sat, Jun 16, 2012 at 7:04 AM, Rafael
On 06/20/2012 10:36 AM, Ryosuke Niwa wrote:
On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
Ojan points out
that simply using end-of-task could expose low-level implementation
detail of the parser to script (such as how
On 06/20/2012 11:58 AM, Anne van Kesteren wrote:
Hi,
The Web Notifications WG is planning to move Web Notifications to W3C
Last Call meaning we don't intend to change it. But we might have
missed something and would therefore appreciate your review of
On 06/20/2012 10:36 AM, Ryosuke Niwa wrote:
On Tue, Jun 19, 2012 at 1:52 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
Ojan points out
that simply using end-of-task could expose low-level implementation
detail of the parser to script (such as how
On 06/26/2012 11:58 PM, Adam Klein wrote:
On Wed, Jun 20, 2012 at 12:29 AM, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:
On Tue, Jun 19, 2012 at 10:52 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
end-of-microtask or end-of-task
On 07/05/2012 01:38 AM, Ryosuke Niwa wrote:
Hi all,
Sukolsak has been implementing the Undo Manager API in WebKit but the fact
undoManager.transact() takes a pure JS object with callback functions is
making it very challenging. The problem is that this object needs to be kept
alive by either
On 07/05/2012 03:11 AM, Ryosuke Niwa wrote:
On Wed, Jul 4, 2012 at 5:00 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 07/05/2012 01:38 AM, Ryosuke Niwa wrote:
Hi all,
Sukolsak has been implementing the Undo Manager API in WebKit
On 07/05/2012 03:25 AM, Olli Pettay wrote:
On 07/05/2012 03:11 AM, Ryosuke Niwa wrote:
On Wed, Jul 4, 2012 at 5:00 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 07/05/2012 01:38 AM, Ryosuke Niwa wrote:
Hi all,
Sukolsak has been
On 07/05/2012 08:00 AM, Adam Barth wrote:
On Wed, Jul 4, 2012 at 5:25 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/05/2012 03:11 AM, Ryosuke Niwa wrote:
On Wed, Jul 4, 2012 at 5:00 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 07/05/2012 01:38
But anyhow, event based API is ok to me.
In general I prefer events/event listeners over other callbacks.
On 07/05/2012 11:37 AM, Olli Pettay wrote:
On 07/05/2012 08:00 AM, Adam Barth wrote:
On Wed, Jul 4, 2012 at 5:25 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/05/2012 03:11 AM
On 07/05/2012 05:15 PM, Adam Barth wrote:
On Thu, Jul 5, 2012 at 1:37 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/05/2012 08:00 AM, Adam Barth wrote:
On Wed, Jul 4, 2012 at 5:25 PM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 07/05/2012 03:11 AM, Ryosuke Niwa wrote:
So, it is very
On 07/05/2012 08:01 PM, Ojan Vafai wrote:
On Thu, Jul 5, 2012 at 7:15 AM, Adam Barth w...@adambarth.com
mailto:w...@adambarth.com wrote:
On Thu, Jul 5, 2012 at 1:37 AM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 07/05/2012 08:00 AM, Adam Barth wrote
Btw, is there something unique with UndoManager which causes implementation
problems in WebKit?
There are plenty of other APIs not using eventlisteners which take JS
callbacks: setTimeout, requestAnimationFrame,
Google's File System API, PeerConnection ... Why aren't those causing problems?
We
On 07/05/2012 10:05 PM, Ryosuke Niwa wrote:
Also, I think consistency matters a lot here. I'm not aware of any other
Web-facing API that takes a pure object with callback functions.
Except of course event listeners. Well, addEventListener can take an object
with _a_ callback function.
I
On 07/12/2012 12:07 PM, Yuval Sadan wrote:
I think we need to realize that a lot of the APIs that have been
designed in the past aren't terribly good APIs.
The IndexedDB API is rather new, and the manner in which it consistently uses
event handlers on returned objects is rather
On 08/04/2012 12:16 PM, Florian Bösch wrote:
On Sat, Aug 4, 2012 at 11:07 AM, b...@pettay.fi mailto:b...@pettay.fi b...@pettay.fi
mailto:b...@pettay.fi wrote:
The update rate depends on the device. Tablet updates reach way beyond
120HZ and even my 3D mouse clocks in at about 500
On 08/07/2012 03:29 AM, Glenn Maynard wrote:
On Sat, Aug 4, 2012 at 4:24 AM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
5ms is quite low when the aim is 60Hz updates... but with
incremental/generational GCs 5ms sounds very much possible.
5ms
On 08/22/2012 10:44 PM, Maciej Stachowiak wrote:
On Aug 22, 2012, at 6:53 PM, Ojan Vafai o...@chromium.org
mailto:o...@chromium.org wrote:
On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa rn...@webkit.org
mailto:rn...@webkit.org wrote:
On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard
On 08/22/2012 11:16 PM, Maciej Stachowiak wrote:
On Aug 22, 2012, at 11:08 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 08/22/2012 10:44 PM, Maciej Stachowiak wrote:
On Aug 22, 2012, at 6:53 PM, Ojan Vafai o...@chromium.org
mailto:o...@chromium.org wrote:
On Wed, Aug 22, 2012 at 6
(And this time to the mailing list too. Sorry for spamming)
On 08/22/2012 11:16 PM, Maciej Stachowiak wrote:
On Aug 22, 2012, at 11:08 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 08/22/2012 10:44 PM, Maciej Stachowiak wrote:
On Aug 22, 2012, at 6:53 PM, Ojan Vafai o...@chromium.org
On 08/22/2012 11:28 PM, Ryosuke Niwa wrote:
On Wed, Aug 22, 2012 at 11:16 PM, Maciej Stachowiak m...@apple.com
mailto:m...@apple.com wrote:
On Aug 22, 2012, at 11:08 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 08/22/2012 10:44 PM, Maciej
On 09/01/2012 11:19 PM, Rick Waldron wrote:
David,
Thanks for preparing this summary—I just wanted to note that I still stand
behind my original, reality based arguments.
One comment inline..
On Saturday, September 1, 2012 at 12:49 PM, David Bruant wrote:
Hi,
A Sync API for workers is
On 09/01/2012 11:38 PM, Rick Waldron wrote:
So far, they all look async. Just calling them sync doesn't make them sync.
Sure they are sync. They are sync inside worker. We all know that we must not
introduce
new sync APIs in the main thread.
On 09/06/2012 09:12 AM, Jonas Sicking wrote:
On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi b...@pettay.fi wrote:
On 09/06/2012 08:31 AM, Jonas Sicking wrote:
On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Sep 5, 2012 at 2:49 AM, Jonas Sicking jo...@sicking.cc
On 09/06/2012 09:30 AM, Olli Pettay wrote:
On 09/06/2012 09:12 AM, Jonas Sicking wrote:
On Wed, Sep 5, 2012 at 11:02 PM, b...@pettay.fi b...@pettay.fi wrote:
On 09/06/2012 08:31 AM, Jonas Sicking wrote:
On Wed, Sep 5, 2012 at 8:07 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Sep 5, 2012
On 09/09/2012 06:33 PM, Mike Wilson wrote:
Is it defined how the browser should behave wrt calling
unrelated event handlers in user code during synchronous
XHR requests? (with unrelated I refer to events that are
not related to the ongoing synchronous request itself)
I didn't find statements
On 10/02/2012 11:55 PM, Florian Bösch wrote:
I'd like to point out that vendors are using additional failure criteria to
determine if pointerlock succeeds that are not outlined in the
specification. Firefox uses the fullscreen change event to determine failure
and chrome requires the pointer
On 10/03/2012 12:59 AM, Florian Bösch wrote:
On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay olli.pet...@helsinki.fi
mailto:olli.pet...@helsinki.fi wrote:
On 10/02/2012 11:55 PM, Florian Bösch wrote:
I'd like to point out that vendors are using additional failure
criteria
On 10/19/2012 01:19 AM, Alan Stearns wrote:
On 10/18/12 2:51 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 10/19/2012 12:08 AM, Rafael Weinstein wrote:
CSS Regions regionLayoutUpdate brings up an issue I think we need to
get ahead of:
https://www.w3.org/Bugs/Public/show_bug.cgi?id
On 11/02/2012 12:56 AM, Glenn Maynard wrote:
On Thu, Nov 1, 2012 at 5:14 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com
mailto:hallv...@opera.com wrote:
The most IMHO elegant solution is what we implemented in Opera: we simply
keep relevant menu entries enabled if there are event
On 12/14/2012 09:46 PM, Boris Zbarsky wrote:
On 12/14/12 2:29 PM, Anne van Kesteren wrote:
Per Hixie the Document is associated with both the old and the new
Window. Meaning that XMLHttpRequest will function normally even though
XMLHttpRequest != window.XMLHttpRequest.
I'm not sure it
On 02/19/2013 10:24 PM, Rafael Weinstein wrote:
On Mon, Feb 18, 2013 at 12:06 PM, Jonas Sicking jo...@sicking.cc
mailto:jo...@sicking.cc wrote:
On Mon, Feb 18, 2013 at 1:48 AM, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:
On Sat, Feb 16, 2013 at 5:23 PM, Dimitri
+1
On 04/27/2013 05:30 PM, Arthur Barstow wrote:
As discussed during WebApps' April 25 meeting, this is a Call for Consensus to
publish a First Public Working Draft of the UI Events spec using the
following ED as the basis:
https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm
This
On 12/04/2013 06:27 PM, Feras Moussa wrote:
The editors of the Streams API have reached a milestone where we feel many of
the major issues that have been identified thus far are now resolved and
incorporated in the editors draft.
The editors draft [1] has been heavily updated and reviewed the
Hi all,
I wonder what people think of if we started to rather aggressively deprecate
the horrible API
main-thread sync XHR?
Currently its usage is still way too high (up to 2% based on telemetry data),
but
if all the browsers warned about use of deprecated feature, we might be able to
get
On 02/07/2014 07:32 PM, Scott González wrote:
What about developers who are sending requests as the page is unloading? My
understanding is that sync requests are required. Is this not the case?
We need sendBeacon asap, and browsers could start warn first when sync XHR is
used outside unload
101 - 200 of 239 matches
Mail list logo
