- From: François REMY <fremycompany_pub@yahoo.fr>
- Date: Wed, 17 Mar 2010 09:43:19 +0100
- To: <www-dom@w3.org>, João Eiras <joaoe@opera.com>
Great proposal. -------------------------------------------------- From: "João Eiras" <joaoe@opera.com> Sent: Wednesday, March 17, 2010 1:46 AM To: <www-dom@w3.org> Subject: New DOM event types > > Hi gentlemen. > > We at Opera have had some demands to find ways that will allow a webpage > to control zooming or panning/scrolling, specially on mobiles. The typical > use case are map applications on devices, where the user double taps or > drags the viewport around to zoom and pan, although the map should have > the chance to detect these events and apply them on the map instead. > Dragging overlaid objects in the page is also another use case. > > Subject of work, the DOM 3 Level Events spec > http://www.w3.org/TR/DOM-Level-3-Events/ > http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html > > First case: scrolling. > > The specification already specifies the 'scroll' event, which is not > synchronized with the scrolling action, and not cancelable, being > therefore only useful as a notification. We need a type of scroll event > which would be synchronized with the scrolling action, and if prevented > would prevent the scrolling entirely. The event can be called > 'beforescroll'. The scroll event needs both a deltaX and deltaY with the > amount of pixels by with he user agent will scroll as consequence of > diagonal scroll/pan. Unfortunately, .detail is not enough. > > So, to summarize: > - new event type 'beforescroll', fired before any scrolling action, > cancelable > - probably a new interface derived from Event, which has the deltaX and > deltaY, like ScrollEvent, or extending that information in UIEvent > > Second case: zooming > > There are no references to zooming or zoom events in the specification, > but there is a magnify event on the developer working draft. Ideally, we > should have both a 'beforemagnify' event, like 'beforescroll', cancelable > and synchronized with the zooming action, and an 'aftermagnify', not > cancelable, and not synchronized with the zooming action. Given that > zooming is a viewport action, UIEvent.detail should be good enough to give > the *new* zoom level that the user agent will apply to the viewport. The > detail property would contain an integer with the zoom level in > percentage, meaning 100 would be the default zoom level. However, it would > be useful to have the *current* zoom level available in a global property, > like window.zoomLevel, but that is out of scope of this specification. > > Handling the target would be similar to the scroll event. In case the > zooming action is performed by a pointing device on top of an element, > like mousewheel when scrolling, the target of the event is the element > beneath the pointing device. Typical examples: pinching on a touch screen, > double tapping on devices, ctrl+mousewheel on desktop computer. If the > zoom action is triggered by other means, and therefore is not "caught" > by the element beneath the pointing device, then the target is the > document. > > To summarize: > - new event type 'beforemagnify', fired before any scrolling action, > cancelable > - new event type 'magnify', fired after any scrolling action, not > cancelable, doesn't bubble. (It's in the WD) > - UIEvent.detail has the new zoom level applied o the viewport > - Event.target set to element below cursor, or document if a pointing > device was not used > > Whether beforescroll and beforemagnify buble or not is debatable. > Typically, non-cancelable events aren't while cancelable ones are. I > don't have very strong feelings about this one. > > Problem: what happens if a script triggers scrolling, like changing > styles which cause a scrollable container to scroll, assigning > location.hash to a new fragment identifier, or assigning scrollTop on a > scrollable container? Possible answer: the beforescroll and before > magnify events should only be fired in response to user input, and not > scripting. The scripts themselves can know if the page is going to > scroll in advance and make all proper provisions. User input includes > dragging scrollbars, PgUp, PgDown, arrow keys (mobiles and pcs), spatial > navigation, finger swiping, clicking link with fragment identifier, etc... > > Theoretical problem: the synchronous cancelable events can introduce > scrolling, or zooming lag. Unfortunately, this is by design as the > scripting environment *needs* to invoke all listeners. To minimize this > problem, the events don't bubble (naturally), and there are the events > that fire *after* the action, just in case the webpage only needs a > notification. > > People usually confuse low level mouse events with these actions. Zooming > and scrolling are high level UI actions, which can be triggered in many > other means than just the mouse. Please do not confuse them. > > Whether you consider giving the webpage control over these events an > annoyance or not, that is a user agent usability problem. Ask for a > configuration option from your favorite vendor :) > > Thoughts ? > > Thank you o/ >
Received on Wednesday, 17 March 2010 08:45:50 UTC