Consider defaulting to use passive listener on window/document/document.body

[smaug----]

This would need some hooks into DOM spec.
Perhaps https://dom.spec.whatwg.org/#dom-eventtarget-addeventlistener step 4 could for example get the default tuple {eventType, isPassive} from the context object and use that in case passive wasn't passed in the options.

@RByers

[smaug----]

This would of course break event delegation pretty badly.

[RByers]

Thanks for filing this. Chrome is experimenting with this as an "intervention" as discussed here, and it's looking like it's probably not that breaking in practice. Once we have hard data on the web compat impact (i.e. by shipping one of our ideas by default in Chrome) we'll circle back here to discuss possible spec changes.

[RByers]

We should also consider whether we can plan long-term to make ALL touch listeners passive by default. It's really weird / ugly to treat listeners on "root" elements specially, though it does seem like the right pragmatic compat/perf tradeoff at the moment.

[patrickhlauke]

Wondering if changing the definition here in the spec would have any real-world effect, considering:

• it would be most relevant for authors who write touch handling after the change has happened and has found its way in browsers
• the hope (wish?) would be for authors in future to migrate to pointer events as the more holistic/sensible event model
• the one browser that is currently refusing to even consider pointer events is also the one that (to my knowledge?) is not signaling any intent to follow anything we may come up with/decide in this spec
• there's the potential of unforeseen breakage

I'll be honest, I personally think we should leave this as is and focus perhaps on more developer outreach ("adding touch handlers can have perf issues, m'kay?" as one compelling argument to switch to pointer events, and offer the idea of explicitly setting them to passive as a stopgap solution - for browsers that do support passive event listeners)

[RByers]

Note that WebKit is now planning on making this change. If this lands in WebKit then I'd argue we should work to update the spec to reflect the implementation reality (IMHO preferring people use a different API isn't a good reason to allow living standards and implementations to diverge - there's a LOT of html we'd rather people not use anymore too ).

@dtapuska has initial PRs for this at #75 and whatwg/dom#365. They need some work still, but they're a start.

[patrickhlauke]

agree making the spec match reality is a good thing (tm). i'll have a look over #75 but any help appreciated (as i slowly emerge from a few months of rubbish that left me with practically no time to look at these things)

[RByers]

Thanks. But totally - if we agree we're interested in landing something like this, then the ball is in @dtapuska's court to polish the changes, respond to the feedback raised so far, etc.

[domenic]

A quick status update on this work has been posted at whatwg/dom#365 (comment) . Work in the touch events repo (if there is any) is still blocked on work in the DOM repo; no need for the touch events editors to do anything yet.