W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2010

Re: ISSUE-155 (textinput): Consider lowercasing 'textInput' event [DOM3 Events]

From: David Flanagan <david@davidflanagan.com>
Date: Wed, 20 Oct 2010 23:10:34 -0700
Message-ID: <4CBFD95A.2040607@davidflanagan.com>
To: Doug Schepers <schepers@w3.org>
CC: www-dom@w3.org
On 10/20/2010 05:49 PM, Doug Schepers wrote:
> Hi, David-
>
> David Flanagan wrote (on 10/20/10 7:13 PM):
>>
>> That was quick action!
>>
>> I was unaware, when I made the request, that Webkit-based browsers
>> already supported textInput in its camel-case incarnation. What I fear,
>> of course, is that Apple or Google will feel that they need to keep
>> supporting textInput and that we'll end up with the same event being
>> fired twice under two different names.
>
> It's a reasonable concern, and we did talk about it during the telcon,
> but we decided there probably isn't much (if any) content out there
> using 'textinput' yet.
>
> Tony seems to confirm this is okay with the WebKit developers. I tested
> the WebKit support (see attachment), and while they do fire the event,
> it doesn't seem to have the right properties, so I think it's still
> under development.

I'm happy to hear that the Webkit developers can just do a switch.

Your test case checked for KeyboardEvent fields instead of TextEvent 
fields.  Webkit currently supports TextEvent.data, which makes the event 
quite useful right now.  (TextEvent.inputMethod doesn't seem to be 
there, but that is less useful.)

>
>> Once I discovered that textInput was actually supported by Chrome and
>> Safari, I went ahead and used it in some example code for the next
>> edition of my JavaScript book. Now I'm left wondering how to
>> future-proof my example so that it will continue to work once browsers
>> also support "textinput".
>
> I hope it's not too late to change your book?

No, not at all.  I was just using that as an example of the more general 
conundrum of how to write future-proof code...

>
>> So, my concern now is to have a clean path forward for existing code. If
>> the webkit implementors disable textInput when they implement textinput,
>> then content authors today can simply register handlers for both event
>> types, knowing that only one or the other will be triggered.
>>
>> Was there any discussion on the teleconference about how this transition
>> will be handled?
>
> Let's hope there won't be any such problems... DOM3 Events is still just
> a draft, so it's subject to change.
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs

Thanks,

	David
Received on Thursday, 21 October 2010 06:11:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:06 GMT