Re: [clipboard] kill onbefore* events?

Hi Johannes,
thanks for commenting here. It was recently brought to my attention in
a GitHub issue that using the term "before* events" was misleading as
it sounds like I also mean beforeInput when the clipboard spec is only
about beforecopy, beforecut and beforepaste. I think you may also have
misunderstood this phrase and apologise for the confusion caused.

Some clarifications inline below:


On Mon, Mar 7, 2016 at 2:50 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:

> --  We use beforePaste and beforeCut events for clipboard related actions
> and  beforeInput events for everything else. (At the time it wasn't clear
> whether beforeInput would be fired in contentEditable=true)

I've reviewed your spec and there is some minor confusion because it
seems you consider the beforecopy, beforecut, beforepaste events as a
sort of "intent events" analogous to beforeInput. They are not, they
are weirder than that. On the other hand, we don't really have a
problem here because the copy, cut and paste events *are* in practise
intent events - they inform the JS of the user's intent to copy, cut
and paste respectively.

When I propose dropping "before"-events from the clipboard spec I mean
only beforecopy, beforecut and beforepaste. Naturally beforeInput will
not be affected :)

With this in mind, I think we'll ask you to change a few small things
in your specs:

1) under contentEditable -  "context menu"
https://w3c.github.io/editing/contentEditable.html#context_menu the text says
"`beforepaste`, `beforecut` and `beforeinput` events SHOULD be triggered"
Change "beforecopy", "beforecut" and "beforepaste" to simply "copy",
"cut" and "paste" respectively.

2) If it is not clear from other parts of the text you may want to add
that pasting and cutting is not enabled for those editing hosts. The
clipboard API spec text will only do the "modify the DOM"-parts if
we're dealing with "an editing host where cutting is enabled" and
pasting respectively - this was indeed added to integrate better with
your cE=events text.

> -- We updated the execCommand spec according to the wishes of the Clipboard
> API people, but do in general only maintain that spec with minimal effort
> for as long as browser makers don't want to change their implementations
> according to a standardized spec.

I also have a small correction for that spec, it's just some text in a
non-normative note where it says about the paste command:

  "will only give access to the contents of the real clipboard if the event is
  dispatched from an event that is trusted and triggered by the user, or
  if the implementation is configured to allow this."

Here I suggest dropping the "dispatched from an event that is trusted
and triggered by the user" part - or at least change 'or' to 'and'. No
implementation will ever allow document.execCommand('paste') from a
user-triggered JS thread without further configuration.

> At the beginning of this year, the browser makers except Mozilla had an
> informal meeting about editing, and from what I gather, they did not know
> about this. So their proposals seems to include copy/paste in beforeInput
> and they have proposed another attribute to hold rich text content to be
> used for dragging/pasting.

Hm..? I don't know anything about this. No biggie, we'll figure this
out. What exactly do you mean by  "include copy/paste in beforeInput"
- that for example Ctrl-C according to their view should trigger not a
"copy" event but a "beforeInput" event? If anyone is arguing that it
seems a bit odd to me ;) And instead of a "drop" or "paste" event with
an event.dataTransfer or event.clipboardData property they suggest a
"beforeInput" event with inputType 'paste' and a brand new property to
carry a data payload? Again I'd be surprised if people really want to
reinvent those wheels..

> I am not sure what the best course of action is now. Given that beforeInput
> will fire also for contentEditable=true, it doesn't seem unreasonable to
> also have it work for paste/cut events.

I believe beforeInput will keep working fine with paste (and cut?) in
a cE=true context and run after the corresponding paste event when the
DOM is actually being modified. I don't think it makes sense to say
that copy/cut/paste events are replaced by "beforeInput
inputType=copy" etc in a cE=intents element - if for no other reason
that it will be a bit odd to require from script authors that they
listen to different events depending on whether an editing host is
TEXTAREA/cE=true or cE=events/caret/typing states.

Finally: we've been discussing how a JavaScript can enable the "copy",
"cut" and "paste" commands in the browser menus when they would
otherwise be disabled. For example, if you have a web app that
implements a custom "selected" state, that app wants to enable "copy"
and "cut" when something is "selected" even though there is no such
thing as a real text selection or an editing host. This usecase is in
fact what IE's old beforecopy/beforecut/beforepaste events were meant
to address. One of my ideas (for bikeshedding / discussion) is to add
a method like document.setCommandEnabledState('copy', true) or
document.setCommandState('copy', 'enabled').

Such a function would of course be analogous to the
document.queryCommandEnabled() stuff and should perhaps be maintained
in the same spec. Does the editing task force have any views on such a
suggestion?

-Hallvord

Received on Monday, 7 March 2016 14:53:16 UTC