RByers
commented
9 years ago Interesting scenario, thanks. I agree there's an opportunity for confusion here.
However I'm worried that the confusion around async/sync events means that using that term here would only further confuse the situation. In particular, my understanding of the definition of "async DOM events" is that it reflects only the ordering of what's observable to JavaScript (events, DOM changes, etc.). So touch and wheel events dispatched to mayCancel=false handlers would still be "synchronous" (the ordering of everything on the main thread remains the same). In particular, I believe it's important that hit-testing be unaffected by this #6.
Filed #14 for a specific alternative I previously rejected.
Or maybe we can do something to help avoid confusion by just adding a note? Eg.
Such an optimization would mean that the user may see the result of scrolling before the application's JavaScript has had a chance to run. In rare situations a handler may wish to modify the page before scrolling starts and so use mayCancel=true to block scrolling even though it will not actually call preventDefault.
annevk
mayCancel makes total sense with respect to preventDefault, but it also affects whether the event is async with respect to the default action, right?
Here's an example where this name is confusing: a popup that you want to go away before the scroll starts. You still want the scroll to happen, but you don't want the popup to scroll with the content, you want it to just go away on touchstart. I can imagine as a developer being in this situation and trying to figure out if there's a way to get the event to be synchronous. "mayCancel" would not seem likely as a way to fix this.
How about "requiresSync"? or "mayBeAsync"? I don't love those names, but they're a bit more accurate and they're the best I can come up with at the moment. :)