In T245734#5920569, @Volker_E wrote:

Instant question on acceptance criteria “sidebar should be sticky” – when the sidebar would be sticky, we'd end up with two vertical scrollbars (in sidebar and main content) when canvas height < sidebar height, which seems relatively common. Are we set on this?

In T245734#5923010, @ovasileva wrote:

In T245734#5920569, @Volker_E wrote:

Instant question on acceptance criteria “sidebar should be sticky” – when the sidebar would be sticky, we'd end up with two vertical scrollbars (in sidebar and main content) when canvas height < sidebar height, which seems relatively common. Are we set on this?

Agreed that scrollbars would not be okay. Would there be a way of avoiding this? Maybe have some max length of the sidebar and if it goes above that it's no longer sticky?

In T245734#5923661, @alexhollender wrote:

In T245734#5920569, @Volker_E wrote:

Instant question on acceptance criteria “sidebar should be sticky” – when the sidebar would be sticky, we'd end up with two vertical scrollbars (in sidebar and main content) when canvas height < sidebar height, which seems relatively common. Are we set on this?

In cases where the contents of the sidebar are taller than the screen having a scrollbar on the fixed sidebar is a natural result. Dependent upon user settings the scrollbar will only become visible when someone is interacting with the sidebar element. If we want to we can style the scrollbar (supported by all webkit browsers) to make it more subtle (https://webkit.org/blog/363/styling-scrollbars/) Example from Gmail:

Check out the prototype if you haven't already: http://localhost:5000/Lil_Yachty

In T245734#5924285, @Volker_E wrote:

I feel that we're not fully clear on the added value behind making the sidebar sticky. IMO we need to be clear on why the top items in the crowded sidebar get more importance (sticky) than links further down. Three concerns on sticky:

• We'd be breaking common user interaction patterns of one-column scrolling, like ctrl+page-up/cmd+arrow-up
• Making language list easier discoverable comes later in the project and it's probably among most used links section (data?), which is harder to scroll into (you'd need to move your link into smaller area)
• Sidebar links are a weird per-project collection and it's not clear at all that most important ones are on top, where fixed sidebar would be preferable

Additionally on a technical level, scrollbar appearance is on many GUI systems still underwhelming and customizations are hard and non-standard. Means, they might look terrible in small space additionally to all user-experience concerns.

In T245734#5924840, @Demian wrote:

In T245734#5923010, @ovasileva wrote:

Agreed that scrollbars would not be okay.

Scrollbars are commonly used for sidebars and better than having to scroll the whole article when looking for a specific link on the scrollbar. If done well it's subtle and convenient. Please see Discord for a great example, or try the userstyle for WikiZero I've posted in the first comment to see the difference with or without scrollbar on a page with long sidebar content and try WikiWand to see scrolling is usable even without a scrollbar, though it's up to the user to recognize there's more...

In T245734#5924285, @Volker_E wrote:

I feel that we're not fully clear on the added value behind making the sidebar sticky. IMO we need to be clear on why the top items in the crowded sidebar get more importance (sticky) than links further down.

Tl;dr: the reason for not seeing added value is that the site-navigation sidebar has in itself very little added value. Editors and readers are often asking for solutions to hide it.
What has added value is the TOC, the best solution would be to show the TOC on the sidebar and optionally - when the user clicks the navmenu icon -, show the site navigation (current sidebar) instead of the TOC. This is a requested feature on the DIP page, it seems this is the last time that can be effectively discussed.

Three concerns on sticky:

• We'd be breaking common user interaction patterns of one-column scrolling, like ctrl+page-up/cmd+arrow-up

FYI Ctrl+PGUP in Chrome and most browsers will go to the tab to the left. Do you mean simple PGUP?

• The scrolling behaviour won't be broken. As long as the main (content) column is focused, PGUP will have its effect there.
• If the user clicks inside the sidebar, it's expected that PGUP will affect that area.
• If the user clicks a link inside the sidebar (assuming site navigation is in the sidebar) a new page will load and focus returns to the main content.
• If the user clicks a link inside the sidebar TOC, then it is unexpected (not breaking tho) that focus (and PGUP scrolling) stays there, but easily fixed with an onclick handler that returns focus to main.

• Making language list easier discoverable comes later in the project and it's probably among most used links section (data?), which is harder to scroll into (you'd need to move your link into smaller area)

The DIP page suggests me with numerous examples that the language list is moved to a drop-down in the top-right corner. Is this concerning the special case of no-js runtime?

• Sidebar links are a weird per-project collection and it's not clear at all that most important ones are on top, where fixed sidebar would be preferable

• If projects put their important links not to the top, that's their own problem. Why would they?
• The bottom links are obscured in Vector, anyway. By the time a reader scrolls down, their focus is on reading the content, not the sidebar. These "concerns" also apply to the status quo.

Additionally on a technical level, scrollbar appearance is on many GUI systems still underwhelming and customizations are hard and non-standard. Means, they might look terrible in small space additionally to all user-experience concerns.

• Take a look at Discord. https://www.discordapp.com
• The userstyle for WikiZero I linked above.

Don't even consider defaulting to the default (system) scroll-bar, that would be terrible indeed. That's why I posted a ready-made solution above.

In T245734#5936114, @Demian wrote:

Demo for sidebar scrolling using above patch: http://patchdemo.wmflabs.org/wikis/197e628bad08d9ea6ab286c6db366fe7/w/index.php/Main_Page