- From: Paul Libbrecht <paul@activemath.org>
- Date: Tue, 28 Feb 2006 21:49:59 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Web APIs WG <public-webapi@w3.org>
But we are talking about web-application, right ? At least presuming the provider of such an application is sane and somewhat trusted of value, it would replace the copy capability only when it makes sense and with something that makes sense. The same would be true for change of selection btw... it only makes sense to impact it when it makes sense. As long as we wish to stick to a single copy operation... it's a no-go... there's no way for a web-application to provide the added-value of a custom copy (which is sensible in many cases!). I would go the following way: - suppose the way a provider does it is sensible and let it be the default copy (and drag, and cut) operation. - allow an extra copy menu-item which "reverts to a trusted way" and is not impactable by webapp providers. How does it sound ? paul Maciej Stachowiak wrote: > On Feb 28, 2006, at 5:37 AM, Paul Libbrecht wrote: >> Why is this an issue to prevent this ? >> Accessiblity ? >> After all, the provider of the page is the provider of the script... >> or ? > It is annoying for users to be prevented from taking normal actions > like using the standard context menu or copying text from the page. We > get a lot of complaints about letting pages block the context menu, I > am sure if they started blocking the copy command it would be much worse.
Received on Tuesday, 28 February 2006 20:50:16 UTC