<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Calibri">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:</font><br>
<blockquote><tt><em>event</em>.initMouseEvent(<em>type</em>, <em>canBubble</em>,
  <em>cancelable</em>, <em>view</em>, <br>
  <em>    detail</em>, <em>screenX</em>, <em>screenY</em>, <em>clientX</em>,
  <em>clientY</em>, <br>
  <em>    ctrlKey</em>, <em>altKey</em>, <em>shiftKey</em>, <em>metaKey</em>,
  <br>
  <em>    button</em>, <em>relatedTarget</em>);</tt> </blockquote>
<font face="Calibri">This
problem is one of the things that made implementation of the
mousepoint event difficult [cf. <a
 href="http://pagenotes.com/mousepoint/mousepointEvent.htm">http://pagenotes.com/mousepoint/mousepointEvent.htm</a>]. 
</font><br>
<br>
<font face="Calibri"><b>Suggested Enhancement<br>
</b><br>
One way of addressing this problem is to allow omitted arguments that
are correctly filled in by the implementation.  That is to say, allow </font><br>
<blockquote><tt><em>event</em>.initMouseEvent(<em>type</em>, <em>canBubble</em>,
  <em>cancelable</em>,<i> view</i>, <em>relatedTarget</em>),</tt> </blockquote>
<font face="Calibri">where the omitted arguments reflect the mouse's
current state, e.g., </font><tt><i>screenX</i> </tt><font
 face="Calibri">is the mouse's current </font><tt><i>screenX</i> </tt><font
 face="Calibri">coordinate.<br>
<br>
Another possibility is to enhance  </font><tt>initEvent </tt><font
 face="Calibri">so that, in the case of mouse events, </font><tt>initEvent
</tt><font face="Calibri">fills in correct values for those parameters
that would otherwise be set by </font><tt>initMouseEvent</tt><font
 face="Calibri">.  In order for this approach to be fully effective, it
would be necessary to allow an optional fourth argument for the </font><i><tt>relatedTarget
</tt></i><font face="Calibri">parameter, in other words, allow any user
defined event to supply a related target, if appropriate:</font><br>
<pre class="eval"><em>     event</em>.initEvent(<em>type</em>, <em>bubbles</em>, <em>cancelable</em>, <i>relatedTarget</i>); 
</pre>
<font face="Calibri">In the case of a mouse event, this would be
equivalent to <br>
</font>
<blockquote><tt><em>event</em>.initMouseEvent(<em>type</em>, <em>canBubble</em>,
  <em>cancelable</em>, <em>view</em>, <br>
  <em>    detail</em>, <em>screenX</em>, <em>screenY</em>, <em>clientX</em>,
  <em>clientY</em>, <br>
  <em>    ctrlKey</em>, <em>altKey</em>, <em>shiftKey</em>, <em>metaKey</em>,
  <br>
  <em>    button</em>, <em>relatedTarget</em>);</tt> </blockquote>
<font face="Calibri">where the additional arguments have their actual
current values.<br>
<br>
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.<br>
<br>
Jim Williams</font><br>
</body>
</html>