I wish people who made webpages trusted browsers to scroll. The number of sites that play with the scroll speed and consistency by hijacking scroll events makes me doubt whether the designers spare a passing thought for usability.
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?
> There's nothing more annoying than a web designer saying "I know better than you" and re-implementing features. Because they're usually wrong.
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.
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.
I wish the same thing, but for desktop applications too. There are some that implement their own scroll and it's the most annoying thing ever, because it makes the scroll bar unusable. As the article point out, it's vastly different than scroll wheel, touch and keys.
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.
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
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?
> There's nothing more annoying than a web designer saying "I know better than you" and re-implementing features. Because they're usually wrong.
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.
Webpages that mess with scroll behaviour invariably annoy me as much as those that autoplay videos, open popups, etc. I just instinctively ctrl-w that shit immediately.
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.
I agree with you — BUT, I have conducted a fair amount of user tests where someone will not scroll. It's often an older demographic, but I've seen 30 year olds fall into it as well.
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.
This is a pet peeve of mine too and I agree with all your points. But I think more often than not, such custom scrolling may happen as a result of trying to control something else, like some infinite scroll with virtualization that would normally start shifting elements and make the scrollbar behave funny.
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 :)
Scroll highjacking can be done to avoid partial content being displayed on the screen.
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
yeah I find any cursor hijacking to be very frustrating, and always results in a "worse" user experience. A big one is Google search results, where a down arrow increments a step through the result list, and not an immediate page scroll.
Back in the day browsers competed over user friendly features like popup blockers, even though that technically breaks a web API. Today browsers are so terrified of breaking a web API that they have allowed the mobile web to become a cesspool. Browsing most sites has become intolerable, the more modern the worse. Scrolling freezes for seconds at a time, whole pages jump up and down constantly while you read, scroll-hijacking ads interrupt you, fixed position headers obscure half the page and appear/disappear at random, "mobile-friendly" sites are more often than not worse than desktop sites even on mobile (plus they break deep links), and I can't be the only one who's noticed that even the old popup blockers have stopped working!
(Author of the post and Microsoft Edge team member here.)
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.
Browsers outside the mainstream are still trying. I'm typing this on the Brave browser[0] and it's fantastic at dealing with those obnoxious sites. It has a built in ad blocker and total JavaScript blocking for a site is just 2 taps away. It's amazing how much smoother sites become when you've blocked all their anti-user shenanigans.
I wonder who tests those mobile websites and what devices they have. The other day, my partner and I tried a popular one in Spain (atrapalo.com) in four different Android devices, including an HTC One M8 phone and a Samsung Galaxy Note 10.1 2014 Edition tablet, which were high tier not that long ago. We found it basically unusable in the four devices and ended up going to the PC...
> There's plenty of detail and pretty much no fluff. More of the same please Microsoft.
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!
There's a ton of missing stuff for even the simplest of applications really, even basic paging controls. Eg. you can present <title>...</title>, <link rel=next ...> and <link rel=previous ...> to search engines, but you typically can't pull these values into your content for display. Technically you can overwrite user agent styles on head elements ([1]; just checked this still works), but it isn't rendered as link/has no link action on Chrome, and isn't rendered at all on IE 10 and lower.
I mean, these features are as basic and RESTful as it gets.
> Hate the trend of dynamically loading content when scrolling down.
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).
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.)
The only thing worse than having a broken scrolling experience on mobile is imagining just how much extra data was wasted to download that useless script so that a crappy mobile experience could be had, and how much battery was wasted running the unnecessary script so that a crappy mobile experience could be had. There is complete priority inversion on the web and I am so sick of it; my device should have ample controls to obey ME and not the whims of some random site.
This is the kind of "accessible take on fundamentals that you might not have even realised were fundamentals" documentation that I'd like to see more of. It took me a few years of web development to even start thinking about just how, exactly, the concurrency model of the web functions.
I'm not sure why anyone is using scrolling events for any standard websites at all. It's much easier to have a function on timer that detects the current viewport position and acts accordingly. The code is simpler, the performance is better, and it's way more future-proof.
It looks like a poor design desicion made 20 years ago (that wheel event is synchronous and must be run before scrolling) leads to all major browsers code becoming unnecessary complicated. I think it would be better to discard that design and make a new event system that would be used with new pages (and don't waste developers' resources to optimize old pages).
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
The situation here is IMO similar to Mozilla vs XUL, except when they actually decided to drop it a ton of people decided to drop firefox. I'm talking about compatibility in general here, not js scrolling specifically.
Bold claim (not a professional webdesigner): Many problems with performance and usability would go away if people made more websites where the document is 100% width and height and contained boxes are individually scrolled. ("Like frames").
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.
You must have forgotten the iframe hell that was the early aughts. There are some sites that could benefit from individually scrolling elements. If you have a navigation pane that doesn't hide, it would be hell to have all of the navigation links above the fold while all of the relevant content exists multiple scrolls/folds/pages below.
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.
My own personal bugbear with individually scrolling elements is when the user hits the min/max scrollHeight of an element and the event immediately propagates back up to the document element, scrolling the whole page. This probably isn't actually what they were trying to do if it's not full-width body content, and making that scrollable seems like a pretty terrible idea in the first place since default scroll behaviour is otherwise OK.
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.
Maybe, but probably not for most sites. My 2 cents as a tudent/freelancer who's been working on a project that does weird shit with scrolling because it has to.
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.
The constant finger-pointing to the shortcomings of other browsers was getting particularly annoying — especially when IE and Edge are historically the lowest performing, late-to-the-game browsers.
IE/Edge has prioritized scrolling performance more than other browsers on Windows for a long time now (mainly because Microsoft cares more about touch on Windows than other browser vendors do).
I feel that the mechanics of scrolling need to be reworked. I have to do a number of tweaks to get free scrolling to work as I'd like, as opposed to the default line-by-line type scrolling. Even line-by-line scrolling has issues, such as not being aligned with the lines of text or block elements on a web page. Scrolling ought to have different control options as well, say ^Scroll scrolls through paragraphs or headings.
There’s a curious anomaly, though: if you try to scroll using touch screen scrolling, the page happily moves up and down, even while JavaScript is blocking nearly everything else on the page. This also works for touch pad scrolling, mouse wheel scrolling, and click-and-drag scrolling (depending on your browser).
Mouse wheel scrolling still works on Chrome but not on Firefox.
The first rule of fucking with scrollbars is you don't fuck with scrollbars.
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.
Only it it can prove that Date.now() has no side-effects or that the loop actually ends. (And Date or Date.now() might not be the same things that are usually expected, since anything in JS can change.)
"User scrolls with two fingers on a touch pad" This was so weird for me at the beginning haha Always mixing up and down :D Anybody else had this problem?
[+] [-] afandian|9 years ago|reply
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?
[+] [-] anamoulous|9 years ago|reply
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.
[+] [-] lloeki|9 years ago|reply
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.
[+] [-] DiThi|9 years ago|reply
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.
[+] [-] LoSboccacc|9 years ago|reply
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?
[+] [-] CaptSpify|9 years ago|reply
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.
[+] [-] jdiez17|9 years ago|reply
[+] [-] xorcist|9 years ago|reply
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.
[+] [-] scoates|9 years ago|reply
[+] [-] accountface|9 years ago|reply
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.
[+] [-] SonicSoul|9 years ago|reply
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 :)
[+] [-] tambourine_man|9 years ago|reply
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
[+] [-] helb|9 years ago|reply
[+] [-] retube|9 years ago|reply
[+] [-] modeless|9 years ago|reply
[+] [-] nolanl|9 years ago|reply
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.
[+] [-] chongli|9 years ago|reply
[0] https://brave.com/
[+] [-] Al-Khwarizmi|9 years ago|reply
[+] [-] nkkollaw|9 years ago|reply
> Today browsers are so terrified of breaking a web API that they have allowed the mobile web to become a cesspool
[+] [-] onion2k|9 years ago|reply
[+] [-] dualogy|9 years ago|reply
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!
[+] [-] noir_lord|9 years ago|reply
[+] [-] stupidcar|9 years ago|reply
For all its advances, the web platform is still incredibly primitive in some areas.
[+] [-] currysausage|9 years ago|reply
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/position#St...
[+] [-] tannhaeuser|9 years ago|reply
I mean, these features are as basic and RESTful as it gets.
[1]: https://mathiasbynens.be/notes/css-hidden-elements
[+] [-] lmm|9 years ago|reply
[+] [-] nuclx|9 years ago|reply
[+] [-] username223|9 years ago|reply
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).
[+] [-] anotheryou|9 years ago|reply
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.)
[+] [-] narrowtux|9 years ago|reply
[+] [-] makecheck|9 years ago|reply
[+] [-] m_fayer|9 years ago|reply
[+] [-] romaniv|9 years ago|reply
[+] [-] codedokode|9 years ago|reply
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
[+] [-] iaml|9 years ago|reply
[+] [-] jstimpfle|9 years ago|reply
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.
[+] [-] noxToken|9 years ago|reply
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
[+] [-] ry_ry|9 years ago|reply
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.
[+] [-] chuckdries|9 years ago|reply
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
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] joshiefishbein|9 years ago|reply
Nice article, but comically ironic.
[+] [-] contextfree|9 years ago|reply
[+] [-] syphilis2|9 years ago|reply
[+] [-] RyanMcGreal|9 years ago|reply
Mouse wheel scrolling still works on Chrome but not on Firefox.
[+] [-] dredmorbius|9 years ago|reply
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.
[+] [-] barrystaes|9 years ago|reply
setInterval(() => { var start = Date.now(); while (Date.now() - start < 500) {/* wheeeee! */} }, 1000);
[+] [-] ygra|9 years ago|reply
[+] [-] mustafabisic1|9 years ago|reply
[+] [-] combatentropy|9 years ago|reply
[+] [-] _pmf_|9 years ago|reply