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

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

From: Tony Chang <tony@chromium.org>
Date: Wed, 20 Oct 2010 16:24:51 -0700
Message-ID: <AANLkTikLg7XLmrKhLxGuH6OErew6NV8o1EbyvgKCnGPZ@mail.gmail.com>
To: David Flanagan <david@davidflanagan.com>
Cc: Doug Schepers <schepers@w3.org>, www-dom@w3.org, Ojan Vafai <ojan@chromium.org>
I don't know of any sites that currently depend on textInput.  I think it's
early enough in it's implementation lifetime that we can just make the
switch in WebKit.  We were trying to rename the event to beforeInput, which
would have been just as disruptive.

On Wed, Oct 20, 2010 at 4:13 PM, David Flanagan <david@davidflanagan.com>wrote:

> Doug,
>
> 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.
>
> 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".
>
> 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?
>
>        David
>
>
>
>
> On 10/20/2010 12:44 PM, Doug Schepers wrote:
>
>> Hi, David-
>>
>> Thanks for your comments.
>>
>> We discussed one of your issues, lowercasing 'textInput', at the DOM3
>> Events telcon today [1], and we agree that it would be handy, and don't
>> see much risk in changing it at this point.
>>
>> I have changed this throughout the DOM3 Events spec, and you will see
>> these changes reflected in the next editor's draft.
>>
>> Please let us know whether or not you are satisfied with this resolution.
>>
>> [1] http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0095.html
>>
>> Regards-
>> -Doug Schepers
>> W3C Team Contact, SVG and WebApps WGs
>>
>>
>> Web Applications Working Group Issue Tracker wrote (on 10/20/10 12:30 PM):
>>
>>>
>>> ISSUE-155 (textinput): Consider lowercasing 'text'Input' event [DOM3
>>> Events]
>>>
>>> http://www.w3.org/2008/webapps/track/issues/155
>>>
>>> Raised by: Doug Schepers
>>> On product: DOM3 Events
>>>
>>> David
>>> Flanagan<
>>> http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0065.html>:
>>>
>>> [[
>>> 0) I suspect that this has already been debated at length, but does the
>>> "textInput" event really have to be mixed case? With the deprecation of
>>> the various DOM-prefixed event types, won't this be the only mixed-case
>>> event type? Assuming that browsers expose this event with an "on"
>>> handler property, JavaScript programmers are going to be confused when
>>> typing "ontextInput" and will end up doing "onTextInput". If a
>>> single-case name is good enough for genuinely hard-to-read things like
>>> "compositionend", it should be fine to use "textinput" for this event!
>>> ]]
>>>
>>
>>
>
>
Received on Wednesday, 20 October 2010 23:25:20 GMT

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