On Sun, Jul 12, 2015 at 11:52 PM, Elliott Sprehn espr...@chromium.org wrote:
This is what I had in mind as well. Also it occurs to me there's a missing
primitive here for how the browser knows that all listeners have mayCancel:
false so it can make this optimization. EventTarget needs some kind
On Mon, Jul 13, 2015 at 8:09 AM, Elliott Sprehn espr...@chromium.org wrote:
Without such a function there's no primitive to explain how the scrolling
and touch systems utilize this mayCancel bit unless we're saying the browser
stores hidden state for event listeners in some WeakMap and all the
, 2015 12:47
To: Rick Byers
Cc: wha...@whatwg.org
Subject: Re: [whatwg] DOM Events Proposal: EventListenerOptions
'mayCancel' for improved scroll performance
Is it not possible for Javascript engines to statically determine if
preventDefault() is called by an event handler?
For example
On Sat, Jul 11, 2015 at 11:41 PM, Rick Byers rby...@chromium.org wrote:
What Anne describes is perfect! I'm not hung up on the value of cancelable
itself - some internal bit on Event that makes preventDefault a no-op (or
event throw) during listener invocation is fine with me (and I agree -
On Sat, Jul 11, 2015 at 11:40 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Sat, Jul 11, 2015 at 11:41 PM, Rick Byers rby...@chromium.org wrote:
What Anne describes is perfect! I'm not hung up on the value of
cancelable
itself - some internal bit on Event that makes preventDefault a
On 7/12/15 12:47 PM, Ashley Gullen wrote:
1. Yes: statically references e.preventDefault
2. Maybe: some dynamic reference like e[str]
3: No: no dynamic references, and no static references to e.preventDefault
Assuming the maybe case is rare
Is there data supporting this assumption? I would
Is it not possible for Javascript engines to statically determine if
preventDefault() is called by an event handler?
For example:
function myHandler(e)
{
// does e.preventDefault occur anywhere in this body?
};
target.addEventListener(scroll, myHandler);
If none of the added event handlers
, July 12, 2015 12:47
To: Rick Byers
Cc: wha...@whatwg.org
Subject: Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for
improved scroll performance
Is it not possible for Javascript engines to statically determine if
preventDefault() is called by an event handler?
For example
On Sat, Jul 11, 2015 at 8:19 PM, Domenic Denicola d...@domenic.me wrote:
I'm not sure that actually matters though, since canceling inside
setTimeout(,0) shouldn't have much affect besides changing
`e.defaultPrevented`. So maybe it's OK.
It's fine. The code that dispatches an event and then
On Fri, Jul 10, 2015 at 9:12 PM, Rick Byers rby...@chromium.org wrote:
1) Should we extend the existing addEventListener API or change the API
names (and perhaps other things) completely.
https://github.com/RByers/EventListenerOptions/issues/18
It seems most other DOM peers are okay with
From: Anne van Kesteren [mailto:ann...@annevk.nl]
2) Should mayCancel=false listeners always get an Event with
cancelable=false, or is this just a hint such that all listeners
still get the same event with the same properties.
https://github.com/RByers/EventListenerOptions/issues/2
I was
[On vacation now with only a phone - so apologies for the brevity and
top-posting]
What Anne describes is perfect! I'm not hung up on the value of cancelable
itself - some internal bit on Event that makes preventDefault a no-op (or
event throw) during listener invocation is fine with me (and I
Let me try to summarize the primary debate around this API so far. There
are (at least) two major questions which I think block creating a proper
pull request for suggesting concrete changes to the spec:
1) Should we extend the existing addEventListener API or change the API
names (and perhaps
On Thu, Jul 9, 2015 at 3:44 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 9:05 AM, James Ross w3c-20040...@james-ross.co.uk
wrote:
Date: Thu, 9 Jul 2015 14:42:07 +0200
From: phil...@opera.com
I
On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote:
I think there's a big opportunity to substantially improve scroll
performance on the web in the relatively short term by doing something
incremental. I.e. I'm pretty sure I can get major scroll-blocking libraries
like
On Thu, Jul 9, 2015 at 9:49 AM, Philip Jägenstedt phil...@opera.com wrote:
On Thu, Jul 9, 2015 at 3:44 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 9:05 AM, James Ross
On Thu, Jul 9, 2015 at 3:58 PM, Rick Byers rby...@chromium.org wrote:
I'd love to hear other ideas!
Well, we have had some discussions in the past about introducing a
better event API:
https://gist.github.com/annevk/5238964
Maybe the time has come...
(I agree with Philip that if we add this
On Thu, Jul 9, 2015 at 11:22 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote:
I think there's a big opportunity to substantially improve scroll
performance on the web in the relatively short term by doing something
On Thu, Jul 9, 2015 at 11:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Jul 9, 2015 at 3:58 PM, Rick Byers rby...@chromium.org wrote:
I'd love to hear other ideas!
Well, we have had some discussions in the past about introducing a
better event API:
On 07/09/2015 06:22 PM, Anne van Kesteren wrote:
On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote:
I think there's a big opportunity to substantially improve scroll
performance on the web in the relatively short term by doing something
incremental. I.e. I'm pretty sure I
On Thu, Jul 9, 2015 at 6:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/9/15 8:42 AM, Philip Jägenstedt wrote:
Would there be any way to feature detect support for EventListenerOptions
as the third
argument?
Yes. You call addEventListener and pass an object that has getters for the
On Thu, Jul 9, 2015 at 11:40 AM, Philip Jägenstedt phil...@opera.com
wrote:
On Thu, Jul 9, 2015 at 5:30 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 11:22 AM, Anne van Kesteren ann...@annevk.nl
wrote:
On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org
On 7/9/15 8:42 AM, Philip Jägenstedt wrote:
Would there be any way to feature detect support for EventListenerOptions as
the third
argument?
Yes. You call addEventListener and pass an object that has getters for
the properties you care about detecting. If those getters get invoked,
the
On Thu, Jul 9, 2015 at 12:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/9/15 8:42 AM, Philip Jägenstedt wrote:
Would there be any way to feature detect support for EventListenerOptions
as the third
argument?
Yes. You call addEventListener and pass an object that has getters for
the
On Thu, Jul 9, 2015 at 5:30 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 11:22 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers rby...@chromium.org wrote:
I think there's a big opportunity to substantially improve scroll
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Rick Byers
That seems like a nice incremental compromise. Using a new name for
addEventListener will help address some of the feature detection /
compatiblity concerns too. Filed
On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking jo...@sicking.cc wrote:
Speaking
of that, having a new function makes it an option to let mayCancel be
false by default, compat-wise at least.
That's a good question regardless of which approach we take. Filed
On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/9/15 1:32 PM, Rick Byers wrote:
Done. How does example 2 look now?
On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/9/15 1:32 PM, Rick Byers wrote:
Done. How does example 2 look now?
On Thu, Jul 9, 2015 at 12:47 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 12:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/9/15 8:42 AM, Philip Jägenstedt wrote:
Would there be any way to feature detect support for
EventListenerOptions as the third
argument?
Yes.
On 7/9/15 1:32 PM, Rick Byers wrote:
Done. How does example 2 look now?
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2
Looks like it would work. Also looks kind of ugly because of the
object-truthiness bit, but I'm not sure there's any way to avoid that
Speaking
of that, having a new function makes it an option to let mayCancel be
false by default, compat-wise at least.
That's a good question regardless of which approach we take. Filed
https://github.com/RByers/EventListenerOptions/issues/17
I definitely think that if we're going to have
On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/9/15 1:32 PM, Rick Byers wrote:
Done. How does example 2 look now?
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2
Looks like it would work. Also looks kind of ugly because of the
On Thu, Jul 9, 2015 at 11:52 AM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking jo...@sicking.cc wrote:
...
I agree 100% with this principle. Changed mayCancel to default to false:
On Thu, Jul 9, 2015 at 2:59 PM, Elliott Sprehn espr...@chromium.org wrote:
On Thu, Jul 9, 2015 at 11:52 AM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking jo...@sicking.cc wrote:
...
I agree 100% with this principle. Changed mayCancel to default to
On Wed, Jul 8, 2015 at 9:12 PM, Rick Byers rby...@chromium.org wrote:
[Cross-posted to www-...@w3.org - please let me know if there's a better
way to account for the DOM spec duality]
In Chromium we've long worked hard at maximizing scroll performance, with
scroll-blocking DOM events (wheel
On Thu, Jul 9, 2015 at 9:05 AM, James Ross w3c-20040...@james-ross.co.uk
wrote:
Date: Thu, 9 Jul 2015 14:42:07 +0200
From: phil...@opera.com
I think this looks like a very promising approach. Would there be any
way to feature detect support for EventListenerOptions as the third
On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 9:05 AM, James Ross w3c-20040...@james-ross.co.uk
wrote:
Date: Thu, 9 Jul 2015 14:42:07 +0200
From: phil...@opera.com
I think this looks like a very promising approach. Would there be any
On Thu, Jul 9, 2015 at 6:03 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 9, 2015 at 12:06 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On
On Thu, Jul 9, 2015 at 12:06 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers rby...@chromium.org wrote:
On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On
On Wed, Jul 8, 2015 at 4:04 PM, Olli Pettay o...@pettay.fi wrote:
On 07/08/2015 10:12 PM, Rick Byers wrote:
[Cross-posted to www-...@w3.org - please let me know if there's a better
way to account for the DOM spec duality]
In Chromium we've long worked hard at maximizing scroll performance,
On Wed, Jul 8, 2015 at 12:12 PM, Rick Byers rby...@chromium.org wrote:
[Cross-posted to www-...@w3.org - please let me know if there's a better
way to account for the DOM spec duality]
In Chromium we've long worked hard at maximizing scroll performance, with
scroll-blocking DOM events (wheel
On 07/08/2015 10:12 PM, Rick Byers wrote:
[Cross-posted to www-...@w3.org - please let me know if there's a better
way to account for the DOM spec duality]
In Chromium we've long worked hard at maximizing scroll performance, with
scroll-blocking DOM events (wheel and touchstart in particular)
[Cross-posted to www-...@w3.org - please let me know if there's a better
way to account for the DOM spec duality]
In Chromium we've long worked hard at maximizing scroll performance, with
scroll-blocking DOM events (wheel and touchstart in particular) being by
far the biggest source of scroll
44 matches
Mail list logo
