Could we add setCapture to DOM Events?

Web Apps WG,

Would it be possible to add setCapture() (as supported in IE; see below) 
to DOM3 Events? It seems more appropriate to have it there than in HTML5.

Note that I don't think we'd need releaseCapture(); we should just say 
that capture is canceled when the mouse is released if it was captured. 
This gets around the problem of unbalanced set/release.

On Thu, 14 Aug 2008, Greg Houston wrote:
> On Thu, Aug 14, 2008 at 6:14 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Thu, 14 Aug 2008, Greg Houston wrote:
> >>
> >> 1. You have a fluid layout where the columns are resizable via 
> >> javascript by dragging the borders. The content of one of the columns 
> >> is an iframe. You begin dragging the border between it and the column 
> >> to the left, but as soon as the cursor goes over the iframe, the 
> >> dragging functionality stops because you have now entered the context 
> >> of the iframe. Thus it becomes impossible or at the very least very 
> >> difficult to resize the column containing it.
> >
> > This seems like a bug. It seems like we would want to address this 
> > directly rather than requiring authors to disable iframes when doing 
> > drags (especially since that wouldn't help with things like plugins or 
> > whatever). Wouldn't the better solution be to provide some sort of 
> > mechanism to say that while the mouse button is down, all the mouse 
> > move events should go to the element that got the mousedown event?
> 
> That would probably work, though I don't know if limiting it to the 
> specific element itself might cause any issues. For instance, something 
> lacking in the HTML5 drag and drop specification is the ability to 
> define a handle for the element that is being dragged. With the drag and 
> drop in javascript libraries you can define a handle (a different 
> element) that drags the draggable element. If the handle 
> property/attribute is null then the element itself is it's own handle.
> 
> Perhaps there is a mousemove event in the current context (the parent 
> document let's say) that is checking to see if the user tries to drag an 
> object over it. We don't want to break the ability to create this sort 
> of collision detection.
> 
> It might be safer to say that while the mouse button is down, all the 
> mouse move events should be processed in the same "context" the 
> mousedown event occurred in. So if the mousedown occurs in the parent, 
> mouse move events should be processed in the parent until a mouseup 
> occurs. Likewise, if a mousedown occurs in the child iframe, mouse move 
> events should be processed in the child iframe until a mouseup occurs.
> 
> Yet there should also probably be some way to disable this or a way for 
> one context to release mouse ownership to another context. I did a 
> search for drag and drop between iframes, and there is at least one 
> application out there that can fake this:
> 
> http://intersoftpt.wordpress.com/2007/03/16/drag-and-drop-across-iframes/
> 
> Also, from a forum post on drag and drop between iframes:
>
>  "I have *heard* of people doing this by using the parent window to 
> store and mediate state between the 2 child iframe windows. So when a 
> drag was in progress, and the mouse coord reached the edge of the iframe 
> window, you would notify the other iframe to start listening for 
> mouseover events and create the illusion of a seamless "drag"."
> 
> In these cases you would probably want a way to change context during 
> mousedown, though the change should probably be controlled from the 
> context the mousedown occurred in. That context gets to decide if it 
> relinquishes control of the mouse move events before the mouseup or not. 
> By default it should not.

On Fri, 15 Aug 2008, Cameron McCormack wrote:
>
> The old SVG 1.2 Full draft had a pair of methods (which are implemented 
> in Batik), startMouseCapture()/ stopMouseCapture(), that could be used 
> to do this kind of thing.

On Fri, 15 Aug 2008, Ojan Vafai wrote:
> 
> setCapture/releaseCapture is how IE supports this. Seems to work well
> with iframes. It even deals with event coordinates in the expected way
> (e.g. clientX, clientY are relative to the document that the captured
> element is in instead of the document of the iframe).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 25 November 2008 06:21:44 UTC