Hi Art, slightly late response because I've been away. CCing public-webapps on this reply, in case anyone knows more that should be done.
> I would like to know your thoughts and plans for the Clipboard API spec. > Here's a short summary as I see it ... > > * The last publication of Clipboard API was February 2012 > > * I just ran a diff [1] and it indicates the spec hasn't changed much in > the last year True. > * Test suite: about 170 files > <http://dev.w3.org/cvsweb/2006/webapi/clipops/testsuite/>. Are these all > "good" and useful? I assume so - would be good if someone reviewed them I guess. The test suite is not quite complete either, though it mainly lacks coverage of certain corner cases like clipboard content with formatting that embeds other clipboard content. > * Bugs: no Bugzilla bug component but Tracker has two 4-year old Issues > ;-) <http://www.w3.org/2008/webapps/track/products/14>. Perhaps these > Tracker bugs be closed and a new Bugzilla component created? Issue 84 can be closed, it's resolved. 85 comes with a proposal for more granular security settings ( http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0685.html ) which I'm undecided about. > It would be nice to understand what needs to be done to get the spec to > Last Call. Plan: * Find a way to test the clipboard-content-that-embeds-other-clipboard-content scenario (do any other types of software even place such content on the clipboard?) and make sure the spec is sane. In practise, this is mainly about HTML content that embeds IMG not linking to a file:// or web URL. * Clarify the intention that document.execCommand() can be used to trigger real paste / copy actions (with due limitations for security and privacy reasons) - I think the spec fails to state this clearly enough * Remove the "cross-origin HTML paste sanitization algorithm" and all references to it (lacks implementation) * "Calling setData() without calling preventDefault() has no effect, even if there is no selection - the default action is to do nothing" - this is a rather silly gotcha.. It would be more user/dev-friendly if setData() or other manipulation automatically prevented the default action of copy.. * Consider if more MIME types need to be "mandatory", resolve the other issues noted in the spec. None of this is time-consuming (except maybe the first point) - just a few hours of work. -- Hallvord R. M. Steen Core tester, Opera Software
