- From: David Flanagan <david@davidflanagan.com>
- Date: Wed, 20 Oct 2010 23:10:34 -0700
- 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 UTC