[whatwg] Drag-and-drop feedback

[Michael Davidson]

On Sat, Jan 23, 2010 at 2:30 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 12 Jan 2010, Michael Davidson wrote:
> >
> > The table in section 7.9.3 says that the DataTransfer object should be
> > empty for dragenter and dragover events.
> >
> > Clearly this is not the case - the example in 7.9.1 shows that, at the
> > very least, the DataTransfer object needs to have a 'types' attribute so
> > that the drag handler can determine if it can accept the drag.
>
> I've tried to clarify what "empty" is supposed to mean here.
>
>
Thanks, that makes sense for the status quo.


>
> > The issue that I'm having is that if the DataTransfer object says that
> > it has Files, I have no way to determine what type those files are. (In
> > this case, I only want to accept image files.) I understand that the
> > DataTransfer shouldn't have the content of the files for security
> > reasons, but it would be helpful if it did contain the file names and/or
> > MIME types.
>
> I could provide a second attribute with the types of the files, would that
> work? I suppose if we did this, we should remove the "Files" fake type.
> That might not be a bad idea in general, it's kind of a hack. I'm not sure
> how I feel about having multiple different ways of representing the data
> in a DataTransfer object... It would give a clean precedent for adding
> other features, though, like promises, which some people have requested.
>
>
Multiple different ways to get the same info doesn't seem great, but it
doesn't matter to me as long as the information is available.

Another option is to throw an error if developers try to access forbidden
attributes during dragenter/dragover.

Michael



>
> On Fri, 22 Jan 2010, Daniel Cheng wrote:
> >
> > Two more questions about implementation details:
> >
> > Cut/copy:
> > Does it make sense to fire a drag event at all? The spec says that drag
> > events should be fired at the source node every 350ms (presumably to
> allow
> > the source node to cancel a drag after it started), but a cut/copy takes
> > place "instantaneously".
>
> I've clarified the spec to say that the loop has to happen immediately and
> then only repeat every 350ms if it's still active.
>
>
> > If drag events should be fired during cut/copy, should the clipboard be
> > restored to its original state if the drag event is cancelled? It would
> > make sense, but might make implementations more complicated.
>
> The idea is for the cut/copy to be done exactly as if it was a drag to a
> hypothetical clipboard window, meaning everything happens in the "drop"
> part, so yes.
>
>
> > Paste:
> > It seems like there is no time a dragleave event would ever fire. A paste
> > essentially goes through the drag and drop loop once; the only possible
> > transition is for the current target element to go from null to non-null.
>
> The 'dragleave' event can fire during a paste if the drag is canceled.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100125/ff55737c/attachment-0002.htm>