Repository navigation
[css-scroll-snap-1] Clarify which writing-mode is used for scroll-snap-align, scroll container or snap position element? #3815
Description
I've been thinking it's for sna-position element, but jfkthame thinks it's for scroll container.
Here is an example that the writing-mode for snap position element differs from scroll container's value;
https://codepen.io/anon/pen/vMyRVV
Activity
fantasai commentedon Apr 9, 2019
Good question! I'm surprised we didn't spec this interaction. The box alignment properties use the container's writing mode, so I think it makes sense here to use the scroll container's writing mode (i.e. the writing mode of the alignment container). https://www.w3.org/TR/css-align-3/#positional-values
fantasai commentedon Apr 9, 2019
(If in the future we want to use the element's own writing mode to resolve the logical values, we can add self-start/self-end keywords.)
tabatkins commentedon Apr 17, 2019
Yes, given the container properties definitely use the container's writing mode, I think it's most useful to default the descendant's properties to use the same.
majido commentedon Apr 23, 2019
I agree with the proposed solution. It makes sense to be consistent with box alignment properties and it feels most natural to me.
Having said that I don't think Chromium current implementation is correct. Here is a slightly modified version of the original example where I gave second container
direction: rtlwhich I take it that with the proposed solution should interpretstartas aligning the snap area to the right side of the scroll container. Which we don't at the moment. I will file a chromium bug for this.hiikezoe commentedon Apr 25, 2019
Just FYI, Firefox has also the issue on the example. I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=1546835.
tabatkins commentedon Apr 25, 2019
Agenda+ to confirm the conclusion.
css-meeting-bot commentedon May 8, 2019
The CSS Working Group just discussed
scroll-snap align vs writing-mode, and agreed to the following:RESOLVED: use the writing mode of the containerThe full IRC log of that discussion
<fantasai> Topic: scroll-snap align vs writing-mode<emilio> thanks dbaron :)
<fantasai> github: https://github.com//issues/3815
<florian> fantasai: the question is which writing-mode is used for scroll-snap-align:start and the container and the containee have different writing-modes
<florian> fantasai: the proposal is to use the writing-mode of the container
<florian> fantasai: because that's what we do for alignment properties
<florian> fantasai: we also have the self-start and self-end keywords if you want that
<florian> fantasai: that made more sense to align all things the same side in a single container
<florian> fantasai: this proposal is motivated by consistency with that
<florian> jen: sounds reasonable to me
<florian> plinss: me too. objections?
<florian> RESOLVED: use the writing mode of the container
<florian> jen: I wanted to thank the group for the great hard work to make specs understandable.
<bdc> (fully agree with jen)
<florian> jen: I have been at conferences, and after strugling with other specs, I really want to voice appreciation for doing it well as this group does.
7 remaining items
fantasai commentedon Jan 16, 2020
Agenda+ to review the use cases
css-meeting-bot commentedon Jan 22, 2020
The CSS Working Group just discussed
Clarify which writing-mode is used for scroll-snap-align, scroll container or snap position element?, and agreed to the following:RESOLVED: Keep the previous resolution to snap to the container's start edge, except when the element is larger than the snap port, in which case we use the scroll edge of the element.The full IRC log of that discussion
<heycam> Topic: Clarify which writing-mode is used for scroll-snap-align, scroll container or snap position element?<heycam> github: https://github.com//issues/3815
<heycam> fantasai: already discussed what to do when you have a snapping element that has a different writing mode from the scroll container
<heycam> ... snap to start edge -- the start edge of element being snapped or the scroll container?
<heycam> ... my original argument was the WM of the scroll container, because when you're doing alignment in general, we always use the WM of the container, so that all elements witht he same start/end alignment are aligned in the same way
<heycam> ... seems reasonable, consistent
<heycam> ... the alignment container's WM
<heycam> ... but then for snapping it makes a bit less sense
<heycam> ... consider an unusual case, you have a scroll container that's ltr
<heycam> ... inside there are a bunch of cards, text has articles in various languages
<heycam> ... most are ltr, snapping on start edge will snap on the left
<heycam> ... another is rtl, it'll also snap to the left edge
<heycam> ... if they're smaller than the container that seems ok
<heycam> ... but if the card is larger than the scroll port, then you'd end up snapping to the end of the content as the first thing the user sees
<heycam> ... but you're trying to snap to the start of the content
<heycam> ... so upon reflection it might make sense to use the WM of the element being snapped to
<heycam> Rossen: only for non-orthogonal?
<heycam> fantasai: similar case for orthogonal flows
<heycam> fantasai: the "start' of the content, you'll end up scrolling to the end of thecontent
<heycam> ... as long ast he content is smaller than the viewport, it's not a problem
<heycam> Rossen: what happens in the the opposite case? when teh scroll port is larger than the item
<heycam> fantasai: the behavior should be consistent
<heycam> ... but ni terms of use cases, when the content is smaller than the scrollport, it's not a big usability problem to use the left or right edge
<heycam> Rossen: my question is, let's say we have two items
<heycam> ... first one is ltr, other is rtl
<heycam> ... they're side by side, 1000px wide each, and weh ave a ivewport that's only 500px wide
<heycam> ... if we're snapping to the start, the first plae we snap to is box A, which is ltr
<heycam> ... the first child
<heycam> ... that'll snap to the left
<heycam> ... when you snap to the next one, it'll snap all the way to the right edge of the rtl element
<heycam> ... say that there are many elements, and these two are still side by side, and you're doing a carousel kind of thing
<heycam> ... every element is snapping to the start of teh scrollport
<heycam> ... element A is going to snap to its left side
<heycam> fantasai: the next one snaps to the right edge of element B
<heycam> ... you're snappiong the right edge of B to the right edge of the scroll container
<heycam> ... an important thing to think of is snapping because of focus/target, and if you target an entire section and it has a different WM and you snap to the end of that section, that's not good for usability
<heycam> [blackboard drawing]
<heycam> [general agreement of oddness]
<heycam> astearns: could say you snap to the scroll container's start edge, unless the snap element's start edge is not in view, in which case you snap to the element's start edge
<heycam> florian: or if the element and scroll port size are the same
<heycam> Rossen: it's not terrible
<heycam> Rossen: if the item fits entirely in the scroll container, it makes more sense to use the WM of the scroll container
<heycam> ... if the inverse is true, and the items are larger than the scroll container, it makes more sense to use the item's WM
<heycam> florian: and at the mid-point it's indistinguishable
<heycam> jfkthame: still seems a bit weird if some are smaller and some that are bigger
<heycam> Rossen: would it though?
<heycam> ... the invariant here is that every time you snap to a start, you'll guarantee you can start readin
<heycam> ... so if you have a collection that varies small and large, you can always snap to a snap that will guarantee that invariant
<heycam> ... sometimes you will go past what could be considered the start item from the scroll container's perspective
<heycam> jfkthame: what's troubling me is that for the items that are smaller than the container, their start is going to end up in the middle
<heycam> fantasai: I don't think that happens
<heycam> Rossen: I think this is the solution that guarantees you can start reading
<heycam> ... it's more important to be able to see the start of the item than have the same alignment point
<heycam> ... in the inverse case, it seems more appropriate that you snap in the direction of the container, so you don't have to jump
<heycam> ... that would change the direction of the scroll
<heycam> ... here you're preserving the direction of the scroll, you're just keeping that invariant that you can read the start of the item
<heycam> fantasai: I can take an action to propose some text
<fantasai> heycam: So if you have this element attachd to the scroller
<fantasai> heycam: and you start narrowing the browser window, it'll start attached to one edge, but end up attached to the other edge
<heycam> fantasai: yes, but that's nice
<fantasai> s/that's nice/it is continuous/
<heycam> RESOLVED: Keep the previous resolution to snap to the container's start edge, except when the element is larger than the snap port, in which case we use the scroll edge of the element.
<fantasai> s/scroll edge/start edge/
litherum commentedon Jan 22, 2020
When the two writing modes are orthogonal, which values should be used to compare when computing "element is larger"?
fantasai commentedon Jul 27, 2020
@litherum You use the size in the relevant axis. Scroll snapping is essentially one-dimensional.
[css-scroll-snap-1] Specify which writing mode is used to resolve 'sc…
[css-scroll-snap] Add tests for matched and mismatched writing modes. w…
[css-scroll-snap] Add tests for matched and mismatched writing modes. w…
Bug 1686547 [wpt PR 27162] - [css-scroll-snap] Add tests for matched …
Bug 1686547 [wpt PR 27162] - [css-scroll-snap] Add tests for matched …
Bug 1686547 [wpt PR 27162] - [css-scroll-snap] Add tests for matched …