Greg Houston wrote:
On Thu, Aug 14, 2008 at 6:14 PM, Ian Hickson <[EMAIL PROTECTED]> 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.
