[uievents] [Proposal] Add "Zoom" event (#31)

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26611

##### Masayuki Nakano 2014-08-20 07:14:47 UTC
Mozilla have a bug report about a way to prevent content zoom by web apps.
https://bugzilla.mozilla.org/show_bug.cgi?id=1052253

According to the bug report, Chrome fires a wheel event whose ctrlKey is true when user attempts to "pinch to zoom" on Mac. Then, if the wheel event's default is prevented, Chrome cancels the zoom.

On the other hand, Firefox doesn't fire any events at "pinch to zoom" on Mac. Therefore, web apps cannot prevent to zoom. Of course, Firefox can dispatch such wheel event. However, Firefox users can customize a way to zoom with wheel. E.g., they can use Option (Alt) key for it and/or reverse the direction. Therefore, web apps cannot distinguish which wheel event is a "before zoom" event strictly.

I'd like to suggest a simple event "Zoom". When users attempt to use zoom feature of browsers from keyboard shortcut, wheel or menu, it should be fired. And if its default is prevented, browser should cancel it.

I think that UIEvent is enough for the event. Its detail value should be |new zoom level * 100| or just 1 or -1 for indicating zooming in or out.

##### Comment 1 Masayuki Nakano 2014-08-20 07:19:20 UTC
If we do create new interface for zoom event, it should have:

double        level; (110 means 110%)
boolean       fullZoom; (full zoom or text only zoom)
unsigned long device; (0: unknown, 1: key, 2: mouse, 3: gesture)

##### Comment 2 Mounir Lamouri 2014-08-20 08:51:57 UTC
Both Firefox and Chrome expose the zoom level via devicePixelRatio change. Should we have a devicePixelRatio change event or do we want to expose an entirely different feature (zoom level + change events)?

Exposing the zoom level and preventing zoom changes is something that Chrome Apps was looking into so it sounds like we definitely have UC for that.

##### Comment 3 Olli Pettay 2014-08-20 09:19:11 UTC
devicePixelRatio is changed after the user intent has been processed by the
browser.
Zoom (or wheel+ctrl) happens before actual zooming.
So devicePixelRatio isn't really about this bug.

##### Comment 4 Evan Wallace 2014-08-20 16:29:57 UTC
The intent isn't just to be able to prevent the default zoom behavior, but also to be able to implement custom zoom behavior. For example, a zoom event in a map application over the map area wouldn't zoom the entire page but would zoom the map instead.

As an app developer, zoom events are easiest to use for custom zoom behavior when the detail value just provides an incremental delta instead of the absolute zoom level. For example, if a keyboard zoom in/out action is part of this event, then either a multiplicative delta of *2 or *0.5 or an additive delta of +1 or -1 (in log space, so the scale is something like *pow(2, additiveDelta)) would be the most useful.

Providing the absolute zoom level in the event is inconvenient because the application likely has its own representation of zoom that has nothing to do with the browser zoom. For example, the scale of the map in a map application usually changes by 100x during a session. Tying the scale of the map to the absolute zoom level doesn't make sense.

##### Comment 5 Tetsuharu OHZEKI 2014-08-20 17:57:14 UTC
I have some questions about this intent:

As Evan remarks, If this intent is not suitable to prevent the default zoom behavior and we should use viewport's `user-zoom=fixed` to prevent it, but if we introduce this intent to make a custom behavior, will UA fires this "zoom" event?

And I think "zoom" is an abstract behavior indicated by user. Is it really suitable to add this intent to DOM3 Event? I remember IndieUI Events which represents user's high abstract indication. so I feel we should add this to its spec, shouldn't it?
(I don't know IndieUI spec status well. if we cannot wait it, I vote passively that to add this intent to DOM3 Event.)

##### Comment 6 Masayuki Nakano 2014-08-21 01:35:29 UTC
(In reply to Evan Wallace from comment #4)
> As an app developer, zoom events are easiest to use for custom zoom behavior
> when the detail value just provides an incremental delta instead of the
> absolute zoom level. For example, if a keyboard zoom in/out action is part
> of this event, then either a multiplicative delta of *2 or *0.5 or an
> additive delta of +1 or -1 (in log space, so the scale is something like
> *pow(2, additiveDelta)) would be the most useful.


Sounds better to me.

(In reply to Tetsuharu OHZEKI from comment #5)
> As Evan remarks, If this intent is not suitable to prevent the default zoom
> behavior and we should use viewport's `user-zoom=fixed` to prevent it, but
> if we introduce this intent to make a custom behavior, will UA fires this
> "zoom" event?

"zoom" event should be fired immediately before the browser attempts to zoom its content. I *believe* that even if zoom won't occur actually (e.g., already reached to min or max zoom level or user-zoom: fixed, zoom event should be fired because the important feature of this event is that web contents should be able to know when the user tries to zoom in/out the content.

> And I think "zoom" is an abstract behavior indicated by user. Is it really
> suitable to add this intent to DOM3 Event? I remember IndieUI Events which
> represents user's high abstract indication. so I feel we should add this to
> its spec, shouldn't it?
> (I don't know IndieUI spec status well. if we cannot wait it, I vote
> passively that to add this intent to DOM3 Event.)


Oh, I've not known IndieUI Events. Indeed, it includes zoom related events. However, looks like the spec is too unstable...

##### Comment 7 Arthur Barstow 2015-03-21 15:11:52 UTC
Bulk move of all D3E bugs to the UI Events component.

##### Comment 8 Rick Byers 2015-07-07 14:23:35 UTC
I'm in favor of adding such an API, but I'd prefer if it was rich enough to also support touchscreen pinch zoom (would be weird if we fired it in all zoom scenarios other than that).  So we'd probably want to include a co-ordinate with the event (so that pinch/drag still tracks your fingers).  But then it's not clear what co-ordinates we'd use for keyboard zoom.  We also need to be careful with the scale to ensure pinch-zoom sticks to your fingers.

Rather than a device integer as suggested in #c1, I'd want to leverage UIEvent.sourceDevice (rbyers.github.io/InputDevice/inputdevice.html).

Sounds like we should talk to Dean Jackson at Apple to make sure we get an API they'd be happy with: https://twitter.com/RickByers/status/618380969343451136

If we're going to do all this, then perhaps it should have zoombegin/zoomend events too (or some equivalent way to know when the user lifts their fingers off the trackpad / touchscreen - maybe a simple 'boolean isEnding' is sufficient).


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/31