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

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.


> 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?


> 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