Replaced Native Scrollbars with Tailwind Scrollbars

[jestinjoshi]

Implements #1247

Changes Made:

• Replaced native scrollbars with Tailwind scrollbars for consistency
• Added hover effect on 'Delete Account' button

cc: @justinfar

[zachgoll]

@jestinjoshi @justinfar this will add persistent scrollbars to the app. Are we okay with that?

@jestinjoshi I think rather than applying these across many places, we should just apply this globally:

*::-webkit-scrollbar {
  width: 4px;
}

*::-webkit-scrollbar-thumb {
  background: #d6d6d6;
  border-radius: 10px;
}

*::-webkit-scrollbar-thumb:hover {
  background: #a6a6a6;
}

[Shpigford]

Not a fan of the persistent scrollbars and not sure cross-browser/platform styling of the scrollbars is a big priority.

[justinfar]

yeah I'm not a fan of the persistent scrollbar either

I'd lean more towards making this change about refining the scrollbar to be consistent with Tailwind rather than keep it showing up whenever we have a scrollable area

[jestinjoshi]

Oops, I closed this PR by mistake, but honestly, it was not the best solution to the problem anyway.

@zachgoll, I like the global styling approach. It’s a great way to future-proof.

Regarding the persistent scrollbar, I think the difference here is that all of you are on macOS, where scrollbars are handled pretty smoothly by default. I’m on Windows, where big, chunky scrollbars (persistent by default) can be a bit of an eyesore, especially on an otherwise beautiful UI. If Maybe is aiming to serve a global user base, it might be worth considering the Windows experience too.

For priority, I agree with @Shpigford that it’s probably not a blocker/high-priority task. It’s up to you whether to tackle it now or later.

cc: @justinfar @zachgoll @Shpigford

[zachgoll]

@jestinjoshi what browser are you using?

Also, I had thought the overflow-auto TW class would override any OS-specific behaviors. Does the existing app have persistent scrollbars for you?

A screenshot / recording would be super helpful here if you could provide.

[jestinjoshi]

@zachgoll I'm using Chrome on Windows.

I've added the screenshots here: #1247 (comment)

Just to clarify, by persistent scrollbars, do you mean the scrollbar stays visible even if the UI isn’t overflowing?

[zachgoll]

@jestinjoshi no, when I say "persistent", I'm referring to the case where there is overflowing content and the scrollbar persists even when the user is not actively scrolling the container (i.e. "auto" behavior):

CleanShot.2024-11-11.at.16.38.18.mp4

If we can find an simple/easy way to preserve this behavior with the custom scrollbars I think it makes sense to do, but from what I'm seeing, adding these custom classes in break this existing "auto" behavior.

[jestinjoshi]

Thanks for clarifying. I just wanted to confirm that I understood your point on persistent scrollbars correctly.

This behaviour is not available on Windows. The scrollbar is always visible, even when the user isn’t actively scrolling within a container. Also, each browser on Windows handles scrollbar styling differently, leading to inconsistency. I’ve added a video below showing how the scrollbar looks in Chrome on Windows.

I think one way to tackle this issue would be to apply custom scrollbar styling only for Windows 🤔

Screen.Recording.2024-11-11.170830.mp4

[zachgoll]

@jestinjoshi I understand this is not available on Windows, but by adding these changes, we are removing it from Mac too, which is not ideal. My main concerns are preserving the "auto" behavior on Mac and keeping the solution here very simple.

The best solution is something that allows for custom scrollbars while preserving "auto" behavior on Mac. As a fallback, I agree that we could do a "Windows only" custom scrollbar if the implementation is simple and straightforward.

[jestinjoshi]

@zachgoll I agree with preserving the Mac behaviour. Implementing 'Windows-only' styling should be straightforward.

I'll start a new PR for this since the current one is merging commits from my main branch.