Re: [whatwg] oninput for contentEditable
On Sat, 28 Aug 2010 03:16:16 +0200, Ojan Vafai o...@chromium.org wrote: WebKit has added the input event to contentEditable nodes. That part of this proposal seemed non-controversial. Do other browser vendors support changing the description of this event to apply to contentEditable nodes as well? Yeah, seems like a good idea. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] oninput for contentEditable
WebKit has added the input event to contentEditable nodes. That part of this proposal seemed non-controversial. Do other browser vendors support changing the description of this event to apply to contentEditable nodes as well? Ojan On Wed, Jun 16, 2010 at 5:33 PM, Ojan Vafai o...@chromium.org wrote: I've started a parallel discussion re: textInput on www-dom. http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.html On Wed, Jun 16, 2010 at 5:13 PM, Ojan Vafai o...@chromium.org wrote: We've given this a bit more thought and come the the conclusion that textInput basically does what we want out of beforeInput, except that it doesn't currently fire for actions like undo/redo. So, basically, we're proposing that textInput should fire for any DOM modifying event and, ideally, that it would be renamed beforeInput. The one exception is for IME input. beforeInput/textInput wouldn't fire for each composition update due to technical limitations of the Mac platform. There's a thread about this on www-dom already. Not sure exactly how to navigation this discussion as textInput is currently in the DOM3 spec and input is in the HTML5 spec. Ojan On Tue, Mar 16, 2010 at 6:35 PM, Ojan Vafai o...@chromium.org wrote: On Wed, Mar 3, 2010 at 6:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: So I have to ask... Why are events _before_ the edit needed? If we add these, then you have to define what happens when those event handlers modify the state of the DOM in arbitrary ways, including carrying out operations that spin the event loop, operations that make the edit that's about to happen nonsensical, and so forth. It's a huge chunk of spec and implementation complexity. So I'd like to see some very compelling use cases to even consider it. Here's a couple use-cases off the top of my head: Google Wave: They keep a model of the content separate from the html contents of the contentEditable region. In order to make that work, for every user-action, they need to either mimic what the browser did or cancel the default browser behavior and perform that action themselves. In both cases, having a beforeinput event makes the code much more sane, less brittle and often more performant. In the case where they want to cancel the default browser behavior (e.g. undo/redo), they get the beforeinput event, cancel it and then do their thing. Without beforeinput, they need to wait for the action to happen and then either make sense of the changes to the DOM, or undo the changes and reapply their own changes. Those both lead to brittle and, in some cases, expensive code. In the case where they want to let the browser perform it's default action, having the beforeinput event allows them to properly bookend a user-action and know with confidence that they've correctly handled it. Instead, they currently have very complex and brittle logic listening to every event under the sun in order to make sure they catch every possible user-action. Typing at the beginning/end of links: Another more general use-case is needing to modify the DOM before the user-action occurs. This comes up often when typing at the beginning/end of a link (or otherwise special inline element). Different apps want different behavior (e.g. should the text inserted go inside the link or after it). Currently, controlling that behavior is really difficult. You need to capture every time the selection changes and mess with the DOM/selection appropriately to get the text inserted in the right place. In theory, you *could* do this with just the input event, but that would get you back into reverse engineering whatever the user-action was, which is again brittle and difficult to get right. Is that a bit more convincing with respect to the need for a beforeinput event? beforeinput aside, are you in support of extending the input event to contentEditable elements and adding the data/action attributes? Any thoughts from Opera developers? Anne, your previous comments on this thread make it sound like you support this and would consider adding it to Opera? Ojan
Re: [whatwg] oninput for contentEditable
We've given this a bit more thought and come the the conclusion that textInput basically does what we want out of beforeInput, except that it doesn't currently fire for actions like undo/redo. So, basically, we're proposing that textInput should fire for any DOM modifying event and, ideally, that it would be renamed beforeInput. The one exception is for IME input. beforeInput/textInput wouldn't fire for each composition update due to technical limitations of the Mac platform. There's a thread about this on www-dom already. Not sure exactly how to navigation this discussion as textInput is currently in the DOM3 spec and input is in the HTML5 spec. Ojan On Tue, Mar 16, 2010 at 6:35 PM, Ojan Vafai o...@chromium.org wrote: On Wed, Mar 3, 2010 at 6:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: So I have to ask... Why are events _before_ the edit needed? If we add these, then you have to define what happens when those event handlers modify the state of the DOM in arbitrary ways, including carrying out operations that spin the event loop, operations that make the edit that's about to happen nonsensical, and so forth. It's a huge chunk of spec and implementation complexity. So I'd like to see some very compelling use cases to even consider it. Here's a couple use-cases off the top of my head: Google Wave: They keep a model of the content separate from the html contents of the contentEditable region. In order to make that work, for every user-action, they need to either mimic what the browser did or cancel the default browser behavior and perform that action themselves. In both cases, having a beforeinput event makes the code much more sane, less brittle and often more performant. In the case where they want to cancel the default browser behavior (e.g. undo/redo), they get the beforeinput event, cancel it and then do their thing. Without beforeinput, they need to wait for the action to happen and then either make sense of the changes to the DOM, or undo the changes and reapply their own changes. Those both lead to brittle and, in some cases, expensive code. In the case where they want to let the browser perform it's default action, having the beforeinput event allows them to properly bookend a user-action and know with confidence that they've correctly handled it. Instead, they currently have very complex and brittle logic listening to every event under the sun in order to make sure they catch every possible user-action. Typing at the beginning/end of links: Another more general use-case is needing to modify the DOM before the user-action occurs. This comes up often when typing at the beginning/end of a link (or otherwise special inline element). Different apps want different behavior (e.g. should the text inserted go inside the link or after it). Currently, controlling that behavior is really difficult. You need to capture every time the selection changes and mess with the DOM/selection appropriately to get the text inserted in the right place. In theory, you *could* do this with just the input event, but that would get you back into reverse engineering whatever the user-action was, which is again brittle and difficult to get right. Is that a bit more convincing with respect to the need for a beforeinput event? beforeinput aside, are you in support of extending the input event to contentEditable elements and adding the data/action attributes? Any thoughts from Opera developers? Anne, your previous comments on this thread make it sound like you support this and would consider adding it to Opera? Ojan
Re: [whatwg] oninput for contentEditable
On Wed, Mar 3, 2010 at 6:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: So I have to ask... Why are events _before_ the edit needed? If we add these, then you have to define what happens when those event handlers modify the state of the DOM in arbitrary ways, including carrying out operations that spin the event loop, operations that make the edit that's about to happen nonsensical, and so forth. It's a huge chunk of spec and implementation complexity. So I'd like to see some very compelling use cases to even consider it. Here's a couple use-cases off the top of my head: Google Wave: They keep a model of the content separate from the html contents of the contentEditable region. In order to make that work, for every user-action, they need to either mimic what the browser did or cancel the default browser behavior and perform that action themselves. In both cases, having a beforeinput event makes the code much more sane, less brittle and often more performant. In the case where they want to cancel the default browser behavior (e.g. undo/redo), they get the beforeinput event, cancel it and then do their thing. Without beforeinput, they need to wait for the action to happen and then either make sense of the changes to the DOM, or undo the changes and reapply their own changes. Those both lead to brittle and, in some cases, expensive code. In the case where they want to let the browser perform it's default action, having the beforeinput event allows them to properly bookend a user-action and know with confidence that they've correctly handled it. Instead, they currently have very complex and brittle logic listening to every event under the sun in order to make sure they catch every possible user-action. Typing at the beginning/end of links: Another more general use-case is needing to modify the DOM before the user-action occurs. This comes up often when typing at the beginning/end of a link (or otherwise special inline element). Different apps want different behavior (e.g. should the text inserted go inside the link or after it). Currently, controlling that behavior is really difficult. You need to capture every time the selection changes and mess with the DOM/selection appropriately to get the text inserted in the right place. In theory, you *could* do this with just the input event, but that would get you back into reverse engineering whatever the user-action was, which is again brittle and difficult to get right. Is that a bit more convincing with respect to the need for a beforeinput event? beforeinput aside, are you in support of extending the input event to contentEditable elements and adding the data/action attributes? Any thoughts from Opera developers? Anne, your previous comments on this thread make it sound like you support this and would consider adding it to Opera? Ojan
Re: [whatwg] oninput for contentEditable
On 3/4/10 4:11 AM, Ojan Vafai wrote: WebKit would like to implement this in the (very) near future. Before proceeding, we'd like to hear from other browser vendors that you're roughly on board with this direction of adding beforeinput and input events. Here are the changes I can think of that would result from this: 1) Fire input event for contentEditable areas as well as for text-entry form controls. 2) For every case where we'd fire input, add a new beforeinput event that fires before the DOM has been modified. 3) Add a new InputEvent interface with an action attribute to use for input and beforeinput events. 4) For events with an inserttext action attribute, also provide a data attribute that specifies the text being inserted. For other actions, data is the empty string. 5) input events may be batched as long as they have the same action. In the case of inserttext actions, the data attribute is the accumulation of text being inserted. One strange side effect here is that there may be multiple beforeinput events per input event fire, although it's not unlike having multiple keydown events before a single keyup. The list of actions still needs to be enumerated, but some obvious ones are inserttext, undo, redo, copy, paste, cut and drop. I also think we should get rid of the textInput event in deference to this more useful event, but that's a discussion we can have on www-dom once this is resolved. As far as I know, only WebKit currently implements textInput. textInput should be pretty useful when combined with the new key events and with the all the properties DOM 3 Events draft defines for it. Webkit's textInput isn't quite that, IIRC. -Olli Ojan On Tue, Jul 14, 2009 at 6:02 PM, Ian Hickson i...@hixie.ch mailto:i...@hixie.ch wrote: On Tue, 23 Jun 2009, Ojan Vafai wrote: Currently, textareas and text inputs support the oninput event that fires on all user-initiated modifications to their content. We should add this event to contentEditable elements as well and add an action property the specifies what action the user took that caused the input event. I haven't yet added this. I think we should probably address the various problems with contenteditable all at once, to make sure the solution is coherent overall. I'm watching what happens with the mutation event changes and tracking proposals for various other changes to contentEditable. It may be that we need to defer these changes to after HTML5 reaches last call, though, and have them in a future version next year some time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] oninput for contentEditable
WebKit would like to implement this in the (very) near future. Before proceeding, we'd like to hear from other browser vendors that you're roughly on board with this direction of adding beforeinput and input events. Here are the changes I can think of that would result from this: 1) Fire input event for contentEditable areas as well as for text-entry form controls. 2) For every case where we'd fire input, add a new beforeinput event that fires before the DOM has been modified. 3) Add a new InputEvent interface with an action attribute to use for input and beforeinput events. 4) For events with an inserttext action attribute, also provide a data attribute that specifies the text being inserted. For other actions, data is the empty string. 5) input events may be batched as long as they have the same action. In the case of inserttext actions, the data attribute is the accumulation of text being inserted. One strange side effect here is that there may be multiple beforeinput events per input event fire, although it's not unlike having multiple keydown events before a single keyup. The list of actions still needs to be enumerated, but some obvious ones are inserttext, undo, redo, copy, paste, cut and drop. I also think we should get rid of the textInput event in deference to this more useful event, but that's a discussion we can have on www-dom once this is resolved. As far as I know, only WebKit currently implements textInput. Ojan On Tue, Jul 14, 2009 at 6:02 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 23 Jun 2009, Ojan Vafai wrote: Currently, textareas and text inputs support the oninput event that fires on all user-initiated modifications to their content. We should add this event to contentEditable elements as well and add an action property the specifies what action the user took that caused the input event. I haven't yet added this. I think we should probably address the various problems with contenteditable all at once, to make sure the solution is coherent overall. I'm watching what happens with the mutation event changes and tracking proposals for various other changes to contentEditable. It may be that we need to defer these changes to after HTML5 reaches last call, though, and have them in a future version next year some time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] oninput for contentEditable
On 3/3/10 9:31 PM, Daniel Danilatos wrote: Worth noting, the events should convey the user intent - so, e.g. not just delete chars 5 - 8 but forward word delete, which is chars 5 - 8. So I have to ask... Why are events _before_ the edit needed? If we add these, then you have to define what happens when those event handlers modify the state of the DOM in arbitrary ways, including carrying out operations that spin the event loop, operations that make the edit that's about to happen nonsensical, and so forth. It's a huge chunk of spec and implementation complexity. So I'd like to see some very compelling use cases to even consider it. -Boris
Re: [whatwg] oninput for contentEditable
On Tue, 23 Jun 2009, Ojan Vafai wrote: Currently, textareas and text inputs support the oninput event that fires on all user-initiated modifications to their content. We should add this event to contentEditable elements as well and add an action property the specifies what action the user took that caused the input event. I haven't yet added this. I think we should probably address the various problems with contenteditable all at once, to make sure the solution is coherent overall. I'm watching what happens with the mutation event changes and tracking proposals for various other changes to contentEditable. It may be that we need to defer these changes to after HTML5 reaches last call, though, and have them in a future version next year some time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] oninput for contentEditable
On 6/24/09 4:42 AM, Ojan Vafai wrote: SUMMARY Currently, textareas and text inputs support the oninput event The event is input ;) that fires on all user-initiated modifications to their content. We should add this event to contentEditable elements as well and add an action property the specifies what action the user took that caused the input event. We should also add a cancellable onbeforeinput event. beforeinput event. USE CASE There are two main use cases. 1. A simple but comprehensive way to detect changes in a contentEditable region for features like autosave, transliteration, spelling correction, etc. 2. Maintaining the data in a non-html model and using HTML as the view on the data. This requires capturing each change to the contentEditable element's contents and updating the model appropriately. Specifically, this is what Google Wave does. WORK AROUNDS Sites that use contentEditable currently rely on MutationEvents to detect when their contents have changed. MutationEvents are lower-level than the developer cares for, fire far too frequently for these use-cases, are complicated to use and have a significant performance impact. Sites that don't use MutationEvents use a long list of events (keydown, keyup, keypress, copy, paste, undo, etc.) to monitor changes. This is a lot of code and hard to get right. Not to mention that browsers don't actually have events for all the possible user-initiated actions. Google properties actually use the long list of events for semantic things (e.g. catch ctrl+z, cancel it and perform a custom undo) *and* listen to MutationEvents to catch cases where browsers don't fire an event. PROPOSAL When a user-initiated action is going to modify the contents of a contentEditable element, a beforeinput event should be fired. The event should be cancellable and have an action property that is a string specifying what the user-action involved was (e.g. paste, inserttext, undo, etc). All the possible actions should be specified somewhere. (and perhaps vendors could use vendor prefix if they add some non-standard actions). Why would you need paste? There is paste event (though, not properly specified anywhere, I think); And for undo and redo there is UndoManagerEvent (terrible interface name, and 7.11.3 has a nice comment about UndoManager :) ). -Olli
Re: [whatwg] oninput for contentEditable
On Tue, 23 Jun 2009 21:42:18 -0400, Ojan Vafai o...@chromium.org wrote: SUMMARY Currently, textareas and text inputs support the oninput event that fires on all user-initiated modifications to their content. We should add this event to contentEditable elements as well and add an action property the specifies what action the user took that caused the input event. We should also add a cancellable onbeforeinput event. I threw an 'input' event doc http://shadow2531.com/opera/testcases/oninput/html5_input_event_support.html together, which includes 'input' and 'beforeinput' for contentEditable elements and documents in designMode. It also includes the .action property. Those are just my basic thoughts of how things should/could work. However, I didn't yet mention what a value change for contentEditable elements means. (Like that it's when the underlying markup changes) I also left the list for the valid action property values empty, since those would have to be agreed upon etc. -- Michael
Re: [whatwg] oninput for contentEditable
On Wed, Jun 24, 2009 at 6:41 PM, Michael A. Puls IIshadow2...@gmail.com wrote: On Wed, 24 Jun 2009 11:49:27 -0400, Anne van Kesteren ann...@opera.com wrote: By the way, did anyone ever implement textInput from DOM Level 3 Events? Just Webkit. And Mozilla ? https://developer.mozilla.org/En/DOM_Events#textInput -- Thomas Broyer
Re: [whatwg] oninput for contentEditable
On 6/24/09 6:49 PM, Anne van Kesteren wrote: On Wed, 24 Jun 2009 12:21:41 +0200, Olli Pettay olli.pet...@helsinki.fi wrote: Why would you need paste? There is paste event (though, not properly specified anywhere, I think); I'd think you want an event that covers all editing actions. Also, that's what the input event does for input. By the way, did anyone ever implement textInput from DOM Level 3 Events? If not maybe someone should email www-dom about nuking that. Why would you want to nuke textInput? Perhaps textInput (in some extended form) could be used for contentEditable and we could deprecate input event. textInput has the advantage that it has .data -Olli
Re: [whatwg] oninput for contentEditable
Michael A. Puls II wrote: And Mozilla ? https://developer.mozilla.org/En/DOM_Events#textInput I tested it on a textarea in Firefox latest trunk before posting. It didn't fire. Yeah, that documentation was apparently authored by copy/paste from the spec... Fixed it to make it clear that this is not implemented yet. -Boris
Re: [whatwg] oninput for contentEditable
On Wed, Jun 24, 2009 at 11:51 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 6/24/09 6:49 PM, Anne van Kesteren wrote: On Wed, 24 Jun 2009 12:21:41 +0200, Olli Pettay olli.pet...@helsinki.fi wrote: Why would you need paste? There is paste event (though, not properly specified anywhere, I think); I'd think you want an event that covers all editing actions. Also, that's what the input event does for input. By the way, did anyone ever implement textInput from DOM Level 3 Events? If not maybe someone should email www-dom about nuking that. Why would you want to nuke textInput? Perhaps textInput (in some extended form) could be used for contentEditable and we could deprecate input event. textInput has the advantage that it has .data textInput only fires when you input text. It does not fire when you delete, paste, bold (i.e. ctrl+b), etc. That does make me wonder whether certain input events should have a data property (i.e. action=inserttext). It's a little ugly to just have data in some cases, but it's no more ugly than rich text libraries needing to listen to input+textInput or input+keydown. On the other hand, maybe it we should try to spec data for all input event cases. Ojan
