On Thu, 27 Jan 2011 05:12:58 +0900, Daniel Cheng <dch...@chromium.org>
wrote:
Platform capabilities vary.
- Windows will be unhappy if you use up all the custom clipboard formats
(~65535 or so). There is no way to release formats once registered.
- Mac uses UTIs which are strings but not MIME types.
- GTK+ seems to support arbitrary MIME types.
So for push support, Windows will be unable to natively support arbitrary
string types.
Thanks. Do you think it is OK to say that we allow arbitrary strings but
it may not be available on all platforms, and recommend that script
authors stick to known MIME types?
When pulling data from the clipboard, I wonder if it may also be a bad
idea
to expose all the native types. I was working on a patch to do this in
WebKit, and it turns out some of the native types leak information about
filesystem paths when files are involved in the dragging/paste operation.
Do you remember any further details? Seems like something we should
mention but I don't know how.
* There is not yet a clear way to push multi-part or alternate formats
to
the OS clipboard from JS. To use something like iCal, I guess best
practise
would be to push one human-readable text/plain string for target
software
without iCal support, and one alternate entry in iCal format. I guess
that
can be done with
DataTransferItem add(in DOMString data, in DOMString type);
I.e. spec for copy event would be
* default action: copy any document selection
* if default action is prevented: push data in drag data store (as
manipulated by setData() or items.add()) to clipboard, probably mapping
certain known values to native clipboard formats while doing so.
If the default action is prevented and no data was added to the drag data
store, does that imply the clipboard should be cleared?
No, that sounds like it should be a no-op to me. Does the spec now imply
otherwise?
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
