Re: [clipboard events] Spec update

I'm eager to replace our flash clipboard bridge with this native api.

Would this be the correct code to write a string to the clipboard on a
button click?

  document.getElementById("copytoclipboard").addEventListener("click",
function() {
    var event = new ClipboardEvent('paste', {data: 'COPIED!',
dataType: 'text/plain'});
    document.dispatchEvent(event);
  });

On Mon, Jan 20, 2014 at 7:55 PM, Hallvord R. M. Steen
<hsteen@mozilla.com> wrote:
> 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 02:53:24 UTC