Scroll Container Ownership Contract

Large Theory

Knowledge bases, asset libraries, dashboards, and canvas tools often combine top navigation, sidebars, result areas, sticky search, local lists, and drawers. If several ancestors use height: 100vh, overflow: hidden, or overflow: auto, the page can become unscrollable, show double scrollbars, break sticky positioning, hide mobile content, or lose inputs when the keyboard opens. Healthy layout names the primary scroll owner first and then defines local-scroll exceptions.

Small Points

1. Page-level content should usually let body/document or one explicit app shell own primary scroll; avoid multiple sibling areas competing for scroll.
2. Use local scroll only for bounded areas such as lists, tables, code blocks, sidebar menus, and modal content.
3. Sticky elements depend on the nearest scrolling ancestor; parent overflow changes the sticky reference and must be verified.
4. Mobile should reflow to a single column except for content that truly needs two-dimensional space, such as data tables, canvases, or maps.
5. Drawers/dialogs may lock body scroll while open, but must restore it on close; focus and keyboard viewport need testing.
6. Validation goes beyond the first viewport: test scrollHeight > innerHeight, actual wheel/touch scroll, bottom content visibility, and 320 CSS px reflow.

Design Judgment

The contract works when desktop and mobile can scroll from top to bottom, no content is hidden, unexpected double scrollbars are absent, sticky behavior is stable, and body copy does not require two-direction scrolling at 320 CSS px width.

Implementation Notes

Write a scroll map for every long page: pageScrollOwner, localScrollRegions, stickyElements, lockedStates, mobileReflow, keyboardRisk, and overflowExceptions. Avoid unexplained height: 100vh chains in CSS. App shells prefer min-height and overflow: visible; local panels use min-height: 0 plus an explicit max-height. Browser verification records document.scrollingElement.scrollHeight, window.scrollY, body/clientWidth, and overflow values for key containers.

Counterexamples/Risks

The page root uses overflow: hidden while the result area is long; both sidebar and results scroll and users lose orientation; sticky search fails because a parent has overflow; mobile horizontal overflow creates WCAG Reflow risk; a dialog locks scroll and never restores it; screenshots cover only the first viewport and never test bottom reachability.

Case Study

MDN defines a scroll container as an element whose content can be scrolled and explains that overflow controls how excess content behaves. W3C WCAG Reflow expects zoomed or narrow content to be read without two-direction scrolling. Awwwards scrolling examples often distinguish the main page narrative from local interactive moments through clear scroll ownership. Applied to Interface-Lab, the knowledge page should allow natural vertical scrolling for main content, keep sidebar scrolling bounded only when necessary, and avoid app-shell overflow that hides library content.

Source Links

MDN Overflow: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/overflow MDN Scroll container: https://developer.mozilla.org/en-US/docs/Glossary/Scroll_container W3C WCAG Reflow: https://www.w3.org/WAI/WCAG21/Understanding/reflow.html Awwwards Scrolling Collection: https://www.awwwards.com/websites/scrolling/