W3C home > Mailing lists > Public > public-webevents@w3.org > October to December 2011

Re: Mouse Lock feedback

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Tue, 1 Nov 2011 07:39:03 -0700
Message-ID: <CADh5Ky1O9mhPOhR1o915yyATTLiCSNJ+vDmFJAkwS1XL6VuP6Q@mail.gmail.com>
To: Vincent Scheib <scheib@google.com>
Cc: public-webevents@w3.org, David Humphrey <david.humphrey@senecac.on.ca>
Looks pretty. Ship it! :)


On Mon, Oct 31, 2011 at 3:41 PM, Vincent Scheib <scheib@google.com> wrote:
> I've updated the spec based on this feedback.
> Raw diff:
> http://dvcs.w3.org/hg/webevents/log/e6b893606800/mouse-lock.html
> On Wed, Oct 26, 2011 at 5:20 PM, Vincent Scheib <scheib@google.com> wrote:
>> On Wed, Oct 26, 2011 at 11:40 AM, Dimitri
>> Glazkov <dglazkov@chromium.org> wrote:
>>> Hi all!
>>> Vincent was kind enough to share his most excellent spec
>>> (http://dvcs.w3.org/hg/webevents/raw-file/default/mouse-lock.html). I
>>> have a few questions/suggestions:
>>> 1) The case of cross-origin frame isn't handled properly with
>>> document.mouseLocked. We probably shouldn't return an element from a
>>> cross-origin frame, but returning nothing seems bad, too. Perhaps we
>>> should separate the queries of "is there a mouse lock in effect?" and
>>> "which node has the lock"?.
>> Good point.
>> Pending additional feedback:
>> - I will modify the spec to have only a bool returned from the function to
>> answer "is there a mouse lock in effect?".
>> - I will not create a new method to answer "which node has the lock?"
>> because it was a convenience only. Pages needing to track that information
>> are not expected to be common and they will be able to do so by storing the
>> current element in a variable upon lock success callback.
>>> 2) "mouse" seems too narrow. There's already a perfectly nice
>>> "pointer" term, which is used in pointer-events, and it appears much
>>> more inclusive of the newfangled touch pads and touch screens.
>> Given point 3 below I see a case for this.  Previously we stayed with
>> 'mouse lock' because that was the common name for the technique.
>>> 3) Putting the API on the document is misleading. There's only one
>>> pointer on the device, and you aren't really locking things per
>>> document. Also, the document is already a huge pile of methods and
>>> properties. Perhaps instead we should use Navigator as the right
>>> place? Something like this:
>>> navigator.pointer.lock(element, failureCallback, successCallback);
>>> navigator.pointer.unlock();
>>> navigator.pointer.isLocked();
>> On document vs navigator I don't have a strong opinion. We can move to
>> navigator if it is more appropriate. Either way the spec would make clear
>> that the API would have impact operating system wide.
>> Nesting the api in a member such as .pointer. feels good in that it
>> bundles it, no objections there.
>> I'm curious if anyone else has any opinions here?
Received on Tuesday, 1 November 2011 14:39:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:54 UTC