W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: Mouse Capture for Canvas

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 8 Feb 2011 22:18:16 -0500
Message-ID: <AANLkTik8e-7B-eyQ7uzmo39teph1duBfkTK4vK1ydi48@mail.gmail.com>
To: Kenneth Russell <kbr@google.com>
Cc: robert@ocallahan.org, Brandon Andrews <warcraftthreeft@sbcglobal.net>, public-webapps@w3.org
On Tue, Feb 8, 2011 at 8:54 PM, Kenneth Russell <kbr@google.com> wrote:

> > How would you satisfy that use-case without enabling abusive behavior by
> Web
> > sites?
>
> Per the proposal posted earlier and at
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 :
>
> 1. Only enable mouse capture in response to a user gesture (clicking
> on the element).
>

This proposal seems to say that mouse capture is enabled by adding an event
handler to an element.  I don't like this:

- It's a major break from the normal event model.  Merely defining an event
shouldn't cause side-effects.
- It permanently bakes the requirement that mouse capture can only happen in
response to a click into the API.  There are legitimate cases to capture the
mouse without first requiring a click.  Browsers may not want to allow this,
but if they can do so without causing abuse then it should be possible to do
so.

This is very similar to mouse capture at the OS level, where users needs to
be able to escape from misbehaving mouse-capturing applications.  It may be
worth comparing the interfaces used for that to see if they can be applied
to web apps.  Also note that as fullscreen and mouse capture often go
together, the "mouseover the top of the screen" mechanisms associated with
fullscreen won't work when both are enabled.  (I'm not a fan of that UI,
either, as they take over the top portion of the screen, preventing UIs from
putting menus there.)

For an API, I'd suggest simply adding "element.captureMouse()" and
"element.releaseMouse()", with events when the mouse is actually captured
and released.  Browsers can still choose to ignore captureMouse if not
called in response to a click, and the spec can require that at the start if
that's really wanted, but that behavior isn't baked permanently into the API
and could be relaxed later on.

Note that "mouse capture" may be the wrong name for this.  Mouse capture
usually refers to capturing mouse movement even when the mouse leaves the
window, usually to implement dragging--this is what IE's "mouse capture" API
is for.  This is different--the mouse cursor is typically hidden and locked
in place, so mouse motion never hits the boundaries of the screen and clicks
never go to another window.  It might be better to call this something else
to avoid confusion with regular mouse capture; I'd suggest "mouse grabbing".

-- 
Glenn Maynard
Received on Wednesday, 9 February 2011 03:18:48 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT