Plus most real-world cases are way too complex to be able to statically
determine. Eg. People love their event delegation patterns. Try stepping
through a no-op listener (eg. Click on whitespace) in gmail some time...
On Jul 12, 2015 1:12 PM, Domenic Denicola d...@domenic.me wrote:
Generally
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
On Fri, Jul 10, 2015 at 1:54 PM, Majid Valipour maji...@chromium.org wrote:
On Mon, Jun 29, 2015 at 5:20 PM Jonas Sicking jo...@sicking.cc wrote:
FWIW I still prefer an API like
history.scrollRestoration = 'manual';
The main reason is that it seems to me that pushState/replaceState has
a
Generally nobody wants to write code in their JavaScript engine implementation
that is aware of concepts like the DOM, events, methods specifically named
preventDefault, etc.
-Original Message-
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ashley Gullen
Sent:
On Sun, Jul 12, 2015 at 7:49 PM, Jonas Sicking jo...@sicking.cc wrote:
I think we've already made that assumption given that history.state
already relies on this.
Good point. I'm still somewhat skeptical of introducing new objects
just for the purpose of grouping some properties if they don't
On Sat, Jul 11, 2015 at 10:51 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour maji...@chromium.org wrote:
Minor bikeshed:
I have put scrollRestoration on history.options instead of directly history
itself in order to use history.options as an
