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

Re: Mouse Capture for Canvas

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 08 Feb 2011 19:27:20 -0800
Message-ID: <4D520998.3050902@jumis.com>
To: Glenn Maynard <glenn@zewt.org>
CC: Kenneth Russell <kbr@google.com>, robert@ocallahan.org, Brandon Andrews <warcraftthreeft@sbcglobal.net>, public-webapps@w3.org
On 2/8/2011 7:18 PM, Glenn Maynard wrote:
> On Tue, Feb 8, 2011 at 8:54 PM, Kenneth Russell <kbr@google.com 
> <mailto: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.
window.open is another item that only fires during an event handle. I'm 
sure full screen is on that grounds.
Drag+drop does that.  [input type=file] is another.

User initiated events are part of the security model; and the current 
issues with mouse capture are about security.

> - 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.
Agreed, but I think it should still be tied to a user event.

> 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.
The way the current APIs are implemented, that makes sense. I think 
we're looking at extending it to more use cases.

> 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".

I for-the-first-time, hit this issue when looking at how screen 
magnifiers work.
The CSS 2D Transform (scale) allows really easy addition of basic screen 
magnification; but doing more complex things,
like grabbing the mouse, is not easy.

I hope the use case helps.

Received on Wednesday, 9 February 2011 03:27:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC