Re: clipboard events

Siterer Dmitry Titov <dimich@chromium.org>:

> Sounds reasonable, and close to what IE and WebKit implement...

Thanks, it was meant to be :)

> Seems the clipboardData object may simply implement
> dataTransfer<http://dev.w3.org/html5/spec/dnd.html#the-datatransfer-interface>interface.
> This would give it legacy setData/getData as well as
> items <http://dev.w3.org/html5/spec/dnd.html#datatransferitems> list which
> can be used for blob-backed reads/writes.

Yes - as you've probably noticed the draft has an "issue"-type comment  
asking what the relationship to HTML5's DataTransfer should be. It  
would make sense to me to say that DataTransfer inherits  
setData/getData from a ClipboardData interface specified in the  
Clipboard Events spec, because one might want to support clipboard  
events on platforms/devices that have clipboard but not drag-and-drop  
capability. However, it doesn't really matter in what spec the details  
sit as long as it is specified somewhere. Perhaps it would be  
perceived as a somewhat pointless waste of editor time to request  
stuff removed from DataTransfer - I don't know. I might change my spec  
to say that ClipboardEvents support requires such-and-such from the  
HTML5 DataTransfer interface (without mandating support for the very  
DnD specific parts). get/setData() would still be covered in the  
spec's test suite (you may not have noticed the test suite because the  
tests are currently just in the source code of the spec - I have a  
script that extracts them, a small framework that runs them, and a  
pretty complete Watir script for automating all of them (using  
OperaWatir, but porting it should be trivial)).

Thoughts on what-spec-should-say-what?

> The list of formats that can be found in dataTransfer, although limited now,
> will probably grow in the future to enable better integration between
> applications ("XML Spreadsheet" or image for example). I can imagine a web
> app that wants to support copy/paste with popular products like MS Office...
> Many of those are not suitable for getData() that returns a string, because
> they are long/async in nature and/or binary. They will need to be
> transferred as blobs or files.

Received on Friday, 24 December 2010 13:48:03 UTC