The ScrollBehavior DOM API would certainly be useful by itself and solve some of our immediate needs (paged B2G home page, for example). I also imagine that it would not preclude us from implementing the css property in the future if we implement it carefully.
I would like to hear feedback regarding the motion of the scrolling itself... The spec describes the motion as "The scrolling box is scrolled in a smooth fashion using a user-agent-defined timing function over a user-agent-defined period of time. User agents should follow platform convensions, if any.". Should we implement a separate model for any of the platforms we support, or is resolution independence and platform-specific tuning of the "critically-damped-motion" model I proposed sufficient? In the Bug 1010538 (https://bugzilla.mozilla.org/show_bug.cgi?id=1010538) I am proposing that this movement model would inherit the velocity of the scroll resulting from fling gestures or prior smooth scroll operations that are interrupted. This would be needed to implement "scroll snapping" like behaviors for carousels and paged navigation that allow manual dragging (Including the B2G home page). The W3C scroll-behavior spec does not require this behavior, but also does not preclude it. My greatest concern is that as platform conventions change, this behavior could (or should) be updated to match. Web developers that depend on particular acceleration / deceleration curves or time to completion may see their web applications behave differently in the future. If they treat it as a black-box; however, their applications may continue to feel modern, as opposed to movement implemented within their own Javascript. Does this raise any concerns or need for further dialogue before implementation? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
