W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [editing] input event should have a data property WAS: [D3E] Where did textInput go?

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 2 May 2012 14:44:29 -0700
Message-ID: <CANMdWTuck7vExwsCORb9jXgaBHqTd5SQ+8AOqFs8+uO9Ecq8yQ@mail.gmail.com>
To: Aryeh Gregor <ayg@aryeh.name>
Cc: Andrew Oakley <andrew@ado.is-a-geek.net>, Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
On Thu, Apr 5, 2012 at 6:19 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Wed, Apr 4, 2012 at 10:07 PM, Ojan Vafai <ojan@chromium.org> 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.

Received on Wednesday, 2 May 2012 21:45:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:33 UTC