Siterer Hallvord Reiar Michaelsen Steen <hallv...@opera.com>:
It would be nice to understand what needs to be done to get the spec to
Last Call.
I've checked in some changes. I guess we're getting there..
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.
Not done yet. Does anyone on this list know details of software that
places "complex" payloads on the clipboard? For example, if you in a
text editor makes a selection that includes an image, then copy - how
is the image described in the HTML part put on the clipboard? Does it
matter if image is loaded from a URL / from file / pasted?
* 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
Clarified, hope it's clear.
* Remove the "cross-origin HTML paste sanitization algorithm" and
all references to it (lacks implementation)
Killed.
* "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..
As this is already implemented I don't think we can change it although
I'd like to.
* Consider if more MIME types need to be "mandatory", resolve the
other issues noted in the spec.
Issues resolved or postphoned.
-Hallvord
