- From: <bugzilla@jessica.w3.org>
- Date: Thu, 21 Aug 2014 01:35:29 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26611 --- Comment #6 from Masayuki Nakano <masayuki@d-toybox.com> --- (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... -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 21 August 2014 01:35:31 UTC