"messing with the clipboard" is not exactly what is intended, for sure! And messing with the clipboard did happen in some leak-full versions of the MSIE API, which made it quite unstable: any web page could read the clipboard then which is now recognized as fully wrong. All contemporary specifications of a web-page-enhanced clipboard transfer, I believe, now take in account that the *standard gesture* is the only one expected to be used by the user to copy and only then could help the user by adjusting the content and the association between types and map before this gets written to the clipboard. A user expecting a near-desktop experience in a web-application that provides many services will find it normal that his clipboard is full of... useful data. E.g. that a web-based SVG editor puts a PDF variant into it so that he can paste that into his word-processing desktop application. paul Le 15-juin-10 à 04:37, David Booth a écrit : >>>> The ability to manipulate what a user is copying is also important >>>> for applications on the Web. If you're using a Web app like Google >>>> Docs, you want copy to copy a useful representation, not the >>>> internal representation that the editor uses. > So perhaps the question should be rephrased as asking whether a > *website* should be able to control copy and paste, rather than > whether > *javascript* should permit it. Just as some operations are safe and > others are unsafe, and unprivileged websites should not be permitted > to > perform unsafe javascript operations, it seems to me that the > ability to > mess with the copy buffer should be considered an unsafe (privileged) > javascript function. > Actually, even the ability of a website to observe copy *events* seems > to me like an invasion of privacy.
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:34 UTC