اسکرول بار اسٹائلر

Two syntaxes, because neither is enough

The standard properties — scrollbar-width and scrollbar-color — are the only route Firefox offers, and they are deliberately limited: a keyword for the width, a pair of colours, nothing else. No radius, no exact pixel size, no separate hover state.

The WebKit pseudo-elements can set all of that, and Chrome, Edge and Safari have understood them for years.

So the [msm_tool slug="scrollbar-styler"] emits both, and the two will never look identical. Firefox rounds the width to its own idea of thin or auto and ignores the radius entirely. That is by design rather than a bug, and it is worth knowing before you spend time trying to reconcile them.

Scope it to a panel

The rule applies to whatever selector you give it, and that choice matters more than it sounds.

Applied to the whole page, a restyled scrollbar affects every reader on every screen. Applied to a code block, a sidebar or a scrolling table, it affects only the component you meant. The main page scrollbar is a control people rely on and have muscle memory for; there is rarely a good reason to redesign it.

A thin scrollbar is a smaller target

Both the thin keyword and a narrow pixel width shrink the area a person has to hit with a mouse. On a control used for navigation that is a genuine cost, not an aesthetic one.

Motor impairments make it worse, and so does a trackpad, and so does a large monitor where the scrollbar is a long way from the pointer. On long pages, leaving the default width is usually the right answer.

Contrast between thumb and track

The thumb is an interactive control, which means it is held to 3:1 against the track rather than to any decorative standard.

A thumb that barely differs from its track disappears against the page — and the fashionable version of this style, a very pale grey thumb on a white track, fails comfortably. If the scrollbar is worth styling at all, it is worth being visible.

Overlay scrollbars ignore most of it

macOS and touch platforms draw scrollbars as overlays that hide when idle and appear briefly during a scroll. They are drawn by the operating system in its own style, and most of what you set does not apply.

Treat scrollbar styling as an enhancement on pointer devices, not as a layout you can depend on. A design that only works when the scrollbar is a specific width will break on half the machines that visit it.

Do not hide it

It is possible to make a scrollbar invisible while keeping the element scrollable. It is almost always a mistake.

The scrollbar is the only indication that there is more content, and how much. Removing it means some users never discover the rest of a list, and it removes the ability to drag to a position. Horizontal carousels with hidden scrollbars are the usual offender: what reads as a clean design to the person who built it reads as a truncated list to someone who does not know to swipe.

If the scrollbar is visually intrusive, style it to be quieter. Do not remove it.

What is worth styling

• Code blocks and pre elements — a default scrollbar inside a dark code block looks out of place, and this is the clearest case for restyling.
• Dark-mode surfaces — a light system scrollbar on a dark panel is jarring, and scrollbar-color alone fixes it in every browser.
• Scrolling panels inside an application shell — sidebars, drawers, data tables.

For the last two, scrollbar-color on its own is often the whole answer. It works everywhere, it needs no prefixed block, and it solves the actual complaint.