Thanks,Rick
Nico, I understand you'd rather see a new web API here rather than changing chromium to match firefox and IE's behavior. I'd love to see that too, but I believe it would be a huge amount of work for relatively little gain - I don't think anyone is volunteering to drive that (unless you are?). Perhaps UIManipulationRequestEvent will gain consensus and we can move to that at some point in the future, but it's likely to be a long time out still.In the interim, is there really a good enough reason not to match IE and Firefox here?Let's back up for a minute. When there is a physical USB mouse, chromium directly handles Ctrl+Wheel to trigger browser zoom without giving websites a chance to override that behavior (no mousewheel event is sent). Sending a ctrl+mousewheel event in this case (with preventDefault disabling the browser zoom behavior) seems completely reasonable (and consistent with mousewheel scroll behavior), right? Of course it means that pages that eat mousewheel events will stop zooming on pinch, but this is consistent with our "content not chrome" principle - when the user is manipulating the web contents, the contents should have primary say (just like a page can override the handling of the zoom keyboard shortcuts - there's always the chrome UI to fall back upon).The only remaining question is to what extent gestures on a trackpad emulate a mouse. If we're already sending 'mousewheel' events for two finger panning on the trackpad (which is already a "lie" with a strict interpretation of the mousewheel API), is sending ctrl+mousewheel for two-finger pinching sufficiently worse that we should leave the maps problem unsolved (such that maps users on IE and Firefox have a better experience than those on Chrome)? To me it's just part of mapping trackpad gestures to their most natural equivalent in the APIs we have for other hardware. Web developers already have to be prepared for (and perhaps even expect) this interpretation from the other 2 major browsers on Windows.Adam, any input? Perhaps we should go through the blink intent-to-ship process for this (even though it's not technically covered since it's not implemented in blink)? It sounds like it's ultimately API compat risk that we're concerned with here.
On Thu, Jan 16, 2014 at 9:40 AM, Rick Byers <rby...@chromium.org> wrote:
Nico, I understand you'd rather see a new web API here rather than changing chromium to match firefox and IE's behavior. I'd love to see that too, but I believe it would be a huge amount of work for relatively little gain - I don't think anyone is volunteering to drive that (unless you are?). Perhaps UIManipulationRequestEvent will gain consensus and we can move to that at some point in the future, but it's likely to be a long time out still.In the interim, is there really a good enough reason not to match IE and Firefox here?Let's back up for a minute. When there is a physical USB mouse, chromium directly handles Ctrl+Wheel to trigger browser zoom without giving websites a chance to override that behavior (no mousewheel event is sent). Sending a ctrl+mousewheel event in this case (with preventDefault disabling the browser zoom behavior) seems completely reasonable (and consistent with mousewheel scroll behavior), right? Of course it means that pages that eat mousewheel events will stop zooming on pinch, but this is consistent with our "content not chrome" principle - when the user is manipulating the web contents, the contents should have primary say (just like a page can override the handling of the zoom keyboard shortcuts - there's always the chrome UI to fall back upon).The only remaining question is to what extent gestures on a trackpad emulate a mouse. If we're already sending 'mousewheel' events for two finger panning on the trackpad (which is already a "lie" with a strict interpretation of the mousewheel API), is sending ctrl+mousewheel for two-finger pinching sufficiently worse that we should leave the maps problem unsolved (such that maps users on IE and Firefox have a better experience than those on Chrome)? To me it's just part of mapping trackpad gestures to their most natural equivalent in the APIs we have for other hardware. Web developers already have to be prepared for (and perhaps even expect) this interpretation from the other 2 major browsers on Windows.Adam, any input? Perhaps we should go through the blink intent-to-ship process for this (even though it's not technically covered since it's not implemented in blink)? It sounds like it's ultimately API compat risk that we're concerned with here.I'm not sure we need to go through a formal process. Mostly it just sounds like we ought to talk with Nico and make sure we've understood his point of view. From reading this thread and the bug, it seems like there are two issues:1) Chrome doesn't behave the same way as other browsers.2) Chrome doesn't support high-fidelity trackpad gestures.Both problems seems worth solving. My understanding of Nico's concern is that he thinks we should resolve (2) first. Given that we want to take a standards-based approach when introducing new APIs, the lead time on (2) is probably significant, especially given the IPR concerns that gave rise to the separate W3C Pointer Events Working Group. A more pragmatic approach is to make the maps team happy by resolving (1) first. That certainly doesn't preclude resolving (2) in the future.