[whatwg] Disabled attribute for iframes
enndeakin at gmail.com
Thu Aug 14 17:56:05 PDT 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
>>> 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
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.
More information about the whatwg