[css-position] Meta-issue: Unresolved `sticky` positioning use cases

[johannesodland]

There are still many use cases for sticky-positioned elements that remain unsolved by the current spec(s).

This meta issue aims to track these use cases and the related proposals that could address them. Many of these issues were previously described in #2496, but I think it's worth tracking the individual issues. My hope is to renew focus on improving sticky positioning to better meet these needs.

• Selecting a different containing block
  The containing block for a sticky positioned element restricts how far the sticky element can be shifted. The current containing block for sticky elements limits what layout the sticky element can participate in. Being able to select a different containing block would add more flexibility to what layouts the sticky element can participate in.

  • [css-anchor-position-1] position-fallback-bounds vs position-container #9868
  • [css-position] position:sticky being limited to children with inline acenstors can be confusing. Allow bypassing this limitation. stick: scroll #10223

• Configuring insets from the containing block
  The insets from the the containing block can currently be configured with the margin of the sticky element. This margin serves a dual purpose, as it is also used in regular layout. Due to this ambiguity, the working group has resolved to ignore the margin in sticky pos calculation. We need a new way to configure the insets from the containing block.

  • [css-position] Allow setting multiple named box insets #10754

• Stack sticky elements against each other
  It would be useful to be able to stack multiple sticky elements together without overlapping, such as allowing a sticky h3 to sticky to the bottom of an already sticky h2.

  • [css-position] ‘Sticky’ behavior is too limited as position scheme created from the elements nearest block level ancestor & margins #2496 (comment)
  • [css-anchor-position-1] Could anchor positioning work for defining the targets of sticky elements? #8905 (comment)

• Allow the sticky element to see the viewport edges
  It could be useful to let an element be sticky both towards its scrollport edges, and towards the viewport edges. This would be useful in a table that is horizontally scrollable, where headers should remain in view when scrolling vertically.

  • [css-position-3] Making a stickypos in a scroller also see the viewport edges #8286
  • [css-position] sticky should be attached to parent with overflow-x or overflow-y depending on top/bottom and left-right #9140

• Select which viewport the element is sticky against
  There are multiple viewports that could be used as boundaries for the sticky element on mobile devices. It would be useful to control whether the element is sticky against the large viewport, the small viewport, or against the virtual keyboard.

  • [css-position] Referencing different viewports in sticky positioning #8934
  • [css-position-3] Reinterpret viewport positioned (fixed, sticky) elements wrt virtual keyboard #7475

• Behavior during overscroll

  • [css-overscroll] position: sticky elements should not move during overscroll when in stuck state #8309

• Styling based on scroll state
  Sometimes design calls for adding a shadow or a background to a sticky menu based on its state. To do this we need a :stuck pseudo selector or a scroll-state container query to add styles based on the state of the sticky element. (Explainer, Draft)

  • [css-selectors] Proposal for allowing selectors that depend on layout (:stuck, :snap, :on-screen, etc) #5979
  • [css-contain-3] Define a syntax for state-based container queries #6402
  • [css-conditional-5] More precisely define the syntax of scroll-state-feature #11127

• Appropriately handle the interaction between sticky elements and the optimal viewing regions
  scroll-padding can be used on scroll containers to reduce the optimal viewing region. This can be used to ensure that an element being scrolled into view doesn't end up hidden underneath the sticky element. However, when typing inside a sticky element the browser tries to scroll the sticky element itself into the optimal viewing region, causing unnecessary scrolling.

  • [css-scroll-snap] Support scroll-padding on all elements. #7931

[johannesodland]

Cc @fantasai, @bramus, @kizu

[flackr]

Perhaps also worth considering #7931, which is about how currently ensuring that scrolling elements into view both inside and outside of the sticky elements correctly ensures visibility.