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 a battle I've fought a zillion times. It's just so hard for some designers, who are used to a world where originality is a good thing, to understand that in UX originality is a liability.
The solution here is simple -- lobby W3C to include custom scrollbar colors in the CSS specs, then call out Mozilla for not following the standards.
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.
If the "designer" only cares about the look of their site, then they're an artist, not a designer. Usability and accessibility are intrinsic parts of web design.
And if their brand is "confusing and hard to use" or worse, "glitchy" then I guess making their own scroll bars is appropriate.
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.
Obvious solution is obvious. If the user is using Firefox, instead of replacing the scroll bars, replace the page with a message telling them to switch to a better browser. That way everybody wins and it's so much less work.
Or more obviously - if a browser works a certain way, and the user has chosen to use it, let it be. If the designer doesn't like it, well - the user chose to use this browser, and they choose to use your site. If you start trying to change one of their choices, they might change the other.
Maybe fix it then? Or better yet, don't fiddle with users' UI items. The scrollbar is the same everywhere on my desktop, why fiddle with a thing that the user's really used to?
Because designs on the web are different from those on desktops and big white scrollbars on a dark design look horrific? Also, because you want your design to work nicely irrespective of the browser and scrollbars and dropdowns make that really hard.
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).
> Because designs on the web are different from those on desktops and big white scrollbars on a dark design look horrific?
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?
>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.
There's a difference between changing behaviour and changing the design. I'd imagine that most designers that design without scroll bars have no idea what the devs are going to do to change behaviour.
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.
There's a difference between the whole window and an element within the page. We have a single page app that still had scroll bars for subsections in the sidebar and quick frankly, it's embarrassing.
It truly sucks, as you said. Also, the web pages are within my browser's chrome, which occupies about a third of my screen, and behind it there's my wallpaper, and behind my screen I've a nice champagne-colour wall and some books, pens, and other stuff. What will you do if your design looks off in front of them? Change them too? Should the browser allow you to change the wallpaper?
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.
This is not really a bug but a wontfix (seemingly). Firefox has its own toolkit so it should be easier than writing a whole slew of JS to fix that bug (a.k.a. add this feature).
Would not it be better to style the scrollbar with CSS only in browsers that support it? That would be an example of progressive enhancement and adaptive markup.
For me, fast scrolling is more important than colored scrollbar.
It seems there's only a small overlap between the people suffering and the people being able to solve this.
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.
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.
With the new AMP articles, Google News has become almost unusable to me for this reason. I used to love it, but now the experience is all janky and I constantly end up navigating to some other article instead of backwards when I use iOS' swipe back gesture.
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.
Near-ubiquitous floating headers (and even footers) have made full-page spacebar scrolling practically useless on most pages for me now, at least under Chrome on OSX. You always have to scroll back a little bit to see a line or two of content.
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...
You're right, some sites manage to do it without breaking full page scrolling. One of these days I'd like to sit down and figure out the specifics (of both right and wrong ways) and write a good comprehensive medium post with clear instructions on doing persistent headers correctly.
Of course if someone else beats me to it, that's fine too...
Agreed. I have a great Apple mouse and trackpad. But I still use space when scrolling.
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.
- Click and hold outside the thingy usually performs consecutive page jumps to the point (Firefox, Chrome)
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!)
I mean the buttons in the GUI scroll bar, that have little arrows or triangles in them. They're way too small and too far apart to be used effectively. For that reason some UI toolkits had both buttons together at the bottom.
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?
Accommodate? They chose to make something that runs in a web browser so they should make something that works in a web browser. If I choose to use one with big scroll bars, that's up to me.
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?
I think it's sadly like that comment about Uber a few days ago -- it's a question of staying insane longer than competitors can remain solvent. The web will eat everything sooner or later.
As someone who actually uses scrollbars, I like scrollbars to be wide enough to actually use, especially when they're not against the edge of a maximized window.
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.
There is some UI chrome that is the responsibility of the browser, not the content within it. Back button, refresh button, scroll bars, address bar, etc. These should be off limits to the content within the web view.
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?
> 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?)
Forced? The browser and OS are the one thing that the user DOES choose! If I don't like the way it works, I can use another one or change the config. If the web designer chooses to change the scrollbars on their site, I have no choice when using their site.
I think it betrays a pretty limited understanding of design, to declare a design task impossible because color-coordination can't be scoped in. Prioritizing aesthetics over function usually defeats both.
Meanwhile in the real world aesthetics play a big role in corporate/brand identity and corporate that care enough will build horrendous kludges to work around the limitations of browser styling, but once again it has proven a fool errand to argue with the ivory tower warriors that inhabits the websites for the technically minded.
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
> Meanwhile in the real world aesthetics play a big role in corporate/brand identity and corporate that care enough will build horrendous kludges to work around the limitations of browser styling
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.
I recently discovered how Facebook do their fade-in thin scroll elements in the messenger[1] web app. They actually size the DIVs too wide by about 20+ pixels, then they alter the z-order so that the DIV edge (where the native scrollbar is) is hidden under another DIV (or over the window bounds). Then they overlay their own scroll bar element at the new visible edge of the DIV and hook it to the div scroll event.
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?
Non-macOS-user here. I always wondered why the Messenger webapp looked so weird. It just dawned on me that they're trying to emulate Apple design to the t. It's like running a Java app with the emulated look-and-feel for the wrong OS.
This actually sounds a pretty low cost way to make an important visual change without abandoning the behavior underneath it. User don't know or care about it. Until there is a standard way to do this, a funky CSS hack that adds a few otherwise unneeded elements is more cognitive load for the programmers, but users don't care. And eventually weird kludges like this influence what features get worked on. I hope!
If i am your user, i will hate your second scroll bar. 1. Too small, 2. don't know were click. 3. First one clean scroll bar second waste thinking cycle to know it is scroll bar
There is a new trend of full-page slide that scrolls but without the scrollbar. I'm seeing a lot of this type websites lately. Though I love the classic scrollbar.
> 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.
I think that's a different issue. If people don't know they need to scroll (your false floor example), that's a failing of the visual language, so it's entirely appropriate to put an explicit message "you can scroll" to make up for the failure of visual language.
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 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
Surely the navigation should be decoupled from scrolling. I think this happens because people try to shoe-horn multiple pages into one page. IMHO these should be separate pages, not one page with pseudo-subpage content. You could use mouse events, or click buttons, or touch events to navigate between them. Perhaps this comes out of the hinterland between touchscreen scrolling and gesturing.
What if I want to zoom in or out on the slide for reasons of accessibility?
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...
I've got four popups/notifications going on this site: a "Show notifications?" from the browser, a JS ad that overlays the whole page, an "Uso de cookie" banner at the bottom, and a "Would you like to translate this page?" from Chrome (ok, this one is not their fault, but still that's a lot of stuff to deal with just for one webpage).
Most cases of bad scrolling performance could be fixed if browsers would accept some web API breakage and move scrolling to its own thread that JavaScript, layout, and image loading can't ever block.
> 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!
>except maybe SharePoint-related, that was quite the mess a few years back, dunno about today tho
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.
With an ever-declining IE/Edge market share, I usually rely on the principle of progressive enhancement and accept that certain non-essential features will only be available to users of modern web browsers (unless, of course, a specific project has an unusually high number of IE/Edge users, e.g. intranet applications).
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.
Yeah, relying on progressive enhancement is obviously only viable when we talk about nice-to-have features. Sticky headers will often fall into this category.
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.
XUL will be dropped soon in favour of WebExtentions, and it doesn't offer as much flexibility as XUL. This means it won't be possible to create addons like tree-style tabs for example.
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.
It's true that the usable screen area shrinks. It also shrinks with sticky headers or similar... If that's a problem, maybe add some Javascript to make the headers optional?
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 know that problem. Browsers should try to zoom everything proportionally, and I think they have gotten quite good at that (using Firefox almost exclusively).
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.
Can't reproduce a problem with Firefox and don't have a phone handy. Maybe you can post a screenshot? The sidebar zooming too is what I would expect. At some insane zoom level the sidebar goes away, which is probably due to CSS and could be intended.
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.
This should no longer be the case, at least for Safari, Edge, and Chrome. All of these "detach" fixed/stick position elements from the viewport once you start zooming.
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.
I think constraining body (to 100% width and height, that's what you mean right?) is fine, however it's not solving the general problem of scrollwheel propagation.
There should be a clean way to disable scrollwheel propagation, but a very quick web search indicates there may not be.
Yeah, sorry, if it's 100% of the viewport, kinda like an old fashioned frameset, you won't get the scroll propagation thing - if it's 100% of html,body you still hit it of course.
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.
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.
(Author of the post here.) It may depend on your OS or your Firefox version! :) I spoke with some Firefox folks after publishing this piece, and it turns out they've fixed some things in Firefox 52, notably for touch-enabled Windows laptops.
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.)
It's not "NOP" code because it has an observable side-effect, unfortunately: time passing. This can be trivially observed with another interval timer at smaller resolution than 500ms.
Javascript doesn't by default do any optimization by removing or modifying code if you don't run the code through some sort of preprocessor or compiler.
"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?
I really didn't have this issue when it became commonplace. It felt natural. Like a piece of paper sitting on a table. If i want to "scroll down" the paper by moving it up, i would touch the paper and move it up.
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.
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?