mouse-lock.html
changeset 135 7df1fb3c1fbc
parent 134 536cc04c0377
child 136 e6b893606800
--- a/mouse-lock.html	Tue Oct 25 11:32:27 2011 -0700
+++ b/mouse-lock.html	Tue Oct 25 15:53:34 2011 -0700
@@ -88,6 +88,12 @@
         white-space: pre-wrap;
       }
     </style>
+
+    <script>
+        function escapeContents(doc, content) {
+            return doc._esc(content);
+        }
+    </script>
   </head>
   <body>
     <section id='abstract'>
@@ -97,39 +103,31 @@
       mode for certain classes of applications, especially first person
       perspective 3D applications and 3D modelling software.
     </section>
-    
+
     <section id="sotd"> <!-- Status of This Document -->
-      Conversion in progress from the <a href="http://goo.gl/9G8pd">Version 
-      0.8, 2011-10-20 Draft Spec</a> Google Document.
     </section>
 
-    </section> 
-
     <section id='introduction' class='informative'>
 
       <h2>Introduction</h2>
 
-      <p>The Mouse Lock API provides for input methods of applications based on 
-      the movement of the mouse, not just the absolute position of a cursor.  A 
-      popular example is that of first person movement controls in three 
-      dimensional graphics applications such as games.  Movement of the mouse is 
-      interpreted for rotation of the view-port, there is no limit to how far 
+      <p>The Mouse Lock API provides for input methods of applications based on
+      the movement of the mouse, not just the absolute position of a cursor.  A
+      popular example is that of first person movement controls in three
+      dimensional graphics applications such as games.  Movement of the mouse is
+      interpreted for rotation of the view-port, there is no limit to how far
       movement can go, and no mouse cursor is displayed.</p>
-      
-      <p>Mouse Lock is related to Mouse Capture [MDCCAP].  Capture provides 
-      continued event delivery to a target element while a mouse is being 
-      dragged, but ceases when the mouse button is released.  Mouse Lock differs 
-      by being persistent, not limited by screen boundaries, sending events 
-      regardless of mouse button state, hiding the cursor, and not releasing 
-      until an API call or specific release gesture by the user.</p> 
+
+      <p>Mouse Lock is related to Mouse Capture [MDCCAP].  Capture provides
+      continued event delivery to a target element while a mouse is being
+      dragged, but ceases when the mouse button is released.  Mouse Lock differs
+      by being persistent, not limited by screen boundaries, sending events
+      regardless of mouse button state, hiding the cursor, and not releasing
+      until an API call or specific release gesture by the user.</p>
 
     </section>
 
     <section id='conformance'>
-      <p class="issue" id="issue-whatever">
-        Please check this section is OK . 
-      </p>
-
       <p>
         This specification defines conformance criteria that apply to a single
         product: the <dfn id="dfn-user-agent">user agent</dfn> that implements
@@ -161,43 +159,45 @@
         <dd>
           <dfn title="lockMouse"></dfn>
 
-          <p>The <code>lockMouse</code> method requests that the mouse be locked 
+          <p>The <code>lockMouse</code> method requests that the mouse be locked
           to a given DOM element <code>target</code>. It must immediately
-          return. Two optional callback parameters provide asynchronous 
+          return. Two optional callback parameters provide asynchronous
           notification of success (<code>successCallback</code>) or failure
-          (<code>failureCallback</code>) to acquire the locked state. The user 
-          agent must determine if mouse lock state will be entered and call the 
-          appropriate callback if it was provided.  Because a user agent may 
-          prompt a user for permission to enter mouse lock the response must be 
+          (<code>failureCallback</code>) to acquire the locked state. The user
+          agent must determine if mouse lock state will be entered and call the
+          appropriate callback if it was provided.  Because a <a>user agent</a> may
+          prompt a user for permission to enter mouse lock the response must be
           asynchronous.</p>
 
