- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 17 Aug 2011 16:18:24 -0700
- To: www-dom@w3.org
I'm not sure if this is relevant -- onmousedown+ scroll is a pretty terrible situation. By and large, I never receive an onmouseup event, when the user is working with a scroll bar. I've had to add onmousedown.addEventListener(event.stopPropagation) to my overflow divs, to catch that issue. This is an edge case, I'm not sure that it's relevant. But while you're looking over dom events, and scroll is being examined, I thought I'd bring it up. Here's someone who reported it on stackoverflow some months ago: http://stackoverflow.com/questions/5972542/how-to-detect-mouseup-on-a-scrollbar-or-scrollend-event -Charles On 8/11/11 11:51 PM, Jacob Rossi wrote: > 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 Wednesday, 17 August 2011 23:18:48 UTC