Re: pan, rotation, move and zoom request events

So for the long-overdue response to this. Leaving Jason's full email body to give context. Response and changeset link follows.

On Dec 12, 2012, at 11:28 PM, Jason White <jason@jasonjgw.net> wrote:

> Note: this issue, if substantive, need not be considered until the first
> working draft of IndieUI Events is published.
> 
> This might be merely symptomatic of a lack of background on my part, but it
> isn't clear to me what the spec demands of Web applications in response to
> these events. What is a pan event required to do that a move event is not? The
> only explanation in the document as it stands is the following: "This is used,
> for example, when changing the center point while panning a map or another
> custom image viewer." I would welcome a clearer statement of the semantic
> difference between the two, noting that they both take the same arguments,
> viz., an offset in the rectangular coordinate plane.
> 
> For the rotation event, it is clear what the angle of rotation specifies, but
> it's less obvious how the origin is taken into account and exactly what
> qualifies as a conforming response to the event.
> 
> For zoom, the scale factor presumably scales the image as requested, or is it
> meant to be only part of the image, centred at the specified origin? The
> latter interpretation is the obvious way to read the draft, but again, it
> isn't made perspicuous what the requirements are.
> 
> I think it is important to be very specific about what behaviour is expected
> of applications that handle the events defined in the spec, and these are
> several cases in which, it seems to me, greater precision would be valuable.

This is a good feedback. Please let me know if the following change alleviate the concern. I have changed the IDL so that the origin values are nullable and default to null instead of 0.0.

originX? of type optional double, defaulting to null
The cartesian X coordinate origin point (if one exists), measured in CSS pixels from the left edge of element box for the receiver element.
originY? of type optional double, defaulting to null
The cartesian Y coordinate origin point (if one exists), measured in CSS pixels from the top edge of element box for the receiver element.
I also added the following clarifying note to "rotationrequest"…

NOTE
In the case where a User Agent lacks a clear or relevant point of origin, user agents could send null values for originX and originY, or they could send x/y coordinates representing the center point of the event.receiver element.

For example, many photo manipulation applications allow users to change orientation, or rotating a photograph 90 degrees, by pressing a key combination like option+leftarrow or option+rightarrow. Since this represents a keyboard only event that is unrelated to the mouse pointer location, it would be appropriate to send null values. In many cases, web applications may not require the origin x/y coordinates even if non-null values exist.

Changeset:
https://dvcs.w3.org/hg/IndieUI/rev/14e1ed0e45fd