Replace mayCancel with blocksScroll?

[RByers]

My original proposal on public-pointerevents suggested a blocksScroll option instead of this mayCancel option. Maybe that would be better after all?

Benefits:

• Avoids @ojanvafai's concern (#13) about scenarios where a touch handler won't call preventDefault but would still want to block scrolling.
• Directly describes it's primary purpose and performance consequence
• Could someday be directly extended to allow a scroll event handler to opt-in to being running in-sync with scrolling (as for scroll-blocks-on)

Disadvantages:

• Not broadly useful enough to justify changing the core event handler model.
  • How compelling are the other uses cases for mayCancel?
• Attempting to spec threaded scrolling behavior explicitly may be opening a Pandora's box of spec hassle. Threaded scrolling is otherwise an implementation detail not directly exposed to the platform.

Previously Olli Pettay argued:

Definitely not this. This is not a strong enough case to change an API which has existed for 15+ years, IMO.

And then

So, "I'm not going to call preventDefault()" might be such, useful also in other cases than just with wheel. A bit odd API, but might be useful, really useful.

Anyone else have opinions here?

[ojanvafai]

I actually tend to agree with Olli's desire for a more general name. My intuition is that we will find other non-scroll-related uses for this in the future. How about "blocksDefaultAction"? That clearly associates with preventDefault, would also be usable in the future for the scroll event handler case you mention and would hopefully avoid the potential confusion I mention in #13.

[RByers]

I'm trying to separate a bit the debate over the right name / spec wording (#13) from the fundamental semantics (this bug). It sounds like 'blocksDefaultAction' would have more of the semantics I'm proposing here for blocksScroll, right? Eg. what would the behavior be for events like 'scroll' and 'mousemove' which have no default action - do we need some mechanism to indicate failure? What would the default value be when unspecified (do we need to reintroduce a third "auto" value)?

Also I'm not sure "blocksDefaultAction" would really make sense for "scroll". I don't think we could add a default action to "scroll" - what would it mean for the page to call preventDefault on it (we can't, for example, undo the scroll)? But maybe we could fudge it to be close enough?

[smaug----]

indicate failure? What failure? There isn't anything to cancel on "scroll". "scroll" event happens after actually scrolling.

[RByers]

Right, my point exactly. So you're suggesting that blocksDefaultAction=true for scroll or mousemove events would be silently ignored since there is no default action, right? Ojan was suggesting that we might want to use blocksDefaultsAction=true on scroll events in the future to enable JS synchronized scrolling (one of my original goals with scroll-blocks-on but not something I'm actively pursuing at the moment).

[RByers]

@esprehn says:

I don't like making this specific to scrolling, that doesn't explain what it really means in terms of the capabilities of the event handler. We probably want to use this for other event types where we want to change the time the event dispatches based on if you require the ability to cancel or not as well.

[RByers]

Consensus seems to be to stick with the general semantics of mayCancel (but we can still debate the exact name in #13).