- From: Jacob Rossi <Jacob.Rossi@microsoft.com>
- Date: Fri, 12 Aug 2011 06:51:21 +0000
- To: "annevk@opera.com" <annevk@opera.com>
- CC: "www-dom@w3.org" <www-dom@w3.org>
Hi Anne, During a working group telecon, we discussed this issue. We agreed that the scroll event fits as a UIEvent from a taxonomy standpoint. While it doesn't take advantage of the detail/view properties, neither do some of the other UIEvents. Having a logical organization of events is helpful for feature detection and is one of the improvements Level 3 events makes over Level 2. Therefore we have rejected this issue and retained the scroll event as a UIEvent. Thanks for your careful review of DOM L3 Events. Regards, Jacob ==================================================== From: Doug Schepers <schepers@w3.org> Date: Fri, 10 Sep 2010 05:36:46 -0400 Message-ID: <4C89FC2E.80607@w3.org> To: Anne van Kesteren <annevk@opera.com> CC: www-dom@w3.org Hi, Anne- I've added this as a Last Call comment in our issue tracker as ISSUE-120 [1]. I'd be especially interested in further feedback from implementers and from content authors and script library creators. Comments inline... Anne van Kesteren wrote (on 8/29/10 3:57 AM): > On Sat, 28 Aug 2010 21:08:23 +0200, Doug Schepers <schepers@w3.org> wrote: >> Anne van Kesteren wrote (on 8/28/10 1:55 PM): >>> What is the advantage? As .detail means nothing and .view is useless. >> >> The advantage I see is a more logical and consistent framework on >> which to build future events, and easier for developers to learn. In >> several of the event interfaces, there are properties that only have >> meaningful values for a subset of the events on that interface, but >> which are still grouped logically, so this has precedent. >> >> From a developer and script library perspective, there may be reasons >> to treat UIEvents differently, and this makes it easy to detect that >> category of events (rather than reply upon a hardcoded list of event >> types). > > This all sounds rather vague. I would rather have us not change the > interface unless a clear need is identified. > > >>> Just seems like additional complexity for no reason. >> >> Isn't any additional complexity is negligible in terms of >> implementation and performance? > > Changes are not negligible. That depends upon the negative impact of the change. Do you have some evidence of this change breaking any content, for example? >>> It works differently for the Document object, yes. (I don't have >>> anything I can share in test form at this point.) >> >> Okay, thanks for the heads-up; I didn't realize this before, and it's >> probably the reason 'scroll' was listed as bubbling before. I've noted >> this in the spec, in the event type definition and the event table: >> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-scroll >> > > If this is supposed to be some kind of normative description, shouldn't > that be normative too? Yes, I've now corrected that in the Editor's Draft... I had a brain lapse in marking it as a note, the intent was to call attention to it. [1] http://www.w3.org/2008/webapps/track/issues/120 Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Friday, 12 August 2011 06:51:50 UTC