- From: Paul Libbrecht <paul@activemath.org>
- Date: Tue, 28 Feb 2006 14:37:01 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Web APIs WG <public-webapi@w3.org>
Why is this an issue to prevent this ? Accessiblity ? After all, the provider of the page is the provider of the script... or ? paul Maciej Stachowiak wrote: > > > On Feb 27, 2006, at 4:34 PM, Jonas Sicking wrote: > >> Maciej Stachowiak wrote: >>> I would like copy/paste integration to be on the agenda. I believe >>> these operations can be offered securely (and implemented in various >>> nonstandard ways by IE, Firefox and in some cases Safari): >>> 1) copy >>> 2) cut (in an editable context) >>> 3) event on copy that lets you prevent the default action and >>> substitute other content >>> 4) event on paste that lets you prevent the default action and >>> substitite other content >> >> An issue with 1-3 is that a site could stop the user from copying >> content off the site. We already see a similar thing happening where >> sites cancel the rightclick event to prevent users from doing "view >> source". >> >> A site could use the copy-event in 3 to always replace the copied >> contents with an empty string (or a string containing some copyright >> statement). Or the site could on every key-press and mouse-click >> cut/copy an empty string to the clipboard. > > I think this is only an issue with #3 (unless you think sites will > spin in a loop doing a copy on an empty selection, I think this is > unlikely). However, IE already has these features. Perhaps we can come > up with something compatible that doesn't make it possible to totally > lock out the user. Or perhaps the copy end is not as important as the > paste end for substituting custom content. Maybe it is enough to just > allow adding extra clipboard types, and not overriding of standard ones. > > Regards, > Maciej > > >
Received on Tuesday, 28 February 2006 13:37:14 UTC