[css-scroll-snap-1] Clarify which writing-mode is used for scroll-snap-align, scroll container or snap position element? #3815
Comments
|
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 |
|
(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.) |
|
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. |
|
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 |
Just FYI, Firefox has also the issue on the example. I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=1546835. |
|
Agenda+ to confirm the conclusion. |
|
The CSS Working Group just discussed
The 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. |
|
Holding off on edits to consult i18n. |
The previous resolution to associate the start/end location with the container box sounds appropriate to me. I'm worried i might be missing something. @fantasai was there something that you were expecting that we might say? |
|
Btw, the editor's version has the CR livery, instead of ED – which confused me for a few moments. I was expecting it to have a red ED label top right. |
|
@r12a I was thinking about it, and there's a reasonable argument to be made for the other way around. E.g. if you have a bunch of "cards" which are in a horizontal row swipy view, and you specify |
|
Agenda+ to review the use cases |
|
The CSS Working Group just discussed
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/ |
|
When the two writing modes are orthogonal, which values should be used to compare when computing "element is larger"? |
|
@litherum You use the size in the relevant axis. Scroll snapping is essentially one-dimensional. |
…roll-snap-align' per WG resolution. #3815
…and mismatched writing modes., a=testonly Automatic update from web-platform-tests [css-scroll-snap] Add tests for matched and mismatched writing modes. w3c/csswg-drafts#3815 -- wpt-commits: eb897b400365b3b3ffb978693ef7e9fa68539654 wpt-pr: 27162
…and mismatched writing modes., a=testonly Automatic update from web-platform-tests [css-scroll-snap] Add tests for matched and mismatched writing modes. w3c/csswg-drafts#3815 -- wpt-commits: eb897b400365b3b3ffb978693ef7e9fa68539654 wpt-pr: 27162 UltraBlame original commit: 83cfb38658ef783cc633575111a3e005f92135ba
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
The text was updated successfully, but these errors were encountered: