Allow me to disable the sidebar resize

[daattali]

The latest version allows sidebars to be resized with the mouse. It's a good feature, but it's not always wanted. There needs to be a way to turn it off, ideally with a resizeable=FALSE parameter.

[gadenbuie]

I'm okay with adding a resizable argument. As I've mentioned before, I originally included one but decided not to include it for the simplicity of the API.

I think there are clearly users who would like to turn of resizable sidebars, and its enough signal to convince me we should move forward with it, but it would still be helpful if you could articulate the scenarios where you've not wanted the sidebar to be resizable.

[daattali]

I don't mind if it's a class that you need to add , so that you don't end up with dozens of parameters. As long as it's documented in the function's documentation (not only on the website, but in the function's help itself), and it's treated as a "feature" that doesn't break in the future, that's good enough for me.

[daattali]

Sorry, I didn't mention why I don't want it. The functionality is very welcomed, but the UX of it bothers me, so I would generally opt out. If a sidebar is long and has a scrollbar, then when I move the cursor to the scrollbar, the sidebar "wins" the hover bottle and I cannot use the scrollbar at all. Maybe if the "collision box" gets much narrower, and is clearly visible so that the user can see where to move the mouse to escape the "resize", maybe that would help.

[gadenbuie]

Thanks Dean, but it really would be helpful to explain the situations in which you don't want to have the sidebar be resizable.

[daattali]

@gadenbuie I added another comment that explains it :) It was just before your comment, so you may have missed it

[daattali]

I threw something together in a few minutes as an idea:

library(shiny)

css <- "
.bslib-sidebar-layout .bslib-sidebar-resize-handle:hover .resize-indicator,
.bslib-sidebar-layout .bslib-sidebar-resize-handle:focus .resize-indicator,
.bslib-sidebar-layout .bslib-sidebar-resize-handle:active .resize-indicator {
  display: none;
}
.bslib-sidebar-layout .bslib-sidebar-resize-handle {
  width: 6px;
  left: -3px;
}
.bslib-sidebar-layout .bslib-sidebar-resize-handle::before {
  left: 0;
  right: 0;
  opacity: 0.5;
  transition: background 0.5s;
}
.bslib-sidebar-layout .bslib-sidebar-resize-handle:hover::before {
  background: #aaa;
}
.bslib-sidebar-layout .bslib-sidebar-resize-handle:focus::before,
.bslib-sidebar-layout .bslib-sidebar-resize-handle:active::before {
  transition: none;
  background: #222;
  opacity: 0.8;
}
"

ui <- bslib::page_fillable(
  tags$head(tags$style(css)),
  bslib::layout_sidebar(
    sidebar = bslib::sidebar(
      div("foo", style = "height: 110vh")
    ),
    "bar"
  )
)

server <- function(input, output, session) {
  
}

shinyApp(ui, server)

https://www.loom.com/share/a4f72c0aa4f1423c824c35d7eb2fb094

[gadenbuie]

Thanks for the explanation, that helps a lot. I intentionally made the resize handle large enough to serve as a touch target and to increase the accessibility; in your Loom screenshare you can see that getting the mouse into the specific region where selecting and dragging the resize handle is possible is quite small and would be difficult for anyone with mobility issues.

I think we could likely do something here though to let clicks and mouse activity on the scrollbar pass through the resize handle. As the app author you could adjust sidebar settings or contents to move the scroll bar away from the sidebar's edge; that said the right answer for the "best" approach will depend a lot on what content you have in the sidebar.

[daattali]

FWIW, I was experimenting with other handles for dragging. In my example there is a 6px "window", it can definitely be increased by 1-2px. In RStudio, to make any pane larger/smaller there's a 7px window. In Windows 11, to resize any window there's an 8px window. In the current bslib sidebar implementation, the window is 26px.

[gadenbuie]

The reason that it's 26px wide is because that's close to the minimum WCAG 2.2 touch target size recommendation. Which is certainly much larger than required for fine pointers (desktop + mouse users). I hadn't encountered the touch target overlapping with the scrollbar in my testing at the time, but this is certainly something we can address, possibly with a any-pointer: coarse media query.

[gadenbuie]

It turns out that just adjusting the resize handle target size by itself isn't quite enough. I played around with resizable sections in various apps and realized that in VS Code, the resize handle doesn't show up until right about when you cross into the adjacent pane. I realized we could do the same thing.

In #1299, in addition to using different widths for the resize handle based on the pointer type, we now detect when the mouse crosses the sidebar boundary and then temporarily increase the resize handle width. This gives you a large enough handle area that it's easy to grab and resize the sidebar, but if you approach the scrollbar from inside the sidebar you should have plenty of space to grab and manipulate the scroll bar. (There could be a few pixels of overlap but the scrollbar handle is no longer covered by the resize handle area.)

There's a video in the PR if you're interested, or if you want to check out the PR branch and test the implementation, feedback would be appreciated.

[daattali]

I tested that PR, works really nice! I never realized that's the trick that is done to make the resize useful but not annoying. Much much better :)