- From: Matt Brubeck <mbrubeck@mozilla.com>
- Date: Wed, 21 Sep 2011 11:44:17 -0700
- To: Anne van Kesteren <annevk@opera.com>
- CC: public-webevents@w3.org
On 09/13/2011 07:46 AM, Anne van Kesteren wrote: > Please do not standardize new initXXXEvent() methods. Instead use event > constructors like HTML, Progress Events, DOM4, etc. In our telcon this week, we decided to keep the initTouchEvent method in the v1 spec. In the v2 spec we will remove initTouchEvent and add a DOM4-style constructor to replace it. Our reason for keeping this method in version 1 is that it is already interoperably implemented, and we expect to need it in tests. Removing it would not allow us to finalize Touch Events v1 as a Recommendation with a full test suite as quickly as we want to. > Using DOM4 you could also use the "fire an event" terminology to make it > clear which events are trusted and which are not. This sounds good to me. I think for v1 we will not want to depend on DOM4 because it is not a recommendation yet, but we could make this change for v2. (Is this right? I am still new to the W3C process.) > Instead of introducing a new interface called DocumentTouch please use > "partial interface Document" instead to extend the Document interface. > You need to add a reference here too for Document. I pushed a fix to both the v1 and v2 (default) branches: http://dvcs.w3.org/hg/webevents/rev/a4ba6867d4d0 http://dvcs.w3.org/hg/webevents/rev/4153b586295c > Is it too late to replace these create* methods with actual constructors > by the way? Should we add constructors nevertheless? As I mentioned in my previous reply, I think it may be too late to remove the create* methods because they are used for feature detection in the wild. However, I think we should add constructions nevertheless in Touch Events v2. Any objections?
Received on Wednesday, 21 September 2011 18:44:47 UTC