- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 08 Feb 2011 19:27:20 -0800
- To: Glenn Maynard <glenn@zewt.org>
- CC: Kenneth Russell <kbr@google.com>, robert@ocallahan.org, Brandon Andrews <warcraftthreeft@sbcglobal.net>, public-webapps@w3.org
- Message-ID: <4D520998.3050902@jumis.com>
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. -Charles
Received on Wednesday, 9 February 2011 03:27:50 UTC