This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://dev.w3.org/csswg/cssom-view/#scrolling-0 [[ fire an event named scroll ]] Gecko uses UIEvent for scroll. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2937
I just wanted to add that in IE we have other behavior. Simple comparison: - Chrome always use Event - Firefox use UIEvent only for scroll event. << according D3E it should also be resize (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-type-resize) - IE use UIEvent for select, resize and scroll. More detail https://bugzilla.mozilla.org/show_bug.cgi?id=992703. Next problem is that when event is generated directly from UI then can be UIEvent interface. But sometimes we can make some synthetic action from script (using dedicated method) and how interpretate this? One browser use Event but other still use UIEvent. All specifications do not devote much space to exactly specify this behaviour.
In Edge, scroll is a UIEvent. In Safari, scroll is a plain Event.
So it's 50/50. :-( It seems .pageY contains potentially useful information in Gecko. Searching on github reveals that there are some pages that use it to record/store scroll position: https://github.com/search?l=javascript&q=onscroll+pagey&type=Code&utf8=✓ It seems less risky for WebKit/Blink to switch to UIEvent than the other way around, so I suggest we change scroll to use UIEvent. Relatedly, in Gecko, .pageY is on UIEvent, not on MouseEvent as the current spec says. Though Chromium has it on MouseEvent. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3987 Rick, do you have opinions?
According to MSDN pageX is on MouseEvent in IE/Edge, so I suppose scroll being a UIEvent is only useful in Gecko currently. Travis, does MSDN match what Edge does? Do you have any thoughts what we should spec here?