seanaery
commented
1 year ago @ggeisler That's a great catch -- turns out to be just a mistake/oversight on our part. I'll get that fixed in our app. Overall, I'd say we really like having the collection/nav context stick and think it enhances the UX. We valued that kind of thing even in our pre-ArcLight finding aids application (2016 blog post). It used to be challenging to pull off across browsers, but these days with position: sticky support and/or Bootstrap .position-sticky class, it doesn't take too much fiddling to get it right.
lfarrell
I'd consider this a UX enhancement more than a bug fix because the collection/component pages currently work acceptably in terms of scrolling, but if and when someone has time I think it's a better user experience when the sidebar remains in-place when the main content area is scrolled. This keeps the sidebar in view and accessible when the user scrolls down longer collection/component pages. Duke's implementation does this and is just what we'd ideally want in core, I believe.
You can't see the sidebar scrollbar in my screenshot above but part of this solution is that the sidebar needs to be scrollable itself, since a content inventory can taller than the content in the collection/component show page.
This only applies to viewports at
lgand above, since belowlgwe now collapse the sidebar and display it as an off-canvas panel.@seanaery One question about your implementation of this: I noticed that you don't use the sticky sidebar until you get to the
xlviewport width. So thelgviewport width has a different behavior (visible sidebar that scrolls with the main content area) than belowlg(sidebar collapsed) and abovelg(sticky sidebar). Just curious what the reason for that was, in case it's relevant to how we should replicate your approach in core? (And any thoughts you have about implementing this in core, if you have them - thanks!)