search

WICG / input-device-capabilities

InputDevice API proposal
MIT License
17 stars 14 forks source link

What to do about scroll events? #5

Closed RByers closed 9 years ago

RByers commented 9 years ago

Scroll events don't technically represent a single input (eg. multiple devices may scroll the same element at the same time - what sourceDevice would we want then?). Should we spec a particular behavior? Should we have any tests?

tdresser commented 9 years ago

I'm trying to come up with a scenario where using the InputDevice from the most recent cause of scrolling wouldn't work. I haven't come up with anything.

If we can go with an approach with that level of complexity, I think specifying the behavior would be worthwhile.

RByers commented 9 years ago

It might be a bit of a pain for us to implement correctly in chromium. We might need to extend all the scrolling machinery with some source tracking, eg. to reliably know when a wheel event actually changed an offset (as opposed to just attempted to scroll but couldn't). This would involve some plumbing from CC to blink (since there are cases today when CC scrolls and blink has no idea why) and some conflict resolution when blink and cc have registered scrolls for different reasons.

I'm OK saying this is the desired behavior though, but not necessarily blocking shipping sourceDevice in chromium on fixing it.

RByers commented 9 years ago

Ah ha, the UI Events spec is changing to align with CSSOM View definition where scroll is just an 'Event': https://code.google.com/p/chromium/issues/detail?id=503280. So this is not an issue ATM. We might want to expose a sourceDevice on scroll in the future but the value seems low compared to the cost (maybe best addressed by scroll customization anyway).