[whatwg] Suggested enhancement for initialization of mouse events

[Ashley Sheridan]

On Tue, 2010-09-14 at 07:51 -0400, Jim Williams wrote:

> Currently, there appears to be no way of sensing the location of the
> mouse cursor without waiting for user-initiated events.  The problem
> is that there is no way to fill in the real current values for many of
> the parameters when executing the following, without copying needed
> information from a user-initiated mouse event such as mousemove, for
> example:
> 
>         event.initMouseEvent(type, canBubble, cancelable, view, 
>             detail, screenX, screenY, clientX, clientY, 
>             ctrlKey, altKey, shiftKey, metaKey, 
>             button, relatedTarget); 
> 
> This problem is one of the things that made implementation of the
> mousepoint event difficult [cf.
> http://pagenotes.com/mousepoint/mousepointEvent.htm]. 
> 
> Suggested Enhancement
> 
> One way of addressing this problem is to allow omitted arguments that
> are correctly filled in by the implementation.  That is to say, allow 
> 
>         event.initMouseEvent(type, canBubble, cancelable, view,
>         relatedTarget), 
> 
> where the omitted arguments reflect the mouse's current state, e.g.,
> screenX is the mouse's current screenX coordinate.
> 
> Another possibility is to enhance  initEvent so that, in the case of
> mouse events, initEventfills in correct values for those parameters
> that would otherwise be set by initMouseEvent.  In order for this
> approach to be fully effective, it would be necessary to allow an
> optional fourth argument for the relatedTargetparameter, in other
> words, allow any user defined event to supply a related target, if
> appropriate:
> 
> event.initEvent(type, bubbles, cancelable, relatedTarget); 
> 
> In the case of a mouse event, this would be equivalent to 
> 
>         event.initMouseEvent(type, canBubble, cancelable, view, 
>             detail, screenX, screenY, clientX, clientY, 
>             ctrlKey, altKey, shiftKey, metaKey, 
>             button, relatedTarget); 
> 
> where the additional arguments have their actual current values.
> 
> On the one hand, I realize it's a bit late in the game for this sort
> of suggestion, but on the other, this note does point out a weakness
> of the event interface that could easily be removed.
> 
> Jim Williams


I'm not entirely sure that this is possible. As far as I know (and I
could be very wrong) the events start with the OS and work their way
down the system to eventually reach the Javascript through a user agent,
so if the mouse has moved off of the user agent (browser) then it may
not be possible to access the current coordinates. The browser would
only be aware of the coordinates that it was last passed by the OS, i.e.
only those in it's own window space. A browser could offer up the last
known coordinates, but if the cursor is beyond the region of a browser
window for example, then the browser would be passing across the wrong
values. This might not matter for most cases, but then again, I can't
foresee much use for having the coordinates of a cursor that triggered
no event. The only time a user agent might be aware of the correct
coordinates and no event would be triggered would be where the cursor
was over part of the user agent that wasn't the web page, like the
menubar, etc.

Thanks,
Ash
http://www.ashleysheridan.co.uk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100914/e526f3b1/attachment-0002.htm>