Re: [editing] input event should have a data property WAS: [D3E] Where did textInput go?
On Thu, May 3, 2012 at 12:44 AM, Ojan Vafai wrote: > As I've said before, I don't think command/value should be restricted to > contentEditable beforeInput/input events. I don't see any downside to making > command, value and text all available for all three cases. It simplifies > things for authors. The code they use for plaintext inputs can be the same > as for rich-text inputs. If command/value make any sense for plaintext inputs, yes. As specced, and AFAICT as implemented in Gecko and Opera, execCommand() only operates on the contents of contenteditable areas, not plaintext inputs. If that were changed to match (AFAICT) IE and WebKit, then I'd agree that it would make sense to expose the same properties.
Re: [editing] input event should have a data property WAS: [D3E] Where did textInput go?
On Thu, Apr 5, 2012 at 6:19 AM, Aryeh Gregor wrote: > On Wed, Apr 4, 2012 at 10:07 PM, Ojan Vafai wrote: > > The original proposal to drop textInput included that beforeInput/input > > would have a data property of the plain text being inserted. Aryeh, how > does > > that sound to you? Maybe the property should be called 'text'? 'data' is > > probably too generic. > > Sounds reasonable. Per spec, the editing variant of these events has > .command and .value. I think .text is a good name for the plaintext > version. It should just have the value that the input/textarea would > have if the beforeinput event isn't canceled. > I'd like this to be available for contentEditable as well. Is there any benefit to restricting this to input/textarea? As I've said before, I don't think command/value should be restricted to contentEditable beforeInput/input events. I don't see any downside to making command, value and text all available for all three cases. It simplifies things for authors. The code they use for plaintext inputs can be the same as for rich-text inputs. Ojan
Re: [editing] input event should have a data property WAS: [D3E] Where did textInput go?
On Wed, Apr 4, 2012 at 10:07 PM, Ojan Vafai wrote: > The original proposal to drop textInput included that beforeInput/input > would have a data property of the plain text being inserted. Aryeh, how does > that sound to you? Maybe the property should be called 'text'? 'data' is > probably too generic. Sounds reasonable. Per spec, the editing variant of these events has .command and .value. I think .text is a good name for the plaintext version. It should just have the value that the input/textarea would have if the beforeinput event isn't canceled.
[editing] input event should have a data property WAS: [D3E] Where did textInput go?
BCC: www-dom CC: public-webapps The original proposal to drop textInput included that beforeInput/input would have a data property of the plain text being inserted. Aryeh, how does that sound to you? Maybe the property should be called 'text'? 'data' is probably too generic. On Wed, Apr 4, 2012 at 11:01 AM, Andrew Oakley wrote: > On Wed, 04 Apr 2012 18:58:49 +0200 > "Anne van Kesteren" wrote: > > > On Wed, 04 Apr 2012 18:54:46 +0200, Andrew Oakley > > wrote: > > > The textInput event seems to have been removed from the latest versions > > > of DOM 3 Events but I can't find any real explanation as to why it > > > disappeared, or if it has been replaced by anything. > > > > See https://www.w3.org/Bugs/Public/show_bug.cgi?id=12958 Conclusion was > > emailed to this list in > > http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0225.html > > Thanks, I must have missed that. The reason seems to be incompatible > implementations and that other events can be used for the same thing. > > How would content now determine what text was input? The input event > in HTML5 appears to just be a simple event, and the keyboard events are > obviously not sufficient (copy+paste being the most obvious thing that > could be missed but there are also the usual IME issues). > > I realise this might be possible with the editing APIs, but that seems > excessively complicated (and not supported by any browsers as far as I > know) way of getting some fairly basic information. > > -- > Andrew Oakley > >
