- From: Daniel Cheng <dcheng@chromium.org>
- Date: Wed, 1 Dec 2010 14:52:13 -0800
Couple of things I noticed after the changes to the DnD spec: - event.dataTransfer.types no longer mentions "Text" or "URL". Is this intentional? - Does the casing of "Text" and "URL" in the return value of event.dataTransfer.types matter? Daniel On Wed, Nov 17, 2010 at 13:05, Charles Pritchard <chuck at jumis.com> wrote: > On 11/16/2010 4:05 PM, Daniel Cheng wrote: > > On Tue, Nov 16, 2010 at 14:48, Charles Pritchard <chuck at jumis.com> wrote: > >> When interacting with non-DOM apps or pages, some platforms can't >>>> easily >>>> convert arbitrary MIME types to native data transfer types for >>>> copy/paste or DnD. For this reason, I think the spec should explicitly >>>> list MIME types for which UAs should handle the conversion to native >>>> data transfer types. A couple that come to mind: text/plain, >>>> text/uri-list, text/rtf, application/rtf, text/html, text/xml, >>>> image/png, and image/svg+xml. UAs can make a best-effort attempt to >>>> convert the other types, but it won't be guaranteed that they will be >>>> there for interaction with non-DOM applications. >>>> >>> I'm not sure what this means exactly. Could you elaborate? >>> >> >> I don't think these need to be "converted" by a UA -- the application >> which >> receives the data does that conversion on its own. >> >> This is a good use case for "promise"-based data callbacks. >> > > Automatic conversion is already implemented for some types (text, URL, > and maybe HTML). It's just not explicitly mentioned in the spec. I'm not > sure how a policy of no conversion would work; the clipboard > mechanism/encoding varies greatly from platform to platform. With no > automatic conversion, a page trying to read text from a drop would have to > first sniff the operating system, choose the appropriate strategy for > reading text, and then transcode the result to a DOMString. > > Daniel > > > Sorry, I completely misunderstood this one. I thought you were referring to > operations from the browser to the desktop. > > The UA could handle conversion to image/png. It's low-hanging fruit. > > Conversion from complex formats into markup is something that should be > handled by the non-DOM app, not the UA. > > Lacking decent markup conversion, a FileList is fine. I don't have to > "sniff" the operating system, > I just have to be determined on what mime types I'm going to support. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101201/3e10c8d5/attachment.htm>
Received on Wednesday, 1 December 2010 14:52:13 UTC