Re: New DOM event types

> 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.

What situation would cause a scroll event to not be synchronized with the
scrolling action?  I agree that it only serves as a notification. But do we
really want web pages to be able to prevent a high level UI task such as
scrolling or zooming?  If I go to scroll the web page and the page cancels
the beforescroll, how will this not be perceived as unresponsive browser UI?
Similarly, why would I want to prevent users from zooming the page? I'm not
sure that's helpful for accessibility either.

Maybe I'm being ignorant of possible use cases for these events to be
cancelable. But otherwise, I'm not sure I grasp the point of these events.
Can you provide some example use cases?

Best,

Jacob

 From: François REMY
<fremycompany_pub@yahoo.fr<fremycompany_pub@yahoo.fr?Subject=Re%3A%20New%20DOM%20event%20types&In-Reply-To=%253CEF4CC4C016C748168714287F7C157EF6%40Fremy1%253E&References=%253CEF4CC4C016C748168714287F7C157EF6%40Fremy1%253E>
>
Date: Wed, 17 Mar 2010 09:43:19 +0100
Message-ID: <EF4CC4C016C748168714287F7C157EF6@Fremy1>
To: <www-dom@w3.org<www-dom@w3.org?Subject=Re%3A%20New%20DOM%20event%20types&In-Reply-To=%253CEF4CC4C016C748168714287F7C157EF6%40Fremy1%253E&References=%253CEF4CC4C016C748168714287F7C157EF6%40Fremy1%253E>>,
João Eiras <joaoe@opera.com<joaoe@opera.com?Subject=Re%3A%20New%20DOM%20event%20types&In-Reply-To=%253CEF4CC4C016C748168714287F7C157EF6%40Fremy1%253E&References=%253CEF4CC4C016C748168714287F7C157EF6%40Fremy1%253E>
>

Great proposal.

--------------------------------------------------
From: "João Eiras" <joaoe@opera.com
<joaoe@opera.com?Subject=Re%3A%20New%20DOM%20event%20types&In-Reply-To=%253CEF4CC4C016C748168714287F7C157EF6%40Fremy1%253E&References=%253CEF4CC4C016C748168714287F7C157EF6%40Fremy1%253E>>
Sent: Wednesday, March 17, 2010 1:46 AM
To: <www-dom@w3.org
<www-dom@w3.org?Subject=Re%3A%20New%20DOM%20event%20types&In-Reply-To=%253CEF4CC4C016C748168714287F7C157EF6%40Fremy1%253E&References=%253CEF4CC4C016C748168714287F7C157EF6%40Fremy1%253E>>
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/
>