[whatwg] Disabled attribute for iframes

[Neil Deakin]

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. 
I assume by 'handle' you mean a grabber element which is used to drag a 
larger element, much like a titlebar drags a window.
If so, you would just make the 'handle' draggable="true". That you are 
dragging the other element is just conceptual for the user. The 
setDragImage for instance could be set to the other element to make a 
drag feedback image

> 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.
>
>   
Is this related to the html5 drag and drop spec? It isn't clear from 
your earlier comment and this one. In the spec, mouse events don't fire 
at all during a drag. Implementations would fire dragover events in the 
parent or child frames as needed.

Dragging columns widths probably wouldn't be done using the html5 d&d, 
but instead would need a mouse capturing api as previously described.