> > Actually non-auto values for the ScrollBehavior DOM API override the > > scroll-behavior CSS property per spec. So I think the real question for us > > is whether to implement the scroll-behavior property, or the ScrollBehavior > > DOM API, or both. I think for now we should just implement the > > ScrollBehavior DOM API. > >
I would also like feedback on the concept of the scrolling behavior being a "write-only" property in much the same way that position: sticky was implemented. Initial conversations on implementation of scroll-behavior: smooth considered that the property would effectively be "write-only", much like how position: sticky has been implemented. When smooth scrolling is enabled for an element, CSSOM methods would return the target location immediately as though the scrolling has already completed. Effectively, Javascript would not be aware of any effect from enabling smooth scrolling. In the event that a scroll operation is cancelled, either by user interaction (scroll wheel, touch gestures, etc) or through script, the "write-only" nature proposed will have "lied" to scripts about the ending position at the start of the animation. Once the animation is cancelled, the DOM methods would need to return the true scroll position, which may appear to scripts as scrolling in the reverse direction. Is this behavior acceptable or would it be more desirable to always return the actual scroll position in DOM methods? _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
