Scrolling on the web: A primer
blogs.windows.com
blogs.windows.com
Scrolling is one of those things that (in my opinion) get calibrated in the brain for hand-eye co-ordination. Which is why (again IMHO) there are religious wars fought over, for example, Apple's trackpads. This stuff is important. It can be a jarring experience when scrolling suddenly doesn't work. Flip side is, I'm sure some people don't care.
There's nothing more annoying than a web designer saying "I know better than you" and re-implementing features. Because they're usually wrong.
EDIT: Would people accept it if each webpage re-adjusted your mouse pointer speed and acceleration? Is there any difference between one mouse function and another? Why do web designers think they have the right?
Scroll bars provides 3 different scroll methods:
- Click and drag scroll thingy. The most used method, but sometimes misunderstood. It should scroll only as much as you moved the mouse. It wreaks havoc with endless scroll pages.
- Click on the bar outside the thingy. This used to be equivalent to pgdown/pgup. It was the method I used the most, and I was infuriated countless times when it behave differently: on some platforms it means "go here".
- Arrow buttons. Not very useful and virtually extinct at this point.
Lots of know-it-all web developers hijack scrolling and unsurprisingly don't know that you can scroll with space. The OS developers have thought about accessibility.
What's frustrating is that this is a solvable problem. I've seen sites that have fixed it, and fixed it well. But they are vanishingly rare. So I will just keep killing their sticky headers and footers...
Of course if someone else beats me to it, that's fine too...
Few omitted means to scroll - hold middle mouse button and drag (this usually works well sideways and in case no scroll bar is present) - spacebar / shift+spacebar, pgUp / pgDn, home / end - and FMoPW most importantly clicking the arrows in the scroll bar. For "us" this seems almost uncomprehensible, but I regularly see users perform scolling this way.
For example my wife with track pad (yes, it is capable of two finger gestures), and my mother even with mouse with scroll wheel, until recently.
No wonder, discoverability of that action is way above all that abstract "dragging", "swinging" and "pressing" concepts without direct visual clue.
I pretty much only use arrow buttons to scroll screens of text into my eyeline.
I get really annoyed when arrow buttons are overloaded to tab between screen elements instead of scrolling (my online banking site, I'm looking at you!)
https://i.imgur.com/rgIbdur.png
it comes in only one color variant, it's inconsistently looking across browser, takes a lot of space, especially for scrolling narrow elements, it has low contrast so it doesn't even do a good job accessibility wise etc.
go to a site like Bulgari's and bam, custom scroller, precisely for this reason
https://i.imgur.com/T3Yasht.png
you'll notice the page scroller is untouched, because it doesn't contrast with the page style, being a browser element, but the inside page scroller would sucks.
you gonna argue with them they have to design their website style to accomodate the gray slate slab of vintage scrollers?
I don't know what browser you're using, but if it's Windows or some GNU/Linux distro, from memory both of these allow you to customise scrollbars. What if I have accessibility requirements and want to customise how software that I run on my own computer works?
The modern web cares very little about such requirements, since they are unlikely to be correlated with making money.
I don't like where things are going :-(.
The only person who cares what the scroll bars look like is the designer of the content within the web view. They have mistakenly thought that this is their responsibility.
If it is such an issue for the designer, maybe they should implement designs that are complimentary to the scroll bar?
that's impossible because, as I said in the comment above, every browser has it's own scroll bar forced upon the user, especially if you factor in mobile browser and their slim, thin black translucent bar (which only appears when you scroll so you don't even know something is scrollable... talk about good design uh?)
I'm gonna take your word for it tho and will use the complain button on that Bulgari page to let them know their solution "betrays a pretty limited understanding of design" and they will need your more competent service. /s
The browser scrollbar shouldn't be part of the corporate/brand identity any more than the browser menu, address bar or navigation buttons. Navigation belongs to the user, not the webpage designer.
It's one of the worst CSS kludges I have ever seen. I don't know enough about cross browser compatibility though to know if there's a better way?
--
Their custom scroll bar looks identical to the native one.
The whole thing they made feels pointless and user hostile.
The pellet in your second image isn't the worst, but I'm pretty sure anyone implementing "gorgeous" 5-pixel slivers never uses them or they'd have permanent black eyes from punching themselves in the face.
Adapt the styling if you wish, using Stylish:
It's not just that they are saying "I know better than you", they are saying they know better than HCI teams that have spent years tuning interfaces in response to actual research and testing. Most of the web and app designers I've worked with have never watched a person use their designs, much less considered their work in the context of the entire OS experience.
She told me "Our site isn't going to work like any other website."
She was right. It didn't. The whole thing was canned six months later.
Often times custom scrolling is used to fix that.
We could remove 90% of custom scrollbar javascript if this was fixed.
If a "normal" web developer struggles with that, they can provide JavaScript workarounds, perhaps many, but they usually aren't that intimate with C/C++ and the whole framework on which Firefox is based.
Also, as with most projects, if a webdev can solve this problem with a workaround now, they don't invest time to provide a proper long-term solution. If if they are capable of improving Firefox, they'd still need to create the JS workaround, because short-term is what they are paid for.
It sucks, but there's a reason that people choose to try to replace these elements (unfortunately, with mixed results).
For future reference, you can actually get rid of nasty scrollbars without ruining the normal scroll behaviour by having an outer div(overflow:hidden, width:x) containing the content div(width:x+scrollbar-width).
Where do you draw the line, though? The scrollbar is not part of the website, it's part of the window where the website is being rendered, and the window is itself part of a desktop environment. Would you try to override the look and feel of the desktop environment if you could?
The answer to this question is almost always yes by short sighted designers who try to control scrolling behavior. In fact optimally they'd like to control your hardware look and feel also.
I hate it when the scrolling feels unnatural. At the same time, it's good when the design looks nice. It's possible to achieve both of those things.
Nasty scrollbars. OK. What if I want to scroll down about a third of a hypothetical long page? I'd either use the wheel/touchpad and make multiple gestures to reach there, or hit space/page down multiple times, or hit end and page up a bit less times, or just point the mouse cursor to about where I want to go on the scrollbar and click on the blinking thing. That nasty scrollbar is mine.
A 16-year old bug with 200+ comments sure looks easy to fix…
For me, fast scrolling is more important than colored scrollbar.
Guess what the site designer cares about?
Their site is their branding, not yours, not Mozilla's.
Back when splash pages were popular I pretty much closed any tab that presented a splash page -- life is too short. Likewise whizzy Flash sites. What I miss about Flash is that it was an excellent bozo avoidance system.
As it is, colored scrollbars are not part of any standard, so asking for them are like asking Google or Mozilla to support ActiveX for your webapp -- if you rely on non-standard, proprietary features, you're locked in to your non-standard browser.
not defending this pattern, I just don't think people fuck with the scrollbar just to make it "better". they probably try to make it as close to original as they can which of will of course be, nothing like the original :)
You know those pages with several 100% height slides? They don't look as nice if there's a bit of the previous one showing at the top or the next one at the bottom.
But yeah, it sucks, we all agree with that.
We need this to be done in CSS, something like body { scroll-step : 100%; }
What I don't understand is scroll highjacking in something like Google AMP.
It replicates the browsers default behavior, only poorly. No tap the menu bar to scroll to the top, motion sickness inducing acceleration, etc
What if I want to zoom in or out on the slide for reasons of accessibility?
So it's not always a designer saying "I know better than you."
I do think that they're going about solving the problem the wrong way though. Your design should on its own encourage scrolling by making it obvious that additional content exists (avoiding so-called "false floors") — it can be harder to do this than unchanging your design and suggesting scrolljacking, which is why I think we see it so often.
I'm talking about what happens when you actually do scroll. In my experience those seem to the same sites that are visually confusing are the ones that re-program your scroll down as a page-down...
This is especially egregious on mobile, where not only they implement scrolling badly in a way that only vaguely matches a single device/os (with terrible performance) and is completely off on others, but also feel compelled to hijack scrolling for "creative"† navigation, like swipe left/right to move across articles, which gets triggered every time you scroll downward but ever so slightly sideways. Like, I'm on a bus and actually holding the phone, so don't zap me to an unrelated article I don't care about on each encountered pothole please.
† at least as creative as the number of expletives I'm thinking about every single time such an abomination of an interaction triggers.
This is my problem with overly designed interfaces in general. Your website is not a special snowflake. It doesn't need a new way to interact, it needs consistency with other sites.
For those of us who use the scroll bar for its intended purpose, everything broke with the single page fad. Now so much of the web doesn't scroll anymore that I've re-trained myself on the arrow keys. That mostly works, until they set keyboard focus too.
Even newspapers now load some entirely different article when I've read half way through one, just in case I want to feast my eyes on something unrelated when I'm done. I'm just sitting this one out. It'll pass.
> Today browsers are so terrified of breaking a web API that they have allowed the mobile web to become a cesspool
This is actually an active area of discussion for browser vendors, and we're all experimenting with "interventions" that are designed to benefit users at the expense of web developers. Our most recent efforts can be browsed at https://github.com/wicg/interventions , and you can see things in there like "passive-by-default" event listeners, timer throttling for background tabs and cross-origin iframes, requiring user intent for vibration, etc.
Not all of these efforts have been popular with web developers, and some of them may even need to be rolled back. But browser vendors are indeed trying to address this problem! :) You'll note that Chrome, Firefox, Edge, and WebKit representatives are all involved in this effort.
It's par for the course with MS tech docs IMHO, well at least the bulk of their dev documentation. I even marvelled at the MSDN docs for the same reasons some 15 years ago as a freshman. I was relieved to see the same spirit in the "extensibility" articles at http://code.visualstudio.com/docs/ (compared to the huge furball of distributed-across-blogs-and-forums, incomplete, or dated equivalent for say Sublime..).
Now. OS-wise and userland-wise I'm certainly no MS fan (and tend to stay as clear as is feasible), but as far as the entire developer ecosystem goes (except maybe SharePoint-related, that was quite the mess a few years back, dunno about today tho), it has been for ages and continues to be: near-on utopia!
Ah, glad you mentioned that. I was about to say that Sharepoint (especially 2005-2010) felt woefully under documented when I worked with it.
I think Sharepoint dev has gotten better since 2013 (the introduction of their app model), but I left that role before the company upgraded so I can't say for certain.
For all its advances, the web platform is still incredibly primitive in some areas.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/position#St...
We dropped IE10 support when we stopped doing IE9 a year or so ago because they both had similarly insignificant numbers, and the opportunity cost of supporting them was too high.
IE11/Edge are also showing fairly similar numbers, which suggests edge uptake is slow, but even factoring in the extra hours, the bugs they generate (usually weird flex issues in both cases) we still effectively make more money by supporting them than not.
Does this not work on some modern browsers out there?
I mean, these features are as basic and RESTful as it gets.
Yep, this sucks. Typical use case: I load a few articles in background tabs to read later offline. Too late, I realize they either load dynamically, or have a useless periodic refresh (I'm looking at you, NY Times), so they're useless when I go to read them. I've mostly learned to quickly scroll all the way through tabs to make sure they're loaded, but this is a poor solution to a self-imposed problem (too-heavy pages).
Pocket or similar apps are another option, though most have their own fatal limitations.
An indicator on where the bottom of the screen scrolled to, so I don't need slow animations or incremental scrolls to find where I left off reading.
(The linked script is not working on all pages and sometimes blocking klicks, I just threw it together to try if the Idea works. I think the principle works really really well.)
Maintaining compatibility is good, but at some point we need to stop and make a new design.
By the way here are the things I'd like to get fixed too:
- make a distinction between same-domain and cross-domain requests (use another HTTP method for cross-domain POST request) so all sites get XSRF vulnerability fixed
- make cross-domain requests anonymous by default
- make cookies unaccessible to Javascript by default
- stop JS loading from blocking the page so we can put script tags in the header where it makes more sense
- make as much events asynchronous as possible
- fix keyboard events, key codes and mouse buttons numbers
- make it impossible to change window.opener.location and windows.parent.location
- add CSS rules to set width for a column in a table, not for cells
- add error reporting so if some resource (like a script) fails to load the user gets a message that the page is broken
What is this referring to (I know what Mozilla and XUL are, didn't know there was a tiff about it)?
Basically, the way it's typically done when using desktop widget toolkits.
But most websites are still made so that there is only one document-wide scrollbar.
The way I see it, most websites fall into two broad camps of layout and associated scroll behavior:
1. Articles
2. Dashboards
You're either trying to present some kind of information as text like most news sites, forums, etc. or you're doing a "web app." It's really less "either-or" and more of a spectrum, but if we're talking about compartmentalizing an entire website into scrollable containers this is where things fall.
For an article style website, you'd want either the entire page or the majority of the content on the site in a single scroll container. Perhaps you're a news site like Medium that has certain UI elements that persist during scroll. Normally you'd just position:fixed those elements, but let's say instead you decide to position your fixed nav and whatnot normally and instead scroll the article inside a box. You run into a few problems:
1. You don't get the benefit of compartmentalizing your scroll listeners because whatever blocks scrolling blocks whatever people care about anyway
2. Designs like this are really hard to get right. Positioning and sizing these elements is notoriously hard to fully test and easy to break. In mobile safari, for example, the showing or hiding of the UI is determined by scrolling the main page. Scrolling within a container does do this. Also Safari uses MacOS/iOS's native UI scrolling system, so scrolling really fast bounces back. However, your box may not bounce, the entire page will if they flick the box and there's still scroll velocity left when they get to the bottom. This bounce CAN affect the visible state of the UI and can really mess with innerHeight calculations. With multiple scrollable boxes on a page, dealing with touch input can be a huge pain. I'm sure you've seen websites that do this incorrectly, where things don't scroll like you think they do. Have you ever tried to scroll a page that had a poorly implemented map on it and scrolled the map instead? In fact, because of this behavior, early versions of mobile safari simply refused to scroll scrollable containers on drag. By default, it would only scroll the page itself and you had to drag with two fingers to scroll inside of Divs and Iframes.
Most sites I browse fall into this camp. The second camp is dashboard UIs.
The canonical way to do a dashboard with multiple scrollable elements is to do just that, which already has the optimization you suggested applied. However, a lot of designers these days actually try to design dashboards using the browser's native page scroll as much as they can. It turns out that there is a lot of complexity to that approach that makes development hard and breaks the user's expectation for how websites work. The story editor of the CMS we use at my college newspaper actually becomes unusable if you trigger the safari page bounce while a mouseover menu is open. They're in the middle of developing a new version, where the story is the page and the UI is position:fixed instead of everything being compartmentalized like you suggest, as it is now.
Back to native scrolling. There's a lot you can do to help the browser along.
The biggest thing you can do is utilize window.requestAnimationFrame(). Your function will be queued up and called when it is convenient for the browser, usually 60 times a second which is fast enough to render things smoothly without firing every time the onScroll event occurs, which can be hundreds of times a second on certain browsers.
Check out the MDN Doc for an example of how to do this. https://developer.mozilla.org/en-US/docs/Web/Events/scroll
I think that many sites wouldn't use individual scrollable elements correctly. Much like sticky headers, you end up with an upside-down L-shaped (like this: |‾) area of static, individually scrollable content. Your viewport shrinks to 75%. That's annoying on desktops at best and pretty much unusable on mobile at worst. It's reminiscent of Toolbar Explorer[0].
If you can use individual elements nicely, go ahead! I believe that if the trend caught on, it would be worse for everyone.
[0]: https://c1.staticflickr.com/3/2040/1924189728_668c4bc4e2.jpg
Another thing that often annoys me is how sticky headers break text search. When you search and the browser scrolls just enough to get the hit "on the page", but still covered by the sticky header. The problem is: not using proper frames. Sticky covers part of the other frame. Bad.
I don't see a sidebar covering content. Of course the sidebar takes some space, but as long as it's not over the content that's a different issue IMO.
Or just don't do "frames"/"overlays"/"sticky". That's still better than messing with the global scrollbar (like Twitter does for example) and totally wrecking user experience.
I don't think artificially constraining body is the answer though.
Neither is capturing the mousewheel event and checking Element.scrollTop and/or e.deltaY tbh, and I've been asked to do that in living memory for scrollable modals. Trying to eliminate that jank on that was fun.
There should be a clean way to disable scrollwheel propagation, but a very quick web search indicates there may not be.
But yeah, mousewheel scroll propagation is a pain, and you can't even cancel a regular scroll event even after shimming it for the wheel.
Scrolling works well at a basic level, but could definitely do with some love.
Nice article, but comically ironic.
Mouse wheel scrolling still works on Chrome but not on Firefox.
You don't set your scrollbar to fade out when not in use. O hai Pocket. Ficks that shite plz.
You don't have an "untouchable" scrollbar. It's not merely a graphical decoration, it's a motherfucking control element. O hai Pocket.... Esp. your non-incremental-searchable tags list that takes me a full fucking minute to scroll up or down.
You don't turn a vertical scroll action into a motherfucking horizontal scroll. I forget which academic article site that is, but I'm blackholing your ass on DNS next time I land there.
You don't nuke the right-hand-side scrollbar, and replace it with a horizontal-across-the-top motherfucking stripe to indicate how far down the fucking page I've read. O hai Bloomsburgs.
You don't have fixed headers and footers. Fuck that shit. Firefox Reader Mode fixes that, usually. Pocket is an alternative.
You don't change the width, colour, buttons, or any other elements of stock scrollbars.
I am too old to be too old for this shit.
setInterval(() => { var start = Date.now(); while (Date.now() - start < 500) {/* wheeeee! */} }, 1000);
Scroll down to move down feels completely wrong. In my head I understand that you're moving the 'viewport' down, but my brain is focused on the viewport's content, not the viewport itself. So my interactions should be with the content not the contents viewport. Not sure if that makes sense.