This view comes mainly from the Mac environment, where scrollbars are usually displayed briefly when the content is first displayed and then hidden. If scrolling is performed (triggered by the user or otherwise), the scroll bar reappears. Only the handle is visible (as semi-transparent, rounded black bars). no arrows or gutter. If the cursor is over the displayed scroll bar, it will widen and allow you to drag with the cursor. At no time does the size of the content change. It behaves as if the scroll bar is not present and the scroll bar is rendered at the top.
This applies to the use of trackpad or trackpad-like input mechanisms (such as a laptop). When you use a mouse, normal scroll bars are still displayed by default.
Of course, this also applies to mobile devices. iOS uses almost the same behavior (minus cursor interaction). In fact, I think it started on iOS (where scrollbars were too small to type reliably) and migrated to MacOS.
Overall, this has advantages and disadvantages:
- The lack of scrolling space simplifies the page design (less disturbing elements) and allows more space for the content, especially if there are multiple scrolling areas.
- Mac users are used to this behavior and expect it.
There is no jump in content size when an area suddenly becomes scrollable, which also eliminates a frequent ambiguity in which a scroll bar may be needed as long as it is visible and is not needed when it is hidden (e.g. of text break).
On the negative side, as mentioned earlier, you'll need to find another way to indicate that the content is scrollable. No such problem for the main body of a web page, as this is expected anyway, but depending on user expectations it can be a problem for internal content. The initial lightning helps, but is not always enough.
- User interaction to move to another location in the document is cumbersome. The user must move the cursor to the position where the scroll bar is displayed, scroll gently with the mouse wheel or "2-finger scroll", grab the displayed scroll bar, and drag to the desired location. Momentum scrolling helps in some cases to avoid this.
- Since the scroll bar is displayed on a transparent background, it may be difficult to detect a dark background. MacOS offers a white alternative scroll bar that can be used in this case (I think browsers automatically switch to them if the background is sufficiently dark, but not 100% foolproof). In addition, it gives the bar a subtle glow (or a shadow), which appears to be fail-safe enough.
If possible, stay with such things naturally with the browser-native components. They ensure that every user gets a natural experience for their platform (I've certainly seen many sites trying to replicate momentum scrolling and elastic scrolling with gruesome end results). Mac users will not be grateful that you enforce visible scrollbars where they would not expect them, and Windows users will not thank you for hiding scrollbars where they would expect them.