[whatwg] Drag-and-drop feedback
Ian Hickson
ian at hixie.ch
Thu Apr 8 15:58:13 PDT 2010
On Fri, 5 Feb 2010, Roland Steiner wrote:
>
> Since I am currently in the process of fixing bugs in this area for
> Chrome, there are 2 things I'm wondering about:
>
> .) 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.
For now .types shouldn't ever have Text and URL, since they get converted
to MIME types. In practice, it's unlikely that a text/uri-list option will
have no URLs. I agree that this was a bad design choice, though.
> .) Judging from the example in
> https://developer.mozilla.org/En/DragDrop/Drag_Operations#drop , 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.
> 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).
I recommend just following whatever the text/uri-list spec says.
> .) should dragged files be converted to file URLs and returned in a call to
> getData("text/uri-list") or getData("URL")?
Exposing file: URLs seems like a bad idea, since that exposes privacy-
sensitive information like the file path... I would recommend not doing
this.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list