Re: Copy to Clipboard - ambush and abuse by javascript

Roy T. Fielding wrote:
 > On Jun 4, 2010, at 7:27 PM, L. David Baron wrote:
 >
 >> On Wednesday 2010-06-02 16:22 -0700, Roy T. Fielding wrote:
 >>> While I support the notion of not messing with the cut buffer
 >>> for UI sanity (i.e., allowing this is a browser bug), I think
 >>> it is pointless to argue about this tool as a legitimate means
 >>> of copy control.
 >> I don't think it's reasonable to expect browsers to enforce user
 >> expectations on copying given a "malicious" Web page.  There are a
 >> large number of ways to hide text, such as positioning it offscreen,
 >> using a very small font size, making it alternate content for a
 >> small image, positioning other content on top of it, etc.  And we
 >> certainly still want to allow copying of text that's offscreen so
 >> users can copy large pieces of text.
 >
 > Yes, I don't see a problem with copying what has been selected,
 > even if it is difficult to see the entire selection.

Yes.

 >> 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.  If you're copying
 >> data from a spreadsheet that auto-formats numbers by inserting
 >> commas every three digits in the displayed value, you may well want
 >> to copy the value without the displayed commas that are not really
 >> part of the data, just part of the display.
 >
 > No, actually, those are all incorrect.  You want to copy the original
 > with all of its marked-up richness,

Roy, I'm in almost complete agreement with the other things you've 
written in this thread, but not quite with this, since it appears not to 
account for the traditional behavior of the clipboard APIs on platforms 
like Windows.  Those APIs encourage the presentation of multiple formats 
by the copy function, and likely at most one of those is "native" to the 
copying application.

What I would agree with, and perhaps this is what you meant, is that 
it's good practice for the copying application to supply and give 
priority to native and/or high fidelity formats, perhaps along with 
others.  Consider a spreadsheet program.  It might well be reasonable 
for it to offer all of the following when a range of cells is copied:

* The native format of the program.  This might or might not be 
proprietary, and perhaps likely to be of use only to other copies of the 
same program.

* High fidelity renderings in more widely-used spreadsheet formats, 
perhaps Excel, and maybe 1-2-3

* Rich text table

* HTML table

* CSV

* Plain text

 > and then you want the paste
 > function(s) to choose how to interpret that content based on the
 > context in which it is pasted.

Maybe.  Let's say you are pasting into a smart HTML editor that happens 
to recognize all the above formats, including the native program formats 
or maybe the Excel format. It's an interesting tradeoff whether you'd 
likely do better with your suggestion, in which the HTML editor would 
look at the spreadsheet data to extract HTML, or whether it might be 
better to trust the HTML conversion provided by the spreadsheet copy 
function.  I certainly don't think it's bad for the spreadsheet to offer it.

Noah

Received on Sunday, 6 June 2010 20:12:11 UTC