[clipboard] kill onbefore* events?
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")
The use case these events were meant to fulfil is described here: w3c.github.io/clipboard-apis/#determining-ui-state
In short: they allow you to tell the UA to enable copy/cut/paste commands even when they would normally be disabled.
Killing them doesn't sound like the right course of action. We would have to come up with another API so we can have an alternative to what before cut/copy/paste do.
Why can't we fire these events regardless of content editability and do actual editability check during the execution of the execcommands?
--grisha
Sent from Outlook[http://aka.ms/weboutlook](http://aka.ms/weboutlook)
On Thu, Feb 4, 2016 at 2:43 AM, Grisha Lyukshin glyuk@microsoft.com wrote: >
Killing them doesn't sound like the right course of action. We would have to come up with another API so we can have an alternative to what before cut/copy/paste do.
True, it's a use case we should handle.
Options:
automagically enable commands if there are corresponding event listeners (Opera Presto model)
- Pros: "just works", no extra APIs, page authors don't need to learn nor do anything extra
- Cons: registering event listeners is not "supposed to" have side effects, W3C specs are not "supposed to" go into UX territory, web apps may want to sometimes leave the commands disabled after all when it doesn't make sense to execute them
Add a new API method like document.setCommandEnabled('paste', false)
- Pros: Simpler and more straightforward than the onbefore* event-based model, can be integrated with queryCommandEnabled(), gives web apps fine grained control of when to enable/disable stuff
- Cons: I think the editing spec people are trying to move away from those legacy document. commands and may not be celebrating the opportunity of adding a new one.. Also, we don't really want to let sites disable these commands at will - we want them to enable them when it makes sense but not disable* them when the UA would otherwise enable them, to prevent nuisance and "copyright protection"-style abuse.
Are there any other options?
Why can't we fire these events regardless of content editability and do actual editability check during the execution of the execcommands?
That's the plan :) - the spec requires the browser to fire a paste event if the user for example presses ctrl-v regardless of whether the context can handle a paste or not. However, the menu command state (and thus the user's actual ability to trigger the command any other way than by shortcut keys) would depend on the onbefore* handling or some equivalent API we'd have to invent. Or the magic solution ;) -Hallvord R
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 w3c/clipboard-apis#16 and for example lists.w3.org/Archives/Public/public-editing-tf/2015Aug/0001.html
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"
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?
On Thu, Feb 4, 2016 at 1:52 PM, Hallvord Reiar Michaelsen Steen hsteen@mozilla.com wrote:
On Thu, Feb 4, 2016 at 2:43 AM, Grisha Lyukshin glyuk@microsoft.com wrote: >
Killing them doesn't sound like the right course of action. We would have to come up with another API so we can have an alternative to what before cut/copy/paste do.
True, it's a use case we should handle.
Options:
automagically enable commands if there are corresponding event listeners (Opera Presto model)
- Pros: "just works", no extra APIs, page authors don't need to learn nor do anything extra
- Cons: registering event listeners is not "supposed to" have side effects, W3C specs are not "supposed to" go into UX territory, web apps may want to sometimes leave the commands disabled after all when it doesn't make sense to execute them
Add a new API method like document.setCommandEnabled('paste', false)
- Pros: Simpler and more straightforward than the onbefore* event-based model, can be integrated with queryCommandEnabled(), gives web apps fine grained control of when to enable/disable stuff
- Cons: I think the editing spec people are trying to move away from those legacy document. commands and may not be celebrating the opportunity of adding a new one.. Also, we don't really want to let sites disable these commands at will - we want them to enable them when it makes sense but not disable* them when the UA would otherwise enable them, to prevent nuisance and "copyright protection"-style abuse.
It has been proposed to have something like this to enable/disable actions from extra menus (clipboard actions in most cases, but safari also adds several menus for formatting such as bold/italic/font size/font type/etc.
Without engaging in the discussion about execCommand again, in my experience/view, the browser provided execCommand is currently unusable for just about all editing operations (but required to operate with the clipboard api). This seems to be the general view of all those JavaScript developers creating editors, whereas some people working on the browser side have a different view of this.
So based on the view of these JavaScript-people, the main usecase for being able to disable actions is to make the extra menus go away if their editor doesn't support a particular editing operation. First priority is really to be able to remove all those menus. Second possibly "all menus except clipboard". Especially on mobile devices these are a major problem currently, as they gte in the way of things.
In the view of those who think execCommand can be used for most editing operations, the main usecase would be to turn a particular action on or off.
So in either case there is an argument for being able to turn them off. However, I am not sure it is such a good idea to have to turn of for example "paste" just to make a context menu go away.
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" w3c.github.io/editing/contentEditable.html#context_menu the text says "
beforepaste,beforecutandbeforeinputevents 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] w3c/editing#106
[2] w3c/editing#96
[3] w3c/editing#93
On Mon, Mar 7, 2016 at 12:49 PM, Johannes Wilm johannes@fiduswriter.org
wrote:
On Mon, Mar 7, 2016 at 3:52 PM, Hallvord Reiar Michaelsen Steen hsteen@mozilla.com wrote:
>
On Mon, Mar 7, 2016 at 2:50 PM, Johannes Wilm johannes@fiduswriter.org wrote:
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.
Agreed. That is the major benefit of 'beforeinput' and 'input' -- you will receive a 'beforeinput' event just before any DOM update (with an option to cancel it), and you'll also receive an 'input' event just after the DOM was updated. If you want to track all DOM updates, then you only need to listen to these two events.
Other events could also be sent before/after the DOM is updated, but it's better to avoid sending events around needlessly. FWIW, this is why 'keypress' was deprecated -- there's no need for it since its functionality is covered by 'beforeinput'.
I don't know the details and subtleties of the cut and paste events, but it would be great if they could coordinate with (or be folded into) 'beforeinput'. Especially since a 'beforeinput' event should be sent before the cut/paste DOM update occurs in any case. But the issues with 'copy' and the formatting commands that Johannes mentions would need to be addressed.
On Mon, Mar 7, 2016 at 11:00 PM, Gary Kacmarcik (Кошмарчик) garykac@chromium.org wrote:
On Mon, Mar 7, 2016 at 12:49 PM, Johannes Wilm johannes@fiduswriter.org wrote:
>
On Mon, Mar 7, 2016 at 3:52 PM, Hallvord Reiar Michaelsen Steen hsteen@mozilla.com wrote:
>
On Mon, Mar 7, 2016 at 2:50 PM, Johannes Wilm johannes@fiduswriter.org wrote:
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.
Agreed. That is the major benefit of 'beforeinput' and 'input' -- you will receive a 'beforeinput' event just before any DOM update (with an option to cancel it), and you'll also receive an 'input' event just after the DOM was updated. If you want to track all DOM updates, then you only need to listen to these two events.
Correct - two rather than one. I was thinking of a European-language text editor that would handle every possible editor operation itself. it would only need to listen to the beforeinput event. An editor using IME or letting the browser take care of part of the editing operations will also need to listen to the input event. At any rate, it's not more than two events.
Other events could also be sent before/after the DOM is updated, but it's better to avoid sending events around needlessly. FWIW, this is why 'keypress' was deprecated -- there's no need for it since its functionality is covered by 'beforeinput'.
I don't know the details and subtleties of the cut and paste events, but it would be great if they could coordinate with (or be folded into) 'beforeinput'. Especially since a 'beforeinput' event should be sent before the cut/paste DOM update occurs in any case. But the issues with 'copy' and the formatting commands that Johannes mentions would need to be addressed.
To me this sounds good. But maybe the clipboard api people have objections?
On Mon, Mar 7, 2016 at 11:00 PM, Gary Kacmarcik (Кошмарчик) garykac@chromium.org wrote:
Agreed. That is the major benefit of 'beforeinput' and 'input' -- you will receive a 'beforeinput' event just before any DOM update (with an option to cancel it), and you'll also receive an 'input' event just after the DOM was updated. If you want to track all DOM updates, then you only need to listen to these two events.
In my personal (and humble) opinion it's not actually a benefit for developers to have only one event that will fire a lot and indicate lots of different things. I accept that library authors want a convenient "point of overview" regarding what happens in the DOM (but wasn't mutation observers supposed to do that job?). However, making one single event type carry lots of different information and adding stuff like clipboardData and/or dataTransfer (because drag-and-drop changes the DOM too, right?) to the InputEvent interface seems like we force authors to
1) Write code with lots of if(e.eventType === foo) and switch(e.eventType) branching, which is hard to read 2) Debug code that gets run a lot all the time - event loops that fire often are annoying when debugging
My five cents..
On Wed, Mar 9, 2016 at 2:29 PM, Hallvord Reiar Michaelsen Steen hsteen@mozilla.com wrote:
In my personal (and humble) opinion it's not actually a benefit for developers to have only one event that will fire a lot and indicate lots of different things. I accept that library authors want a convenient "point of overview" regarding what happens in the DOM (but wasn't mutation observers supposed to do that job?). However, making one single event type carry lots of different information and adding stuff like clipboardData and/or dataTransfer (because drag-and-drop changes the DOM too, right?) to the InputEvent interface seems like we force authors to
1) Write code with lots of if(e.eventType === foo) and switch(e.eventType) branching, which is hard to read 2) Debug code that gets run a lot all the time - event loops that fire often are annoying when debugging
I strongly agree with this. We should not design another XMLHttpRequest readystatechange event disaster.
On Wed, Mar 9, 2016 at 2:29 PM, Hallvord Reiar Michaelsen Steen hsteen@mozilla.com wrote:
On Mon, Mar 7, 2016 at 11:00 PM, Gary Kacmarcik (Кошмарчик) garykac@chromium.org wrote:
Agreed. That is the major benefit of 'beforeinput' and 'input' -- you will receive a 'beforeinput' event just before any DOM update (with an option to cancel it), and you'll also receive an 'input' event just after the DOM was updated. If you want to track all DOM updates, then you only need to listen to these two events.
In my personal (and humble) opinion it's not actually a benefit for developers to have only one event that will fire a lot and indicate lots of different things. I accept that library authors want a convenient "point of overview" regarding what happens in the DOM (but wasn't mutation observers supposed to do that job?).
Mutation observers look at actual changes in the DOM (for any reason).
The beforeinput event looks at the user's intention of changing something, before the DOM is changed. The script can then take that information and do whatever changes to the DOM that are needed.
In another setup, where one lets the browser do parts of the DOM changing, the input event combined with the beforeinput event can let the script know what the user intention was + what changes were made to the DOM based on that intention. This may be helpful if the script needs to record this change or make some additional changes to the DOM.
Just using mutation observers, one can see the change that was made, but doesn't really know what the user's intentions were, right?
However, making one single event type carry lots of different information and adding stuff like clipboardData and/or dataTransfer (because drag-and-drop changes the DOM too, right?) to the InputEvent interface seems like we force authors to
The browser meeting also came up with the suggestion that drag-and-drop should have a beforeinput event [1].
1) Write code with lots of if(e.eventType === foo) and switch(e.eventType) branching, which is hard to read 2) Debug code that gets run a lot all the time - event loops that fire often are annoying when debugging
What's your proposed alternative? That one creates a three event listeners for the clipboard events + one for beforeInput that covers most other operations + maybe one for drag and drop? I don't see how that be easier to debug or read, at least on the JavaScript side of things.
My five cents.. -Hallvord
[1] w3c/editing#107
On Wed, Mar 9, 2016 at 5:29 AM, Hallvord Reiar Michaelsen Steen hsteen@mozilla.com wrote:
On Mon, Mar 7, 2016 at 11:00 PM, Gary Kacmarcik (Кошмарчик) garykac@chromium.org wrote:
Agreed. That is the major benefit of 'beforeinput' and 'input' -- you will receive a 'beforeinput' event just before any DOM update (with an option to cancel it), and you'll also receive an 'input' event just after the DOM was updated. If you want to track all DOM updates, then you only need to listen to these two events.
In my personal (and humble) opinion it's not actually a benefit for developers to have only one event that will fire a lot and indicate lots of different things. I accept that library authors want a convenient "point of overview" regarding what happens in the DOM (but wasn't mutation observers supposed to do that job?). However, making one single event type carry lots of different information and adding stuff like clipboardData and/or dataTransfer (because drag-and-drop changes the DOM too, right?) to the InputEvent interface seems like we force authors to
1) Write code with lots of if(e.eventType === foo) and switch(e.eventType) branching, which is hard to read 2) Debug code that gets run a lot all the time - event loops that fire often are annoying when debugging
Yes, that's one of the trade-offs that needs to be considered when designing these APIs.
There is a design tension between the 2 extreme approaches, each with pros and cons:
(1) A single 'beforeinput' event that fires for all "input" activities. Pros: Developers only need to support this and don't worry about the details. Basic support for new input types just work without additional work. Cons: Developers that care only about a particular type need to filter out the other event types.
(2) Separate events for each type of input activity. Pros: Developers that care about specific event types can easily catch the cases they care about. Cons: Developers have to explicitly add support for each event type if they want to catch all input.
(Hybrid approaches are also possible: add some more specific events + a generic catch-all, but that means a lot more events are being sent.)
There are issues with either approach: (1) Problem with single event: Anne mentioned XMLHttpRequest readystatechange as an example of going too far down the path with a generic "something-happened" event. (2) Problem with separate events: Many developers didn't support composition events because their native language didn't use them, so parts of the web were broken for CJK users. We don't want similar things to happen for voice or accessibility (or other) inputs. Note that this is part of the reason why 'keypress' was deprecated.
Personally, I'm more concerned about developers forgetting to add (or not knowing they need to add) support for uncommon things like IMEs, voice and accessibility, than I am about a developer sometimes needing to write a bit of extra code to filter out things they're not immediately interested in. The latter is an inconvenience for the developer, but the former breaks part of the web for some users.
Just using mutation observers, one can see the change that was made, but doesn't really know what the user's intentions were, right?
I guess so, haven't used them for anything. Perhaps the "after the fact" nature was a design flaw in Mutation Observers.
The browser meeting also came up with the suggestion that drag-and-drop should have a beforeinput event [1].
I'd prefer not..
1) Write code with lots of if(e.eventType === foo) and switch(e.eventType) branching, which is hard to read 2) Debug code that gets run a lot all the time - event loops that fire often are annoying when debugging
What's your proposed alternative?
My suggestion would be to use the existing stuff for clipboard and DnD: a developer with a cE=events editing host who is interested in enabling paste should listen to paste events. If she wants to enable DnD she should listen to drop events. And of course a beforeInput listener for the stuff that beforeInput does best.
That one creates a three event listeners for the clipboard events + one for beforeInput that covers most other operations + maybe one for drag and drop? I don't see how that be easier to debug or read, at least on the JavaScript side of things.
Easier to read because there's less if() branching and switch() statements.
Easier to debug because if you want to debug pasting, you ask your debugger to break on a paste event. No scanning through lots of code in a code base you may not even know to find the right beforeInput method sub-branch to break on. Not breaking on beforeInput and striving to trigger a paste without doing anything else that will trigger the breakpoint set on an event that fires for quite a few things. (Ever tried to debug a problem in a mousemove event handler? I have..more than once.)
Using more narrowly scoped events for those things that require special payloads or API just seems a lot better. I actually think you should push back a bit against the browser devs who seem to think beforeInput is the perfect hammer for anything that might or might not resemble a nail..
(I'm responding to some of Gary's points in the next reply on this thread below)
On Wed, Mar 9, 2016 at 11:19 PM, Gary Kacmarcik (Кошмарчик) garykac@chromium.org wrote:
1) Write code with lots of if(e.eventType === foo) and switch(e.eventType) branching, which is hard to read 2) Debug code that gets run a lot all the time - event loops that fire often are annoying when debugging
Yes, that's one of the trade-offs that needs to be considered when designing these APIs.
I agree it's a trade-off - in other words we're discussing shades of grey.
There is a design tension between the 2 extreme approaches, each with pros and cons:
(1) A single 'beforeinput' event that fires for all "input" activities. Pros: Developers only need to support this and don't worry about the details. Basic support for new input types just work without additional work.
I don't see how this logic holds if you add something like beforeInput for paste. Suppose that I already wrote a beforeInput - based editor. Suppose it's pretty good at handling the events I already know - I've carefully implemented typing, deletion etc based on beforeInput events. Now all of a sudden a modern browser is sending me beforeInput with eventType set to "paste" and with an event.clipboardData property I'd have to pull data from to insert into the DOM to make the paste work. How is that something that will "just work" in my app? It clearly won't.
Cons: Developers that care only about a particular type need to filter out the other event types.
<X>
(2) Problem with separate events: Many developers didn't support composition events because their native language didn't use them, so parts of the web were broken for CJK users. We don't want similar things to happen for voice or accessibility (or other) inputs. Note that this is part of the reason why 'keypress' was deprecated.
But the same thing can easily happen with a single-event model where developers (naturally) "filter out" event types they believe they are not interested in.. If four years from now browsers start sending me "beforeInput" of type "voiceRecognition" I may have written lots of code handling all the other already known input types and my app is going to be broken when used with voice.
Now, of course I think the idea here is to up the semantic value of the events so you get "this text is being inserted" semantics (even for voice..) that's easy to handle compared to a "those keys were pressed and we have a number that might look like a key you think you know but might not and we won't tell you more" semantics of keypress. But that's sort of independent of the question of whether to have a single-event or multiple-events model. If you really want to be backwards compatible you could spell out the letters of the words from voice recognition and send keydown/up/press and good, old input and change events.. wonder if we're actually going to go there when we get that far ;)
Personally, I'm more concerned about developers forgetting to add (or not knowing they need to add) support for uncommon things like IMEs, voice and accessibility, than I am about a developer sometimes needing to write a bit of extra code to filter out things they're not immediately interested in. The latter is an inconvenience for the developer, but the former breaks part of the web for some users.
What if those options do not correspond to the two alternatives we're discussing? :) You might see something I don't, but I think we're conflating a few issues here.
On Wed, Mar 9, 2016 at 3:40 PM, Hallvord Reiar Michaelsen Steen hsteen@mozilla.com wrote:
On Wed, Mar 9, 2016 at 11:19 PM, Gary Kacmarcik (Кошмарчик) garykac@chromium.org wrote:
There is a design tension between the 2 extreme approaches, each with pros and cons:
(1) A single 'beforeinput' event that fires for all "input" activities. Pros: Developers only need to support this and don't worry about the details. Basic support for new input types just work without additional work.
I don't see how this logic holds if you add something like beforeInput for paste. Suppose that I already wrote a beforeInput - based editor. Suppose it's pretty good at handling the events I already know - I've carefully implemented typing, deletion etc based on beforeInput events. Now all of a sudden a modern browser is sending me beforeInput with eventType set to "paste" and with an event.clipboardData property I'd have to pull data from to insert into the DOM to make the paste work. How is that something that will "just work" in my app? It clearly won't.
Unless the beforeinput event is canceled, the DOM will be updated without
any special handling. Most webapps don't need to do anything to support
typing, deletion, et al, and they wouldn't need to do anything to support
paste. A rich editing app may need/choose to do extra work, but pasting
into a regular <input type="text"> should work without any extra effort.
Consider beforeinput (as it replaces keypress):
beforeinputevent is sent with key info. If I ignore it, the DOM will be updated with the key value, if I cancel it, it doesn't. If the programmer does nothing, key presses just work.
Now a paste action happens:
beforeinputevent is sent with the paste data (just in case the app wants to do something with it). If ignored, the DOM will be updated, If canceled, the DOM won't be updated. If the programmer does nothing, pasting just works.
Now a brand-new-event-that-updates-the-DOM is sent:
- Same thing.
beforeinputevent is sent. DOM is updated (or not, if canceled). It just works.
In fact, that's pretty much how the Clipboard API spec says the 'paste' event should work:
7.1.3 The paste action
If the cursor is in an editable element, the paste action will insert
clipboard data in the most suitable format (if any) supported for the given context.
This means that it updates the DOM, which means that a beforeinput event
needs to fire. And if we're firing a cancelable beforeinput event, then
there's no point also sending a paste event that does basically the
thing. This is the exact same situation that we had with keypress and it
was deprecated in favor of beforeinput.
On Thu, Mar 10, 2016 at 12:40 AM, Hallvord Reiar Michaelsen Steen hsteen@mozilla.com wrote:
Just using mutation observers, one can see the change that was made, but doesn't really know what the user's intentions were, right?
I guess so, haven't used them for anything. Perhaps the "after the fact" nature was a design flaw in Mutation Observers.
The browser meeting also came up with the suggestion that drag-and-drop should have a beforeinput event [1].
I'd prefer not..
1) Write code with lots of if(e.eventType === foo) and switch(e.eventType) branching, which is hard to read 2) Debug code that gets run a lot all the time - event loops that fire often are annoying when debugging
What's your proposed alternative?
My suggestion would be to use the existing stuff for clipboard and DnD: a developer with a cE=events editing host who is interested in enabling paste should listen to paste events. If she wants to enable DnD she should listen to drop events. And of course a beforeInput listener for the stuff that beforeInput does best.
For us JavaScript people this alternative would be a few more lines of code, but not impossible to handle.
I think this is mostly for the browser people to come to an agreement about.
That one creates a three event listeners for the clipboard events + one for beforeInput that covers most other operations + maybe one for drag and drop? I don't see how that be easier to debug or read, at least on the JavaScript side of things.
Easier to read because there's less if() branching and switch() statements.
You mean in the JavaScript code? Well, it will be maybe three-four event more event handlers and then maybe 25 cases in the beforeInput/input event handler.
Either way will work, but I don't think either one will be much less or more code than the other. Also if I just wanted to listen to for example "paste", "insertCharacter" and "deleteForward" or soem other subset, it doesn't seem very hard handler to create the correct switch statement.
Easier to debug because if you want to debug pasting, you ask your debugger to break on a paste event. No scanning through lots of code in a code base you may not even know to find the right beforeInput method sub-branch to break on. Not breaking on beforeInput and striving to trigger a paste without doing anything else that will trigger the breakpoint set on an event that fires for quite a few things. (Ever tried to debug a problem in a mousemove event handler? I have..more than once.)
I assume you are here thinking of the debugging issues it gives in the browser code. This I know nothing about.
In the JS code I cannot see why this wouldn't be solveable by filtering through the events with a switch and then just debugging the part of the code that is executed for a specific action.
Using more narrowly scoped events for those things that require special payloads or API just seems a lot better. I actually think you should push back a bit against the browser devs who seem to think beforeInput is the perfect hammer for anything that might or might not resemble a nail..
:)
I think it will work for us JS-ppl either way. The most important is that the browser-people come to an agreement.
The beforeinput approach makes it slightly easier to just listen to one event and learn all about that and have all the edit types in just one document, rather than having to hunt down all the different events in different documents and never being entirely sure all user intentions are really handled.
The separate events approach may mean that this is implemented faster because the clipboard and drag/drop events don't have to be changed (right?)
I can ask around the different editor developers, but it seems to me that this likely isn't an issue any of the JS editor people would want to fight with any of the browser people.
So it would be good if Firefox could come to an agreement with the other browser developers. Also, it would be good if Firefox could be represented at the next Editing Taskforce meeting. I sent aa proposal out to our mailinglist a few days ago of having the next meeting around May/June and then perhaps TPAC.
On Thu, Mar 10, 2016 at 2:24 AM, Gary Kacmarcik (Кошмарчик) garykac@chromium.org wrote:
On Wed, Mar 9, 2016 at 3:40 PM, Hallvord Reiar Michaelsen Steen hsteen@mozilla.com wrote:
>
On Wed, Mar 9, 2016 at 11:19 PM, Gary Kacmarcik (Кошмарчик) garykac@chromium.org wrote:
There is a design tension between the 2 extreme approaches, each with pros and cons:
(1) A single 'beforeinput' event that fires for all "input" activities. Pros: Developers only need to support this and don't worry about the details. Basic support for new input types just work without additional work.
I don't see how this logic holds if you add something like beforeInput for paste. Suppose that I already wrote a beforeInput - based editor. Suppose it's pretty good at handling the events I already know - I've carefully implemented typing, deletion etc based on beforeInput events. Now all of a sudden a modern browser is sending me beforeInput with eventType set to "paste" and with an event.clipboardData property I'd have to pull data from to insert into the DOM to make the paste work. How is that something that will "just work" in my app? It clearly won't.
Unless the
beforeinputevent is canceled, the DOM will be updated without any special handling.
Gary is thinking of the usecase where the beforeinput event is used in cE=true, it seems. Hallvord was possibly thinking of cE=intentions/events?
Most webapps don't need to do anything to support typing, deletion, et al, and they wouldn't need to do anything to support paste.
Ok, as for that last sentence "Most webapps don't need to do anything to support typing, deletion, et al, and they wouldn't need to do anything to support paste." I think our experiences wit that are vastly different, and I was actually wondering if the Gmail or Microsoft Office 365 developers would have any opinion about that.
In my experience, I kind of need to override almost everything, or at least make checks about where the caret is before something is changed before I decide to let the browser handle it.
At any rate, our differences in experience doesn't seem to mean that we reach different conclusions.
Having the editor do something new, such as "voice input" all by itself is not something I would think work either.
But that's precisely why the beforeinput event would come in handy: Say a user uses version 4.35 of my editor from spring 2017. It supports all the known beforeinput events at that time.
Three months later, Apple announces the immediate availability of a new version of Safari with an unstandardized "voice input" eventType, while I am off scuba diving for 6 weeks.
Once I get back to work, I will start to program a version 5.0 of my editor that handles the new eventtype correctly.
Anyone still not having upgraded from version 4.35, the editor doesn't end up doing crazy/uncontrolled stuff when receiving voice input. It simply does nothing on voice input because the switch statement has no case-definition for it and I made sure that any unknown eventType results in no changes to the DOM.
And that's good. I can go scuba dive without having to panic. The alternative is that I would have to constantly watch out whether there are new ways of inputting things, and if so, cancel my holiday, do 24 hour shifts and update my editor really quickly to listen and handle the new event, and pressure all site administrators into updating their installations really fast. Sounds like a nightmare.
On Thu, Mar 10, 2016 at 4:23 AM, Johannes Wilm johannes@fiduswriter.org wrote:
Once I get back to work, I will start to program a version 5.0 of my editor that handles the new eventtype correctly.
Anyone still not having upgraded from version 4.35, the editor doesn't end up doing crazy/uncontrolled stuff when receiving voice input. It simply does nothing on voice input
That's sort of the polar opposite of Gary's goal that new stuff should "just work" :)
It also means that you do not consider it a goal of your spec development to make it easier to handle stuff the developer hasn't explicitly thought of - like IMEs, accessibility helpers and possible future input stuff - in a way that would have a chance of "just working"?
I'd consider it a brilliant technological achievement if voice input fired key insertion beforeInput events (and potentially keydown/up/press - why not? /me <3 back compat :-p) and your app "just worked" with the new Apple device while you were scuba diving (and more importantly: on the 10 000 sites that never bothered updating to the new version of your JS lib at all).
Anyway - however much fun we can have imagining the future, this discussion is sort of off-topic when we're arguing whether to replace specialised paste and drop events with a general beforeInput eventType=paste and eventType=drop approach.
Johannes also wrote:
Easier to read because there's less if() branching and switch() statements.
You mean in the JavaScript code? Well, it will be maybe three-four event more event handlers and then maybe 25 cases in the beforeInput/input event handler.
25 cases is a lot :)
Easier to debug because if you want to debug pasting, you ask your debugger to break on a paste event.
I assume you are here thinking of the debugging issues it gives in the browser code. This I know nothing about.
Not meant as boasting but just to explain where I'm seeing things from: I've been debugging random issues on random websites for the last 14 years or so, usually working on code I have not had the luxury of prior knowledge of, I've been dissecting heavily obfuscated code at least since GMail hit the web. 25+ cases inside one event handler inside an obfuscated script is hard. 25+cases inside a non-obfuscated script still means you might have to step over quite a few statements to get to the code you want to see running.
In the JS code I cannot see why this wouldn't be solveable by filtering through the events with a switch and then just debugging the part of the code that is executed for a specific action.
Browser people who advocate for this solution should be tasked with creating a usable debugger UI for this :) Most debuggers already have UI for breaking on a specific event type. This is a solved problem. None have UI for creating conditional breakpoints on a specific event type AFAIK - not saying it can't be done, but it's harder.
On Thu, Mar 10, 2016 at 10:50 AM, Hallvord Reiar Michaelsen Steen hsteen@mozilla.com wrote:
On Thu, Mar 10, 2016 at 4:23 AM, Johannes Wilm johannes@fiduswriter.org wrote:
Once I get back to work, I will start to program a version 5.0 of my editor that handles the new eventtype correctly.
Anyone still not having upgraded from version 4.35, the editor doesn't end up doing crazy/uncontrolled stuff when receiving voice input. It simply does nothing on voice input
That's sort of the polar opposite of Gary's goal that new stuff should "just work" :)
It also means that you do not consider it a goal of your spec development to make it easier to handle stuff the developer hasn't explicitly thought of - like IMEs, accessibility helpers and possible future input stuff - in a way that would have a chance of "just working"?
I just don't think this is technically possible for any editing action to "just work" in all the different editors that all work extremely differently. We have to interrupt just about every other user action, including simple things such as hitting the space bar, backspace/delete, or making bold. But whether or not it's feasible for browsers to just provide this functionality or not is an everlasting argument that we don't need to reach a conclusion for here.
And lets say that you guys are right and voice input happens to "just work": the editor developers will enable it, run their 2000-10000 automatic tests and if everything just works fine, I am sure they will enable it immediately in their production version and push out an update ASAP. After all there are several editors out there, so there is no reason to have any less features than any of the others.
I am sure if any of you browser people were off scuba-diving and a major library you depend on would change and give the user new ways of communicating with the application comes out, you would want to test building your browser with it, and not just automatically have it be bundled and shipped to the entire world.
I'd consider it a brilliant technological achievement if voice input fired key insertion beforeInput events (and potentially keydown/up/press - why not? /me <3 back compat :-p) and your app "just worked" with the new Apple device while you were scuba diving (and more importantly: on the 10 000 sites that never bothered updating to the new version of your JS lib at all).
indeed, brilliant. But not necessarily possible.
Anyway - however much fun we can have imagining the future, this discussion is sort of off-topic when we're arguing whether to replace specialised paste and drop events with a general beforeInput eventType=paste and eventType=drop approach.
The idea is here to argue whether or not it is a good idea to give the script author a "guarantee" that the beforeinput event will carry all user intentions about changes to a contenteditable element.
Of course we can also say: clipboard and drag/drop events stay as they are, but all future editing events will get a beforeinput event. That would be more or less the same type of guarantee. It would just be slightly more inconsistent.
Johannes also wrote:
Easier to read because there's less if() branching and switch() statements.
You mean in the JavaScript code? Well, it will be maybe three-four event more event handlers and then maybe 25 cases in the beforeInput/input event handler.
25 cases is a lot :)
Easier to debug because if you want to debug pasting, you ask your debugger to break on a paste event.
I assume you are here thinking of the debugging issues it gives in the browser code. This I know nothing about.
Not meant as boasting but just to explain where I'm seeing things from: I've been debugging random issues on random websites for the last 14 years or so, usually working on code I have not had the luxury of prior knowledge of, I've been dissecting heavily obfuscated code at least since GMail hit the web. 25+ cases inside one event handler inside an obfuscated script is hard. 25+cases inside a non-obfuscated script still means you might have to step over quite a few statements to get to the code you want to see running.
my respect. Obfuscated code is a mess.
On Thu, Mar 10, 2016 at 10:50 AM, Hallvord Reiar Michaelsen Steen hsteen@mozilla.com wrote:
On Thu, Mar 10, 2016 at 4:23 AM, Johannes Wilm johannes@fiduswriter.org wrote:
Once I get back to work, I will start to program a version 5.0 of my editor that handles the new eventtype correctly.
Anyone still not having upgraded from version 4.35, the editor doesn't end up doing crazy/uncontrolled stuff when receiving voice input. It simply does nothing on voice input
That's sort of the polar opposite of Gary's goal that new stuff should "just work" :)
It also means that you do not consider it a goal of your spec development to make it easier to handle stuff the developer hasn't explicitly thought of - like IMEs, accessibility helpers and possible future input stuff - in a way that would have a chance of "just working"?
I'd consider it a brilliant technological achievement if voice input fired key insertion beforeInput events (and potentially keydown/up/press - why not? /me <3 back compat :-p) and your app "just worked" with the new Apple device while you were scuba diving (and more importantly: on the 10 000 sites that never bothered updating to the new version of your JS lib at all).
The beforeInput inputType works no matter what the input device is (different from keydown/up/press). So if a new input device can use the existing inputTypes (for a new type of key input that works by letting the camera read hand gestures), then it will indeed just "work" even though I am still scuba-diving.
The problematic part comes up when new inputTypes were used -- the fact that a new inputType was used indicates that the existing inputTypes couldn't cover what was needed. A type of "voice control" may have very new and different ways of trying to change existing text, where a new command "ah... sorry, computer..." may mean to remove the last 3-4 words.
In the cases where a new inputType was used, in the editors that I know, I think the JS developers would prefer to cancel those entirely until they have tested them out. But if another JS editor developer is more confident that his editor will be able to just handle it right, she could just let the browser handle any inputType unknown to her code.
Want more features?
Request early access to our private beta of readable email premium.
- Go to Source
# Hallvord Reiar Michaelsen Steen (a month ago)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] bugzilla.mozilla.org/show_bug.cgi?id=596764
-Hallvord R