Re: [clipboard] kill onbefore* events?

Hey,
last year we discovered that Hallvord and the others working on the
Clipboard API were working on similar things as what we were doing in the
editing taskforce with contentEditable=intentions/caret and the beforeInput
event. But we were working on it from two different  sides. The division
was something like this:

- The editing taskforce felt that execCommand wasn't useful at all as it it
currently is, and there is no reasonable way to get execCommand to be both
useful for JS-based editor sand standardized in browsers in the next 20
years, the main path forward was to listen to the beforeInput event and
handle everything else in JavaScript, and not to work much on trying to
standardize execCommand or contentEditable=true.

- The clipboard API people saw execCommand as the foundation of text
editing on the web and they worked on getting the clipboard-related parts
of execCommand up to date. Their main idea was that the browser should
ensure standardized behavior by enforcing that paste, cut, etc. MUST be
executed in an editable environment.


Eventually we came to a compromise agreement, which looked somewhat like
this [1]:

--  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)
-- The Clipboard API document was updated so that the forced changes to the
DOM that paste/cut will trigger in contentEditable=true do not apply to
other types of contenteditable such as cE=intentions that do not update
thje DOM by default.
-- 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.
-- We no longer call execCommand=true or execCommand "deprecated" but
instead added a longer text to these specs that reflect the current and
likely future status of these specs. The exact wording was negotiated
between all relevant parties.

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.


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.



[1] See for example https://github.com/w3c/clipboard-apis/issues/16 and for
example
https://lists.w3.org/Archives/Public/public-editing-tf/2015Aug/0001.html

On Tue, Feb 2, 2016 at 11:48 PM, Gary Kacmarcik (Кошмарчик) <
garykac@chromium.org> wrote:

> I'm not very familiar with onbefore{cut|paste|copy}, but they sound like
> very specialized versions of the beforeinput event.
>
> What do these events provide that you don't get from handling beforeinput?
> (well, other than the upcoming context "I'm about to do a cut/paste/copy")
>
> On Tue, Feb 2, 2016 at 2:00 PM, Hallvord Reiar Michaelsen Steen <
> hsteen@mozilla.com> wrote:
>
>> Hi,
>> there's some scepticism about implementing
>> onbeforecut/onbeforepaste/onbeforecopy in Gecko [1], IE's implementation
>> seems considerably more limited than I expected (maybe because of bugs?),
>> and it doesn't really seem like an elegant solution to the use case it is
>> meant to solve.
>>
>> Would anybody mind if we killed those events?
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=596764
>>
>> -Hallvord R
>>
>
>


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