Re: [clipboard] kill onbefore* events?

On Mon, Mar 7, 2016 at 3:52 PM, Hallvord Reiar Michaelsen Steen <
hsteen@mozilla.com> wrote:

> 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.
>


Ah, I see that now. Yes, we should use "paste" and "cut" in those places.


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

That part was clear to me.


>
> 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.
>

The spec currently reads

'Within an editing host that is in the "events", "caret" or "typing" state,
cutting and pasting is disabled. However, `cut` and `paste` events are
still triggered.'


Is that sufficiently clear?


>
> > -- 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.
>
>
Sure, feel free to send in another PR and I will merge.


> > 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?


The way we currently have it is that any user initiated editing operation
triggers a beforeInput event with an inputType attribute specifying exactly
what type of change the user is asking for. For many operations this is is
in practice another event in addition to an already existing event
(keydown, etc.), but for actions there is no good event to listen to.

An exception up to this point was pasting/cutting -- for those we thought
we would only listen to the events you were working on in the clipboard API.

Now what the browser makers seem to have counted on is that the beforeInput
event is also triggered for cut and paste within both cE=true and the other
types of contenteditable. It would be a beforeInput event with the
inputType attribute set to "cut" or "paste".

And it doesn't seem like such an awful idea to me. For someone creating an
editor, it should in theory mean that they only have to listen to the
beforeInput event and based on that do all the required actions.

The "copy" event is something that works independently of editing hosts, so
I would think it should be triggered. "paste" and "cut" could possibly be
replaced by corresponding beforeInput events, but maybe you have other
reasons why that isn't such a good idea?


> 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..
>

Right, if there are good reasons to keep them, then we should keep them.

The browser makers at their meeting came up with a dataTransfer attribute
for this purpose [1]


>
> > 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.
>

I am not very set on the order of the events. The important thing is that a
script author must be able stop the paste/cut from happening by canceling
the beforeInput event. And the script author will need to have access to
the text that is to  be pasted in case of paste.

Btw, there also seems to be no opposition to the beforeInput event also
being triggered for textareas and input type=text in addition to the
various type of contenteditable. This ticket came out of the browser
meeting [2]



> 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?


We had a larger discussion on this at TPAC. There is a ticket to get
something like that [3].

It seems everyone agrees that there needs to be a way of enabling/disabling
these.

If this were only about copy/paste/cut, it would not be so problematic to
achieve this. The problem is that for now Safari -- and in the future
possibly other browsers -- has a large number of editing/formatting
commands that need to be enabled or disabled. And the issue with that is
this: If we have an opt-in model, one will have to write maybe 50 lines of
JavaScript just to get all the standard features Safari currently offers.
If we use an opt-out model, many editors will still need tow rite 50 lines
of JavaScript just to get the basic editor and secondly, if Safari decides
to add a new editing feature (say "crossed out text"), then suddenly every
user will be able to write in crossed out text on existing sites, those
texts will be saved to database and cause all kinds of problems further
down the road.




> -Hallvord
>

[1] https://github.com/w3c/editing/issues/106

[2] https://github.com/w3c/editing/issues/96

[3] https://github.com/w3c/editing/issues/93

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org