[whatwg] Could we add setCapture to DOM Events?
Ian Hickson
ian at hixie.ch
Mon Nov 24 22:08:13 PST 2008
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 at 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list