This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24748 - An event to notify the page that we're about to scroll (e.g. because a node was focused)
Summary: An event to notify the page that we're about to scroll (e.g. because a node w...
Status: NEW
Alias: None
Product: CSS
Classification: Unclassified
Component: CSSOM (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Simon Pieters
QA Contact: public-css-bugzilla
Depends on:
Blocks: 24750
  Show dependency treegraph
Reported: 2014-02-20 19:11 UTC by Ian 'Hixie' Hickson
Modified: 2014-03-11 16:56 UTC (History)
3 users (show)

See Also:


Description Ian 'Hixie' Hickson 2014-02-20 19:11:55 UTC
Use case: some fallback content in a canvas is given AT focus (not keyboard focus) and the user agent, based on an AT request, would like to scroll to the element. However it's being painted on a canvas, and in fact is off the canvas at this time, so we need to tell the author to scroll to it.

Proposed design: whenever we need to scroll, fire an event on the element, that bubbles, and whose default action is to do the scroll. When the event is fired on a canvas or a fallback element in a canvas, include the relevant region, if any (much as we do with mouse events).
Comment 1 Ian 'Hixie' Hickson 2014-02-20 19:12:12 UTC
zcorpan: Should this belong in CSSOM?
Comment 2 Simon Pieters 2014-02-24 10:12:05 UTC
I'm OK with having this in CSSOM View, although I think it really belongs in "the" UI Events spec.

Given the information in this bug I'm not confident with my ability to spec what is needed here, I have no idea what hooks, if any, you need for canvas. Maybe you can spec out in HTML what you have in mind first?
Comment 3 Ian 'Hixie' Hickson 2014-02-24 18:27:13 UTC
I can take care of the canvas side of this the same way I do it for MouseEvent (see "partial interface MouseEvent" in the HTML spec). I think we only need a spec to say "when a user agent feels the need to scroll to a particular part of the page, e.g. due to the user moving the focus or due to an accessibility tool requesting a scroll to a specific element, the user agent must fire this event and if it's not canceled must scroll to the element in question" (which then fires a scroll event, of course). This would be distinct from regular scrolling via the scrollbar, touch pan, or as the default action of a mouse wheel event. Just make sure you use a new event type so that I can extend it.
Comment 4 Simon Pieters 2014-02-25 09:46:41 UTC
How about 'beforescroll'?

So these cases should not fire it:

User scrolls normally.
Scrolling API is invoked.
focus() is invoked.

But these should (if scrolling is necessary):

User asks for AT focus on some element.
User asks for keyboard focus on some element (e.g. tabs to it).

Comment 5 Ian 'Hixie' Hickson 2014-03-11 16:56:20 UTC
Sounds right.