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

w3c / touch-events

https://w3c.github.io/touch-events/

26 stars 24 forks source link

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

Open smaug---- opened 8 years ago

smaug---- commented 8 years ago

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---- commented 8 years ago

This would of course break event delegation pretty badly.

RByers commented 8 years ago

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 commented 8 years ago

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 commented 7 years ago

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 commented 7 years ago

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 https://github.com/w3c/touch-events/pull/75 and https://github.com/whatwg/dom/issues/365. They need some work still, but they're a start.

patrickhlauke commented 7 years ago

agree making the spec match reality is a good thing (tm). i'll have a look over https://github.com/w3c/touch-events/pull/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 commented 7 years ago

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 commented 2 years ago

A quick status update on this work has been posted at https://github.com/whatwg/dom/issues/365#issuecomment-1098416958 . 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.