Re: Mouse Lock feedback

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?
>
>
>