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.
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.