- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 11 Aug 2011 23:54:09 -0700
- To: Vincent Scheib <scheib@google.com>
- Cc: Klaas Heidstra <klaas1988@gmail.com>, "Robert O'Callahan" <robert@ocallahan.org>, Brandon Andrews <warcraftthreeft@sbcglobal.net>, Olli@pettay.fi, "Tab Atkins Jr." <jackalmage@gmail.com>, Ryosuke Niwa <rniwa@webkit.org>, Adam Barth <w3c@adambarth.com>, "Gregg Tavares (wrk)" <gman@google.com>, Glenn Maynard <glenn@zewt.org>, Charles Pritchard <chuck@jumis.com>, Kenneth Russell <kbr@google.com>, public-webapps@w3.org
On Thu, Aug 11, 2011 at 7:27 PM, Vincent Scheib <scheib@google.com> wrote: > Re Rob: >> Is there a need to provide mouse-locking on a per-element basis? It seems >> to >> me it would be enough for mouse-locking to be per-DOM-window (or >> per-DOM-document) and deliver events to the focused element. This >> simplifies >> the model a little bit by not having to define new state for the >> "mouse-locked element". Or is there a need for mouse-lock motion events to >> go to one element while keyboard input goes elsewhere? > > I may need to clarify the specification to state that there is only a single > state of mouse lock global to the user agent. You may be suggesting that the > MouseLockable interface be added to only the window and not to all elements? > An argument was made that multiple elements may attempt a mouseLock, > especially in pages composing / aggregating content. If so, it would be > undesirable for an unlockMouse() call on one element to disrupt a lock held > by another element. I will update the spec to explain that decision. If you > were suggesting something else, I didn't follow you. But if the mouseLock API was only available on the Document object, then everyone would call it there and there would be no interference between aggregated content. As soon as the lock was granted, anyone that had requested it would be notified. / Jonas
Received on Friday, 12 August 2011 06:55:06 UTC