W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

[clipboard events] Spec update

From: Hallvord R. M. Steen <hsteen@mozilla.com>
Date: Mon, 20 Jan 2014 17:55:39 -0800 (PST)
To: public-webapps <public-webapps@w3.org>
Message-ID: <1215288786.3460023.1390269339666.JavaMail.zimbra@mozilla.com>
I've just comitted a spec update with some significant changes. Please review and discuss..

Change #1: click-to-copy and click-to-cut
Yesterdays edits introduced a concept called "semi-trusted events" - in order to make script-initiated copy and cut operations "just work" if the script that initiates them is run in response to user input. See http://dev.w3.org/2006/webapi/clipops/clipops.html#semi-trusted-event 
Discussion that caused this change happened on the list and in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235

Change #2: more details (and tests for) the beforecopy, beforecut and beforepaste events. 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21696
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21697
Implementations that follow the spec will end up with a better implementation of before* events that what Internet Explorer has, thus exceeding the (low) expectations of web developers ;-)

Related note: the spec (and tests) already expects that the firing of copy/cut/paste events occurs irrespectable of any cursor/selection/editable context. So if a page with no cursor or selected text is open, and the user presses ctrl-c, a copy event is expected to fire. If user presses ctrl-x, a cut is expected to fire. The before* events are all about the state of UI controls, and have no impact or whether or not actual events fire. (AFAIK both Firefox and other teams have some work to do to make that happen as expected. We don't have the thought reading capability to fire beforecopy if the user thinks about pressing ctrl-c, so there's no way around that.)

Change #3 - no prior discussion, might be a bit controversial?
Synthetic (script-generated) paste events are now defined as causing paste actions. document.execCommand('copy'|'cut'|'paste') is now from the spec's point of view just a shortcut for generating and firing synthetic events.

There are two possible ways this works:
1) When creating synthetic clipboard events, the script can specify a data payload. For example, the default outcome of this script: 

var evt = new ClipboardEvent({data:'EHLO WORDL', dataType:'text/plain'})
document.getElementsByTagName('textarea')[0].dispatchEvent(evt)

would be to insert the text 'EHLO WORDL', as if pasted from the clipboard, into the textarea.

2) UAs may be configured to allow "scripted paste" operations. In this case, dispatching a paste event targeted at some element where data can be inserted (input/textarea/contenteditable etc.) will by default insert the clipboard data. However, if a data payload was specified for the event (as in the example above), that data will be used instead of clipboard data.

Is this a good change or a bad idea? Please discuss :-)

Known issue: the Editor's draft is not currently properly cross-linked with other specs, because I don't have a computer with Anolis set up handy right now. I'll fix this later. For the same reason, the ED doesn't have a proper inline table of contents.
-Hallvord
Received on Tuesday, 21 January 2014 01:56:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC