[docs-infra] Double vertical scrollbars

[sangauit]

Related page

• https://mui.com/joy-ui/react-autocomplete/
• https://mui.com/material-ui/react-autocomplete/

Kind of issue

Other

Issue description

Double vertical scrollbars

Context 🔦

Going to any pages under Components sections on Joy page

I use Edge Version 116.0.1938.54 on linux-x64, the same with Firefox 116.0.3 on linux-x64 Docs version: v5.0.0-beta.4

[brijeshb42]

Could you add a video of the bug that you are describing?

[sangauit]

You can go to the attached link and the issue will occur, no need video, btw see the attached file

[danilo-leal]

Hey @sang-au! Are you referring to these scrollbars? Or is it something else? Want to understand if it's something Autocomplete-related, given that was the page you linked, but I'm sensing it's not.

[brijeshb42]

This is expected since content is more than the available area. On MacOS, it's not an issue because scrollbars are hidden by default. Maybe there might be a similar setting at OS level to hide scrollbars by default in your OS.

cc: @danilo-leal

[danilo-leal]

Yup, I'm aware! Wanted to see if that's really what they're referring to because if it is, it's just the docs scrollbars ⎯ not a bug/problem (and not Joy UI-related, too).

[sangauit]

As the topic. It related to docs and base on the context go to any page under components section. It related to docs only.

[sangauit]

I did not see this issue on previous version

[danilo-leal]

@sang-au would you mind clarifying it a bit more? I'm still a bit unsure what you're referring to 😬

[sangauit]

Just the issue on the doc page, that show 2 vertical scrollbar on the right side, not related to any component!

[danilo-leal]

@sang-au Got it! Thanks for the clarification! As we mentioned above, I don't think that's a bug/problem ⎯ the two scrollbars are there because one is for the table of contents & the other is for the entire page. Is that getting in your way somehow, causing navigation experience issues?

One tentative solution would be for you to hide the scrollbar at the OS level (happens automatically on MacOS). Let us know if you have any other suggestions, too. Otherwise, I think we can close the issue!

[sangauit]

I agree that is not a bug. However, an issue like that should not occur on the UI library's docs page like MUI, LOL.

[danilo-leal]

I see... my point is: is it an issue? I don't think the table of contents scroll should be tied to the entire page scroll ⎯ having a scrollbar allows you to scroll it independently from the page. If you were expecting just one scrollbar, that would mean that you'd need to go to the bottom of the page to see more TOC content, which is not a great experience. Does that make sense? Were you expecting something else?

[oliviertassinari]

Ideas:

1. We could make the table of contents items a bit denser, there is maybe too much gap between each item.
2. We could make the table of contents scroll container behave like on macOS: https://github.com/mui/mui-x/issues/510, e.g. https://www.radix-ui.com/primitives/docs/components/dialog

https://github.com/mui/material-ui/assets/3165635/4ed2b7a9-dacb-4d9b-b680-112b593f17a2

3. We could split the Autocomplete docs page into more pages in Base UI, and move more content away from Joy UI & Material UI to Base UI: https://github.com/mui/base-ui/issues/20.
4. We could move the sponsors back to the main side nav. https://github.com/mui/material-ui/issues/38033#issuecomment-1703075284 using less space in the tocs.

[samuelsycamore]

I'm not sure there's any way to work around this on pages that are especially long. (And do we really need to?) Ideally we'd be able to either a) extract some content from one page to create a new one, or b) revise the content on the page to include fewer headers. In the case of the Autocomplete component doc, for example, I don't think either of these is an option. Tighter density might help some pages, but there could still be double scrollbars on especially long pages.

[danilo-leal]

Yup, agreed! Making sure content is well distributed and organized is always positive, and we should do so, but unless the second option there ("...behave like macOS") does do something to the scrollbar (saying that because it's not clear to me what behaving like macOS in this context means exactly), I don't think we'll be able to avoid it. At the end of the day, not sure if it's a problem at all 😬

[oliviertassinari]

saying that because it's not clear to me what behaving like macOS in this context means exactly

@danilo-leal illustration added https://github.com/mui/material-ui/issues/38710#issuecomment-1702888377.

[mbrookes]

We could make the table of contents scroll container behave like on macOS

Pedantically, not quite like macOS in the Radix example, as the scrollbar appears on hover, not on scroll, but that seems like a valuable affordance in this instance.

[auvansang]

Today I see the docs on https://material-web.dev/components/button/ so MUI can apply some thing like bellow