hi, I think that the css "transition" property can be also used for DOM values scrollTop and scrollLeft I'm talking about animate, instead of a direct jump, when scrollTop or scrollLeft are set (also should work with scrollIntoView() and focus()) in plus the "delay" and the "duration" properties may be used to customize the default "smooth scrolling" of the browser (if any) IE body { /*means: animate .scrollLeft and .scrollTop */ -webkit-transition-property:-webkit-scrolling; -webkit-transition-duration:0.5s; -webkit-transition-delay:0.1s; overflow:auto; } it is just an idea that may can be analyzed change the scrollbar behavior may not be a good idea, but developers already use jquery or similar to do this, then a native solution isnt more dangerous as js frameworks are... on the contrary, can be more accessible and usable than a js framework solution changing the mouse behavior is not very important, but animation for scrollTop, scrollLeft, scrollIntoView, focus may be really useful what do you think about this? (this request has been posted on the mozilla's bugtracker too)
scrollTop and scrollLeft are not CSS properties. It's expected that some other kind of Animation API will work for them in future.
(In reply to comment #1) > scrollTop and scrollLeft are not CSS properties. It's expected that some other kind of Animation API will work for them in future. Hello, they are not "CSS", of course, but the scrolling coordinates are related to layout, then to css I don't think it is clever ignore this without a discussion. in plus, .scrollLeft and .scrollTop will be part of CSSOM, then they are (will be) part of CSS
`scrollTo with {behavior: 'smooth'}` and `scroll-behavior: smooth` is supported in every other browser. This proposal should be closed in favor of implementing scroll-behavior. Right now, the old way to achieve the same is to polyfill the behavior using requestAnimationFrame. One common problem with existing implementations is that use static scroll velocity rather than static duration. This means that if you scroll a long distance, it can take a very long amount of time to animate. However, The draft specification states that ``` 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 conventions, if any. ``` So the Webkit implementation could choose to use a static duration instead. Further, if the ideas in this proposal seem relevant, you could add some new properties to make scroll-behavior more customizable: ``` -webkit-scroll-behavior-duration: 0.5s; -webkit-scroll-behavior-timing-function: ease-in; ```
*** This bug has been marked as a duplicate of bug 188043 ***