On 11/16/2010 4:05 PM, Daniel Cheng wrote:
On Tue, Nov 16, 2010 at 14:48, Charles Pritchard <ch...@jumis.com
<mailto:ch...@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.