-          <p>Mouse lock must succeed only if the window is in focus and the 
-          user-agent is the active application of the operating system. The 
+          <p>Mouse lock must succeed only if the window is in focus and the
+          user-agent is the active application of the operating system. The
           target element of <code>lockMouse</code> need not be in focus.</p>
 
-          <p>Mouse lock must succeed only if the target element is in the DOM 
-          tree. If the target element is removed from the DOM tree after mouse 
+          <p>Mouse lock must succeed only if the target element is in the DOM
+          tree. If the target element is removed from the DOM tree after mouse
           lock is entered then mouse lock will be lost.</p>
 
-          <p>If the mouse is already locked to the same element, a repeated 
-          call to <code>lockMouse</code> will succeed and the 
-          <code>successCallback</code> called. If 
-          another element is locked a user agent must transfer the mouse lock to 
-          the new target and call the <a>mouselocklost</a> callback for the previous 
+          <p>If the mouse is already locked to the same element, a repeated
+          call to <code>lockMouse</code> will succeed and the
+          <code>successCallback</code> called. If
+          another element is locked a <a>user agent</a> must transfer the mouse lock to
+          the new target and call the <a><code>mouselocklost</code></a> callback for the previous
           target.</p>
 
-          <p>Once in the locked state the user agent must fire all relevant user 
-          generated <code>MouseEvent</code> events (for example: <code>mousemove</code>, <code>mousedown</code>, 
-          <code>mouseup</code>, <code>click</code>, <code>wheel</code>)[DOMMOUSE] to the target of mouse lock, and 
-          not fire mouse events to other elements. Events that require the 
-          concept of a mouse cursor must not be dispatched (for example: 
-          <code>mouseover</code>, <code>mouseout</code>).</p>
-          
-          <p>In the locked state the system mouse cursor 
-          must be hidden. Movement and button presses of the mouse must not 
+          <p>Once in the locked state the <a>user agent</a> must fire all relevant
+          user generated <code>MouseEvent</code> events (for example:
+          <code>mousemove</code>, <code>mousedown</code>, <code>mouseup</code>,
+          <code>click</code>, <code>wheel</code>)[<a
+          href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-MouseEvent">DOMMOUSE</a>]
+          to the target of mouse lock, and not fire mouse events to other elements.
+          Events that require the concept of a mouse cursor must not be dispatched
+          (for example: <code>mouseover</code>, <code>mouseout</code>).</p>
+
+          <p>In the locked state the system mouse cursor
+          must be hidden. Movement and button presses of the mouse must not
           cause the window to lose focus.</p>
 
-          <p>Synthetic mouse events created by application script act the same 
+          <p>Synthetic mouse events created by application script act the same
           regardless of lock state.<p>
 
           <dl class='parameters'>
@@ -212,9 +212,10 @@
           <dfn title="unlockMouse"></dfn>
 
           <p>The <code>unlockMouse</code> method cancels the mouse lock state.
-          The system mouse cursor must be displayed again and positioned at 
+          The system mouse cursor must be displayed again and positioned at
           the same location that it was when mouse lock was entered (the same
-          location that is reported in screenX/Y when the mouse is locked).</p>
+          location that is reported in <code>screenX</code>/<code>Y</code>
+          when the mouse is locked).</p>
         </dd>
 
         <dt>Element mouseLocked ()</dt>
@@ -228,7 +229,7 @@
     </section>
 
     <section>
-      <h2><a>mouselocklost</a> Event</h2>
+      <h2><dfn><code>mouselocklost</code></dfn> Event</h2>
 
       <p>User agents must allow a new DOM event type, named
       <code>mouselocklost</code> of type <code>MouseLockLostEvent</code>
@@ -239,6 +240,460 @@
       </dl>
     </section>
 
