[whatwg] Disabled attribute for iframes

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.

- Greg

Received on Thursday, 14 August 2008 17:39:06 UTC