- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Aug 2024 20:28:32 +0000
- To: public-css-archive@w3.org
flackr has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-overflow-5][css-scroll-snap-2] Snapping and generating scroll-marker pseudo-elements from fragments == 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](https://flackr.github.io/carousel/examples/carousel/image/). 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](https://drafts.csswg.org/css-overflow-5/#scroll-marker-pseudo) 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: ```css .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](https://drafts.csswg.org/css-scroll-snap/#scroll-snap-align) (as suggested in #6017) and [::scroll-marker](https://drafts.csswg.org/css-overflow-5/#scroll-marker-pseudo) pseudo-elements on a `::fragment` selector[^1]. This would allow a paginated carousel-like snapping experience to be created as follows: ```html <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](https://drafts.csswg.org/css-scroll-snap/#scroll-snap-align) (as suggested in #5911) and [::scroll-marker](https://drafts.csswg.org/css-overflow-5/#scroll-marker-pseudo) fragment aware. As per @tabatkins [comment](https://github.com/w3c/csswg-drafts/issues/5911#issuecomment-781596466) 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](https://drafts.csswg.org/css-overflow-5/#scroll-marker-pseudo) 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: ```html <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: ```html <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> ``` [^1]: Note that the current spec uses [::nth-fragment](https://drafts.csswg.org/css-overflow-5/#selectordef-nth-fragment), however having a single element [inherit different styles per fragment](https://drafts.csswg.org/css-overflow-5/#selectordef-nth-fragment:~:text=This%20means%20that%20elements%20split%20between%20fragment%20boxes%20may%20have%20different%20styles%20for%20different%20parts%20of%20the%20element) 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](https://drafts.csswg.org/css-overflow-5/#issue-978c73c1)) Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10715 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 August 2024 20:28:33 UTC