[regularfry]

Please, please don't do this. By doing it you break UI conventions I can rely on everywhere else, and introduce yet another thing that's not quite going to work right in some combination of platform and browser.

You probably don't have the budget to make sure this works properly as you intend it everywhere it's accessible, and by introducing it you're actively making your site, and by extension my experience, less reliable and less predictable.

[sheetjs]

There is one case where I really do appreciate manipulating copy-paste: selecting multiple cells in a table.

Excel ends up populating the plaintext as well as the HTML paste buffers. The plaintext buffer holds TSV output and the HTML buffer holds the full HTML. The HTML is the only way to distinguish between the two cells

    |"foo|bar"|

and the single cell

    |"foo\tbar"| (using some CHAR magic in excel to generate the tab character)

my short spiel: http://blog.sheetjs.com/post/66908170192/the-magic-behind-ex...

[taye]

What if your site is a graphic editing web app using a <canvas> renderer? By convention users should be able to copy and paste graphical objects created within the app as well as paste text or images copied from elsewhere.

If you use keyboard short-cuts in your UI to copy into your app's memory but not the system clipboard then you have no way to know whether the data the user wants to paste was copied from your app or somewhere else. If you only use the system clipboard and inform the user that copy/pasting is done with right-click or key-combos and not the browser's "Edit" menu, you can handle copy-pasting predictably.

This was the most reliable method I could think of. Yes the browser's "Edit" menu is a problem and there's no way to get around that.