+    <section>
+      <h2>Extensions to the <a>MouseEvent</a> Interface</h2>
+
+      <p>User agents must extend the MouseEvent interface [<a
+      href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-MouseEvent">DOMMOUSE</a>]
+      with two members:</p>
+
+      <dl title='partial interface MouseEvent' class='idl'>
+        <dt>readonly attribute long movementX</dt>
+        <dd><dfn title="movementX"></dfn></dd>
+        <dt>readonly attribute long movementY</dt>
+        <dd><dfn title="movementY"></dfn></dd>
+      </dl>
+
+      <p>The members <code>movementX</code> and <code>movementY</code> must
+      provide the change in position of the mouse, as if the values of
+      <code>screenX</code>/<code>Y</code> were stored between two subsequent
+      <code>mousemove</code> events <code>eNow</code> and
+      <code>ePrevious</code> and the difference taken
+      <code>movementX = eNow.screenX-ePrevious.screenX</code>.</p>
+
+      <p><code>movementX</code>/<code>Y</code> must be valid regardless of mouse
+      lock state.</p>
+
+      <p>When unlocked, the system cursor can exit and re-enter the <a>user
+      agent</a> window.  If it does so and the <a>user agent</a> was not the
+      target of operating system mouse move events then the most recent mouse
+      position will be unknown to the <a>user agent</a> and
+      <code>movementX</code>/<code>Y</code> can not be computed and must be set
+      to zero.</p>
+
+      <p>When mouse lock is enabled <code>clientX</code>, <code>clientY</code>,
+      <code>screenX</code>, and <code>screenY</code> must hold constant values
+      as if the mouse did not move at all once mouse lock was entered.  But
+      <code>movementX</code>/<code>Y</code> must continue to provide the change
+      in position of the mouse as when the mouse is unlocked.  There will be no
+      limit to <code>movementX</code>/<code>Y</code> values if the mouse is
+      continuously moved in a single direction.  The concept of the mouse cursor
+      will have been removed, and it will not move off the window or be clamped
+      by a screen edge.</p>
+    </section>
+
+    <section>
+      <h2>Requirements</h2>
+
+      <p>The Mouse Lock API must provide a default system action to unlock the
+      mouse.</p>
+
+      <p>The Mouse Lock API must be agnostic to the underlying system-specific
+      mouse locking mechanism.</p>
+
+      <p>The Mouse Lock API must exit the mouse lock state if the <a>user agent</a>,
+      window, or tab loses focus.</p>
+    </section>
+
+    <section class='informative'>
+      <h2>Use Cases</h2>
+
+      <section>
+        <h2>Relative view-port rotation of free moving virtual actors</h2>
+
+        <p>A player on a first/third person game will need to control the
+        view-port orientation.  A widely used method is the use of mouse movements
+        to control the viewing angle.  This kind of application can use the Mouse
+        Lock API to allow a complete freedom of control over the viewport's yaw
+        and pitch even when the user is not pressing mouse buttons.  Those buttons
+        can be used for other actions while constantly providing navigation via
+        mouse movement.</p>
+      </section>
+
+      <section>
+        <h2>Free rotation of 3D models or panning of 2D layers</h2>
+
+        <p>Users of a three dimensional modeling application will need to rotate
+        models.  A application can use the Mouse Lock API to enable the author to
+        rotate the model freely in a drag operation without limiting motion.
+        Without mouse lock a drag would stop providing motion data when the mouse
+        cursor is limited by the edge of the screen.</p>
+
+        <p>Similarly, absolute motion panning of a large two dimensional image
+        could be permitted in a single drag operation without cursor / screen
+        limits.</p>
+      </section>
+
+      <section>
+        <h2>Relative movement of actors</h2>
+
+        <p>A player on a fast reflexes game controls a paddle to bounce back a
+        ball to the opponent, while allowing the same paddle to execute actions
+        based on different mouse buttons being pressed.  The application can use
+        the Mouse Lock API to allow the player to react quickly without being
+        concerned about the mouse cursor leaving the game play area and clicking
+        another system application, thus breaking the game flow.</p>
+      </section>
+
+      <section>
+        <h2>Jog movement over spinner controls</h2>
+
+        <p>When modifying numerically magnitudes in applications sometimes the
+        user will prefer to "drag" a numeric control (e.g.  a spinner [<a
+        href="http://books.zkoss.org/wiki/Small%20Talks/2008/June/Using%20Spinner%20Component">ZKSPINNER</a>])
+        by its button handles to increment or decrement the numeric value.  An
+        application could use the Mouse Lock API to allow modifying the numeric
+        values beyond what the logical screen bounds allow.  The same could apply
+        for a control that fast forwards or rewinds a video or audio stream like a
+        "jog".</p>
+      </section>
+
+      <section>
+        <h2>Synthetic cursor interaction with HTML DOM UI</h2>
+
+        <p>Some games use a classical cursor, however they want it to be limited
+        or controlled in some manner.  E.g.  limited to the bounds of the game, or
+        movable by the game.  Locking the mouse enables this if the application
+        creates their own cursor.  However HTML and DOM should still be available
+        to use for user interface.  Synthetic mouse events should be permitted to
+        allow an application defined cursor to interact with DOM.  E.g.  the
+        following code should permit a custom cursor to send click events while
+        the mouse is locked:</p>
+
+        <pre class='example' data-transform='escapeContents'>
+            document.addEventListener("click", function (e) {
+              if (e._isSynthetic)
+                return;
+              // send a synthetic click
+              var ee = document.createEvent("MouseEvents");
+              ee._isSynthetic = true;
+              x = myCursor.x;
+              y = myCursor.y;
+              ee.initMouseEvent("click", true, true, null, 1,
+                                x + e.screenX - e.clientX,
+                                y + e.screenY - e.clientY,
+                                x,
+                                y);
+              var target = document.elementFromPoint(x, y)
+              if (target)
+                target.dispatchEvent(ee)
+            });
+        </pre>
+
+        <p>Note that synthetic clicks may not be permitted by a <a>user agent</a> to
+        produce the same default action as a non-synthetic click.  However,
+        application handlers can still take action and provide user interface with
+        existing HTML & DOM mechanisms.</p>
+      </section>
+
+      <section>
+        <h2>View-port panning by moving a mouse cursor against the bounds of a
+        view-port.</h2>
+
+        <p>Real Time Strategy games often use this technique.  When the player
+        moves the mouse to the view-port borders, if they "push" the border
+        with a mouse movement, the view-port is panned over the game area
+        according to how much they move the mouse.  When moving the mouse cursor
+        within the bounds of the view port it acts at is typically would on a
+        system.  Applications may choose to implement this using mouse lock and
+        the previous use case of "Synthetic cursor interaction with HTML DOM UI"
+        to bring cursor behavior completely under their control.</p>
+      </section>
+
+      <section>
+        <h2>Game Lobby, timer based mouse lock</h2>
+
+        <p>Games that use mouse lock may desire a traditional UI and system cursor
+        while players prepare in a game lobby.  Games usually start after a short
+        timer when all players are ready.  Ideally the game could then switch to
+        mouse lock mode without requiring a user gesture.  Players should be able
+        to seamlessly move from the game lobby into game navigation.</p>
+      </section>
+
+      <section>
+        <h2>Game Portal</h2>
+
+        <p>Game portals, and other sites such as Facebook and Google Plus, host
+        games for users to play.  These games may be hosted and served from a
+        different origin from that of the portal site.  Embedded games should be
+        able to lock the mouse, even in non-full screen mode.</p>
+      </section>
+
+    </section>
+
+    <section class='informative'>
+      <h2>Security</h2>
+
+      <p>Security Concerns:</p>
+        <ul>
+          <li>User gestures may be misdirected to elements the user did not intend
+          to interact with.</li>
+
+          <li>Mouse Lock will remove the ability of a user to interact with user
+          agent and operating system controls</li>
+
+          <li>Mouse Lock can be called repeated by script after user exits mouse
+          lock, blocking user from meaningful progress.</li>
+
+          <li>Full screen exit instructions are displayed in some <a>user agents</a> when
+          the mouse is moved to the top of the screen.  During mouse lock that
+          gesture is not possible.</li>
+        </ul>
+
+        <p>Responses:</p>
+        <ul>
+          <li>User agents may limit what security origins may lock the mouse.</li>
+
+          <li>User agents may prompt for confirmation before locking, this
+          preference may be saved as a content setting.</li>
+
+          <li>Keyboard based escape will always be provided, e.g.  ESC key.</li>
+
+          <li>Persistent display of escape instructions can be provided.</li>
+
+          <li>Repeated escapes of mouse lock can signal <a>user agent</a> to not re-lock
+          the mouse without more specific user intent gesture, e.g.  similar to how
+          Chrome suppresses repeated alert() calls.</li>
+
+          <li>Changing to new tabs, windows, or any other action that causes a page
+          to lose focus will exit mouse lock.</li>
+
+          <li>Mouse lock can only be engaged when the window is in focus in the user
+          agent and operating system.</li>
+        </ul>
+
+        <p>Recommendations:</p>
+        <ul>
+          <li>ESC key should exit mouse lock.</li>
+
+          <li>Preferences per sub-domain can be used to allow or block mouse lock,
+          similar to popup, geolocation, and fullscreen.</li>
+        </ul>
+
+        <p>Mouse Lock is a required user interaction mode for certain application
+        types, but carries a usability concern if maliciously used.  An attacker
+        could remove the ability for a user to control their mouse cursor on their
+        system.  User agents will prevent this by always providing a mechanism to
+        exit mouse lock, by informing the user of how, and by limiting how mouse
+        lock can be entered.</p>
+
+        <p>User agents will determine their own appropriate policies, which may be
+        specialized per device or differ based on user options.  The following
+        discussion illustrates considerations and plausible implementations.</p>
+
+        <dl>
+          <dt>Escape from mouse lock must always be possible.</dt>
+          <dd>Based on device the mechanisms will vary, but obvious examples include
+          the keyboard escape key "ESC" and any control that moves the system focus
+          away from the web page (window management keystrokes that change windows,
+          operating system buttons such as the Windows key).</dd>
+
+          <dt>Escape instructions may be communicated.</dt>
+          <dd>User agents can provide persistent on screen instructions, or
+          transitory instructions when mouse lock is entered.  If users are
+          particularly dissatisfied with the distraction of instructions <a>user agents</a>
+          may offer to hide instructions after sufficient intent is expressed, e.g.
+          by permissions.</dd>
+
+          <dt>Escape can not be performed by mouse actions, including the use of the
+          context menu.</dt>
+          <dd>The intent of the Mouse Lock feature is to enable rich applications
+          not currently available in browsers.  These applications have unbounded
+          movement and button press consumption needs, including the use of the
+          context menu.<dd>
+        </dl>
+
+        <p>Examples of user agent scenarios:</p>
+
+        <dl>
+          <dt>A conservative approach</dt>
+          <dd>May only permit mouse lock based on a user gesture such as a click
+          event.  The <a>user agent</a> would prompt the user with a confirmation dialog,
+          with options to permit, dismiss, or block all repeated attempts.  That
+          dialog may be a passive display instead of modal.  Instructions for escape
+          would be provided.  After acceptance, a succinct reminder notice of escape
+          instructions may persist.  In the extreme, a <a>user agent</a> may require the
+          user to perform an uncommon gesture demonstrating that they understand the
+          escape gesture, e.g.  by pressing F10.</dd>
+
+          <dt>A full screen approach</dt>
+          <dd>May permit mouse lock at any time, and cancel mouse lock when full
+          screen mode is exited.  Instructions for exiting full screen mode may be
+          shown, likely for a brief period of time to not detriment the full screen
+          experience.  Entry to mouse lock may be gated by a user explicitly
+          confirming the action via a dialog.</dd>
+
+          <dt>A permissive approach</dt>
+          <dd>May permit mouse lock for the target or ancestor of a a user gesture
+          without prompt.  Escape instructions would likely be displayed
+          persistently in a non full screen view.</dd>
+        </dl>
+
+        <p>Chrome / Chromium has a design document page for their implementation
+        of mouse lock: <a
+        href="http://www.chromium.org/developers/design-documents/mouse-lock">http://www.chromium.org/developers/design-documents/mouse-lock</a></p>
+
+    </section>
+
+    <section class='informative'>
+      <h2>Frequently Asked Questions</h2>
+
+      <section>
+        <h2>Why not merge with Mouse Capture: setCapture()?</h2>
+
+        <p>Mouse Capture [<a
+        href="https://developer.mozilla.org/en/DOM/element.setCapture">MDCCAP</a>]
+        handles low security risk mouse event target lock for the duration of a
+        mouse drag gesture.  Mouse Lock removes the concept the the cursor and
+        directs all events to a given target.  They are related, but
+        different.</p>
+
+        <p>If a browser implemented both, it would be reasonable to support a
+        combination of traits: The security simplicity of "automatically release
+        lock when mouse up" and the increased functionality of total control over
+        mouse input and removal of the system cursor.  The security trait would
+        allow more permissive use of the feature for applications that only
+        required a short burst of mouse lock during a drag event.</p>
+
+        <p>This functionaility is omitted from the initial version of this spec
+        because it helps the minor use cases in windowed mode but we still do not
+        have an implementation solving the major ones.  And, to implement this a
+        browser must implement both, which none does yet.  It is not clear if this
+        feature should live on .lockMouse or on .setCapture.  If both were
+        implemented, either API could be augmented fairly easily to offer the
+        hybrid functionality.</p>
+      </section>
+
+      <section>
+        <h2>Why not repurpose MouseEvent's .clientX/Y .screenX/Y?</h2>
+
+        <p>Even in non locked state, the delta values of mouse movement are
+        useful.  Changing the meaning of .client or .screen based on lock state
+        would also cause easy errors in code not carefully monitoring the lock
+        state.</p>
+      </section>
+
+      <section>
+        <h2>Why use .movementX/Y instead of .deltaX/Y?</h2>
+
+        <p>When the mouse is locked 'wheel' events should be sent to the mouse
+        lock target element just as 'mousemove' events are.  There is a naming
+        conflict with .deltaX/Y/Z as defined in <a
+        href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-wheelevents">DOM
+        3 'wheel' event</a>.</p>
+      </section>
+
+      <section>
+        <h2>Why bundle all functionality (hiding cursor, providing mouse deltas)
+        instead of using CSS to hide the cursor, always providing delta values,
+        and offering an API to restrict the cursor movement to a portion of the
+        webpage?</h2>
+
+        <p>There are good motivations to provide a more fine grained approach.
+        E.g.  the use case "View-port panning by moving a mouse cursor against the
+        bounds of a view-port" doesn't require hiding the mouse cursor, only
+        bounding it and always having delta values available.  Also, this
+        specification defines the movement deltas to be taken from how the system
+        mouse cursor moves, which incorporates operating system filtering and
+        acceleration of the mouse movement data.  Applications may desire access
+        to a more raw form of movement data prior to adjustments appropriate for a
+        mouse cursor.  Also, raw data may provide better than pixel level accuracy
+        for movement, as well as higher frequency updates.  Providing the raw
+        delta movement would also not require special permission or mode from a
+        user, and for some set of applications that do not require bounding the
+        cursor may reduce the security barriers and prompts needed.</p>
+
+        <p>There are two justifications for postponing this finer grained
+        approach.  The first is a concern of specifying what units mouse movement
+        data are provided in.  This specification defines .movementX/Y precisely
+        as the same values that could be recorded when the mouse is not under lock
+        by changes in .screenX/Y.  Implementations across multiple <a>user agents</a> and
+        operating systems will easily be able to meet that requirement and provide
+        application developers and users with a consistent experience.  Further,
+        users are expected to have already configured the full system of hardware
+        input and operating system options resulting in a comfortable control the
+        system mouse cursor.  By specifying .movementX/Y in the same units mouse
+        lock API applications will be instantly usable to all users because they
+        have already settled their preferences.</p>
+
+        <p>Secondly, the implementation of providing movement data and bounding
+        the mouse cursor is more difficult in the fine grained approach.  Bundling
+        the features together gives implementations freedom to use a variety of
+        techniques as appropriate on each operating system and is more practical
+        to implement.  Direct APIs do not exist on all platforms (Win, Mac, Linux)
+        to bound the cursor to a specific rectangle, and prototypes have not yet
+        been developed to demonstrate building that behavior by e.g.  invisible
+        windows with xlib or manual cursor movement on Mac.  Unaccelerated Delta
+        values have been proposed to be accessed by reading raw Human Interface
+        Device (HID) data.  E.g.  WM_INPUT messages on windows, and USB device
+        apis on Mac / Linux.  The challenge here is interpreting and normalizing
+        the units to some consistent and specifiable scale.  Also, most APIs
+        considered to date are limited to USB devices.</p>
+
+        <p>It would be reasonable to consider adding these capabilities in the
+        future, as the currently specified mouse lock API would be easy to
+        continue to support if the finer grained delta and confinement features
+        were implemented.</p>
+
+        <p>The bundled API is selected for implementation practicality, because
+        the desired use cases are supported, and because it will not conflict with
+        future improvements as discussed here.</p>
+      </section>
+
+      <section>
+        <h2>High resolution deltas / High frequency updates?</h2>
+
+        <p>Not yet, for the same reasons in the previous Q.  See "Why bundle all
+        functionality (hiding cursor, providing mouse deltas) instead of using CSS
+        to hide the cursor, always providing delta values, and offering an API to
+        restrict the cursor movement to a portion of the webpage?" above.</p>
+      </section>
+
+      <section>
+        <h2>Why modify MouseEvent and reuse existing mouse events instead of
+        creating a mousedelta event?</h2>
+
+        <p>When under mouse lock many mouse events remain relevant, e.g.  click,
+        mousedown, etc.  These all share the same event data structure MouseEvent.
+        If movement data were reported via a new data structure then a new event
+        would be needed for reporting delta movement.  The new data structure
+        would have many parallels to MouseEvent to offer the same conveniences,
+        e.g.  button and modifier key states.  When handling click, down, and up
+        events would the existing mousedown, mouseup be used?  If so, they would
+        provide .clientX/Y and .screenX/Y with no useful data, but would lack the
+        convenience of containing the current movement data.  Or, new events would
+        also be required for when the moues is locked.</p>
+
+        <p>Also, movementX/Y are convenient even when the mouse is not locked.
+        This spec requires movement members to always be valid, even when the
+        mouse cursor exists.  This reduces code required to track the last cursor
+        state and mouseover/mouseout transistions if applications which to make
+        use of delta motion of the mouse.  This may be convenient even if the
+        mouse is not fully locked and the deficiencies of no locked target of
+        events, out of window, and screen borders clamping dat exist.</p>
+
+        <p>The only negative of adding movementX/Y to MouseEvent appears to be the
+        unused values in clientX/Y and screenX/Y when under mouse lock.  This does
+        not seem to be a significant problem.</p>
+
+        <p>Therefore the minimal change to add movementX/Y to MouseEvent is
+        selected to reduce API and implementation complexity.</p>
+      </section>
+
+      <section>
+        <h2>Why separate targets for mouse events under mouse lock and keyboard
+        input focus?</h2>
+
+        <p>Consider a game with a 3D view controlled by moving the mouse cursor,
+        while the user may still chat with other users via a text console.  It is
+        reasonable for the application to accept text input to an element that is
+        different than where mouse events are being dispatched.  This is similar
+        to preexisting behavior of receiving mousemove events over any element
+        while typing into a form on a page.</p>
+      </section>
+
+    </section>
+
     <section class='appendix informative'>
       <h2>Acknowledgements</h2>