- From: Daniel Cheng <dcheng@google.com>
- Date: Tue, 16 Nov 2010 16:05:21 -0800
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 list of transfer types reminds me of all the redundancy that can take > place in a data transfer. > > A sufficiently large XML content file may be transferred in ~4 different > file formats > for compatibility with the destination. > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101116/5dadc79e/attachment.htm>
Received on Tuesday, 16 November 2010 16:05:21 UTC