<br><br><div class="gmail_quote">On Sat, Jan 23, 2010 at 2:30 AM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Tue, 12 Jan 2010, Michael Davidson wrote:<br>
><br>
> The table in section 7.9.3 says that the DataTransfer object should be<br>
> empty for dragenter and dragover events.<br>
><br>
> Clearly this is not the case - the example in 7.9.1 shows that, at the<br>
> very least, the DataTransfer object needs to have a 'types' attribute so<br>
> that the drag handler can determine if it can accept the drag.<br>
<br>
I've tried to clarify what "empty" is supposed to mean here.<br>
<br></blockquote><div><br></div><div>Thanks, that makes sense for the status quo.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
> The issue that I'm having is that if the DataTransfer object says that<br>
> it has Files, I have no way to determine what type those files are. (In<br>
> this case, I only want to accept image files.) I understand that the<br>
> DataTransfer shouldn't have the content of the files for security<br>
> reasons, but it would be helpful if it did contain the file names and/or<br>
> MIME types.<br>
<br>
I could provide a second attribute with the types of the files, would that<br>
work? I suppose if we did this, we should remove the "Files" fake type.<br>
That might not be a bad idea in general, it's kind of a hack. I'm not sure<br>
how I feel about having multiple different ways of representing the data<br>
in a DataTransfer object... It would give a clean precedent for adding<br>
other features, though, like promises, which some people have requested.<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Another option is to throw an error if developers try to access forbidden attributes during dragenter/dragover.</div>
<div><br></div><div>Michael</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On Fri, 22 Jan 2010, Daniel Cheng wrote:<br>
><br>
> Two more questions about implementation details:<br>
><br>
> Cut/copy:<br>
> Does it make sense to fire a drag event at all? The spec says that drag<br>
> events should be fired at the source node every 350ms (presumably to allow<br>
> the source node to cancel a drag after it started), but a cut/copy takes<br>
> place "instantaneously".<br>
<br>
I've clarified the spec to say that the loop has to happen immediately and<br>
then only repeat every 350ms if it's still active.<br>
<br>
<br>
> If drag events should be fired during cut/copy, should the clipboard be<br>
> restored to its original state if the drag event is cancelled? It would<br>
> make sense, but might make implementations more complicated.<br>
<br>
The idea is for the cut/copy to be done exactly as if it was a drag to a<br>
hypothetical clipboard window, meaning everything happens in the "drop"<br>
part, so yes.<br>
<br>
<br>
> Paste:<br>
> It seems like there is no time a dragleave event would ever fire. A paste<br>
> essentially goes through the drag and drop loop once; the only possible<br>
> transition is for the current target element to go from null to non-null.<br>
<br>
The 'dragleave' event can fire during a paste if the drag is canceled.<br>
<font color="#888888"><br>
--<br>
Ian Hickson U+1047E )\._.,--....,'``. fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a> U+263A /, _.. \ _\ ;`._ ,.<br>
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'<br>
</font></blockquote></div><br>