Skip to content

[css-overflow-5][css-scroll-snap-2] Snapping and generating scroll-marker pseudo-elements from fragments #10715

Closed
@flackr

Description

@flackr

For common carousel patterns as outlined in #9745, developers will have content being fragmented into different boxes. Often, developers want to create an interface that scrolls through these fragments by pages, e.g. demo. Similarly, for existing column fragmentation use cases developers may wish to snap to particular columns. Issues #6017 and #5911 both have prior discussion on snapping specifically.

As with snapping, it would be very convenient to be able to generate a ::scroll-marker pseudo-element per generated fragment to set up automatic markers based on the available space and number of resulting fragments the content ended up needing.

This explores the two issues together as they feel similar in nature, though we don't necessarily have to resolve on the same solution for both.

For the examples below, we have the following common styles:

.scroller {
  overflow: auto;
  height: 80vh;
  scroll-snap-type: x mandatory;
  columns: 1; /* Fragment content to horizontally scrollable full pages */
}

Options:

  1. Support scroll-snap-align (as suggested in [css-multicol-2][css-scroll-snap] Snapping to column boxes #6017) and ::scroll-marker pseudo-elements on a ::fragment selector1. This would allow a paginated carousel-like snapping experience to be created as follows:
    <style>
      .scroller::fragment {
        scroll-snap-align: center;
        &::scroll-marker {
          content: ' ';
        }
      }
    </style>
    <div class="scroller">
      <!-- flowing content or items, e.g. -->
      <div>Item 1</div>
      <div>Item 2</div>
      ...
      <div>Item n</div>
    </div>
  2. Make scroll-snap-align (as suggested in [css-scroll-snap] Scroll snap areas for fragmented boxes (like in css-multicol) #5911) and ::scroll-marker fragment aware. As per @tabatkins comment in the linked issue this seems to be the way that firefox behaves for scroll-snap-align already. If we go this way we may decide whether that ::scroll-marker should behave the same as well or that it should have a different solution. For our common example, this would require the use of a wrapping element to establish the fragment snap areas and markers:
    <style>
      .scroller > div {
        scroll-snap-align: center;
        &::scroll-marker {
          content: ' ';
        }
      }
    </style>
    <div class="scroller">
      <div> <!-- wrapping container generating snap areas and markers -->
        <!-- flowing content or items, e.g. -->
        <div>Item 1</div>
        <div>Item 2</div>
        ...
        <div>Item n</div>
      </div>
    </div>
  3. Introduce fragmentation aware values for these selectors / properties. This would provide a bit more capability as authors could specify for each sytled element which one should have its fragmented parts should generate a snap areas and/or scroll markers. Similar to option 2, this would also require wrapping the content for our common example case:
    <style>
      .scroller > div {
        scroll-snap-align: center per-fragment;
        &::scroll-marker(per-fragment) {
          content: ' ';
        }
      }
    </style>
    <div class="scroller">
      <div> <!-- wrapping container generating snap areas and markers -->
        <!-- flowing content or items, e.g. -->
        <div>Item 1</div>
        <div>Item 2</div>
        ...
        <div>Item n</div>
      </div>
    </div>
  4. Support scroll-snap-align (as suggested in [css-multicol-2][css-scroll-snap] Snapping to column boxes #6017) and ::scroll-marker pseudo-elements on a ::column selector. This would allow a paginated carousel-like snapping experience to be created as follows:
    <style>
      .scroller::column {
        scroll-snap-align: center;
        &::scroll-marker {
          content: ' ';
        }
      }
    </style>
    <div class="scroller">
      <!-- flowing content or items, e.g. -->
      <div>Item 1</div>
      <div>Item 2</div>
      ...
      <div>Item n</div>
    </div>
    This is similar to option 1, however is more clear about what is being styled. I think developers could think about this as decorating the columns, and the properties may not need to be inherited to the elements in the columns.

Footnotes

  1. Note that the current spec uses ::nth-fragment, however having a single element inherit different styles per fragment introduces significant implementation complexity. As such, we would propose initially resolving to go with a single ::fragment style (i.e. the syntax mentioned in the inline issue)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Friday morning

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions