Quick correction/addendum: FireFox seems to be actually fine with CRLF as line separator in setData("text/uri-list", data) and will return only the first URL within data on getData("URL"). However, it doesn't seem to return files as URLs with getData("text/uri-list"), which I guess would be my third question:<div>

<br></div><div>.) should dragged files be converted to file URLs and returned in a call to getData("text/uri-list") or getData("URL")?</div><div><br><div><br></div><div>- Roland<br><br><div class="gmail_quote">

On Fri, Feb 5, 2010 at 4:34 PM, Roland Steiner <span dir="ltr"><<a href="mailto:rolandsteiner@google.com">rolandsteiner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><br></div><div>Since I am currently in the process of fixing bugs in this area for Chrome, there are 2 things I'm wondering about:</div><div><br></div><div>.) whether "Text" and "URL" should be part of the return value of "types" (probably not, according to Ian's comment). However, since "text/uri-list" may in fact not contain a valid URL, the presence/absence of "URL" in types could be useful. I.e., it could indicate whether getData("URL") will return something useful.</div>


<div><br></div><div>.) Judging from the example in <a href="https://developer.mozilla.org/En/DragDrop/Drag_Operations#drop" target="_blank">https://developer.mozilla.org/En/DragDrop/Drag_Operations#drop</a> , Firefox seems to use only LF for line feeds within text/uri-list, while RFC 2483 calls for CR-LF for all "text/*" formats, including "text/uri-list", as does the HTML5 spec in the section on the drag-and-drop processing model. </div>


<div>Since the UA has to parse "text/uri-list" for the return value of "URL", I wonder whether both should be accepted (break on LF, filter out any CR). The other problem here is that WebKit/Safari and Chromium convert files to file URLs to return for "text/uri-list"/"URL". Is there a consensus how this difference should be best handled (or is this just a bug in FF)?</div>


<div><br></div><div><br></div><div>Cheers,</div><div><br></div><font color="#888888"><div>Roland</div></font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Thu, Feb 4, 2010 at 11:29 AM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch" target="_blank">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">Webkit and Firefox are case-sensitive. IE only does "TEXT" and "URL", but<br>
case-insensitively (at least for Text, I didn't test URL). Chrome is<br>
case-insensitive for everything.<br>
<br>
Tough call. I guess we'll go with just converting everything to lowercase,<br>
so that it's case-insensitive.<br>
<br>
BTW I noticed Chrome includes "Text" and "URL" in the .types list. That's<br>
incorrect according to the spec.<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>
</div></div></blockquote></div><br></div></div>