danielfernandez
commented
6 years ago Chrome implemented smooth scrolling in a way that seems to be dependant on the length of the document being scrolled, rather than a fixed time
WAT
Open ultraq opened 6 years ago
danielfernandez
commented
6 years ago Chrome implemented smooth scrolling in a way that seems to be dependant on the length of the document being scrolled, rather than a fixed time
WAT
ultraq
commented
6 years ago Yep. It's... 🤦♂️
On larger screens, our docs are presented as a left-hand-side column for the Table of Contents, with the doc content taking up the rest of the screen. In this view, when you clicked on a link to a different section of the docs, you could see the content change. On smaller screens, because the ToC is presented as a toggled overlay that obscured the content, you couldn't tell if you'd actually changed section - one header and text that follow look pretty much the same as any other header and text!
Smooth scrolling (https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-behavior) fixed this and was added to the docs several months ago because, as the ToC disappeared, you could visibly see the contents moving to the new section, giving you assurance that your command was accepted.
Recently however, Chrome implemented smooth scrolling in a way that seems to be dependant on the length of the document being scrolled, rather than a fixed time like how it was in Firefox. This meant that, if you wanted to go straight to the end of the docs (where our Appendix of common utility functions lives), you'd have to suffer a very long wait as Chrome brought that part of the docs into view (see: #54).
Given that, the smooth scrolling will be removed for #54.
This then means we need to rethink how to present the table of contents to those browsing the docs on mobile so they still get the assurance that something has actually changed.