Tim Berners-Lee wrote:
Definitely agreed. Charles has set that a full-fledged-clipboard specification was thought as version 2, trying to get version 1 as soon as possible out with (almost?) IE and Safari compatibility. I'm afraid that this means the clipboard is limited in content-types (URL, text, I fear).There is a lot of architecture in the clipboard.I think it is important that the WebAPI clipboard is very web architecture compatible.
Desktop clipboards, like HTTP, have concepts of type negotiation.
Definitely!
It would be logical to make the clipboard type in WebAPI carry content-typeI always thought the clipboardData to be a map associating mime-types to data... extending this is not an issue I believe.[and later negotiate it].
I wonder, however if the copy-and-paste or drag-and-drop negotiation wouldn't take advantage of being more HTTP-like. E.g., the current architectures I know do not say anything about the recipient and provider application names... whereas this is a classical http header.
paul
Setting and getting the data to be transferredInternet Explorer provides 3 methods for the clipboardData and dataTransfer objects:setData()This takes one or two parameters. The first must be set to either 'text' or 'URL' (case-insensitive).getData()This takes one parameter, that allows the target to request a specific type of data.clearData() This clears the data from the object.
smime.p7s
Description: S/MIME Cryptographic Signature
