Suggestion: add more event types (xxxpassive or xxx-ed) instead of EventListenerOptions

[duanyao]

Currently there are only a few event types (touchstart, touchmove, and wheel) really benefit from mayCancel option, so maybe it is not worth to introduce the new concept of EventListenerOptions to all events immediately. Instead, we can simply define touchstartpassive, touchmovepassive, and wheelpassive events, which are the non-cancelable variants. These variants are also available via DOM0 properties (i.e. onxxx).

EventListenerOptions may be added to some new API in future, as suggested in #18.

Update:
"xxxpassive" may be too long names, how about "-ed" names, i.e. touchstarted, touchmoved, and wheelrolled? Past tense implies that those events just happend, too late to cancel.

[RByers]

I agree that's an option worth considering (I especially like the names like touchstarted - those hadn't occurred to me). I initially rejected this option for the following reasons:

1. Pushes what is really a more general problem down to the individual specs. So rather than more complexity in the DOM spec, we'd have more complexity in both the Touch Events and UI Events specs.
2. Doubles the event-dispatch cost for high-frequency events like touchmove. We'd have to at least evaluate the perf impact of this. Even an extra 0.1ms on slow phone hardware would probably be a deal breaker for blink (we're very protective of the 16ms frame budget).
3. Less incremental for sites to adopt, changes the behavior (i.e. ordering wrt. other handlers, impacts event delegation code that uses Event.type). In some large apps this could be much more difficult to adopt (especially if you want to try adopting as an experiment without relying on a polyfill). If we're going to have a real impact on the perf of the web, dead-simple incrementalism for web developers is critical.
4. May not be possible to polyfill faithfully. Need to dispatch the passive events right after active event dispatch has finished.
5. Perhaps this is irrational, but I'm concerned about the developer perception of introducing a third event model for touch (after all the touch events vs. pointer events debates). One could legitimately argue that rather than extending touch events, we should just be focusing on pointer events (which is a legitimate argument regardless of course - but this would make it much stronger).
6. If we're still going to want a mayCancel option in the future anyway (eg. @smaug---- said he sees it being useful for other event types), then adding new event types would be platform debt.

That said, mayCancel is certainly turning out to be a little more complicated than I initially appreciated. I think it's still pretty simple for web developers, but will have a larger spec footprint than I hoped. I don't think it's unreasonable to revisit this option.

@annevk, @smaug---- any opinion?

[annevk]

It's no longer clear to me what the processing model for mayCancel is. Same goes for new UI events since the current UI event specifications are a morass of undocumented behavior.

[smaug----]

about 2) Looks like event dispatch in a tree which has depth 100 takes about 0.011ms on
Gecko and 0.015ms on Blink on this fast laptop (64bit linux).
With tree depth=20 times are ~0.003ms
On my FFOS phone it is d=100 0.036ms, d=20 0.012ms.
The phone has fast 2.5GHz quad-core Snapdragon 801.

But anyhow, I don't like adding more event types for this kind of case.
We really should have some generic way to have "passive" listeners, so I'd prefer something like mayCancel - whatever the exact API will look like.

[RByers]

Sounds like there's general consensus that adding more event types is not the best solution. Closing.