Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-scroll-snap-1] Clarify which writing-mode is used for scroll-snap-align, scroll container or snap position element? #3815

Closed
hiikezoe opened this issue Apr 9, 2019 · 15 comments
Labels
Closed Accepted by CSSWG Resolution Commenter Timed Out (Assumed Satisfied) css-scroll-snap-1 Current Work i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. Needs Testcase (WPT)

Comments

@hiikezoe
Copy link

hiikezoe commented Apr 9, 2019

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

@fantasai fantasai added css-scroll-snap-1 Current Work i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. Needs i18n feedback labels Apr 9, 2019
@fantasai
Copy link
Collaborator

fantasai commented 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
Copy link
Collaborator

fantasai commented 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
Copy link
Member

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
Copy link
Contributor

majido commented 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: rtl which I take it that with the proposed solution should interpret start as 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
Copy link
Author

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: rtl which I take it that with the proposed solution should interpret start as 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.

Just FYI, Firefox has also the issue on the example. I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=1546835.

@tabatkins
Copy link
Member

Agenda+ to confirm the conclusion.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed scroll-snap align vs writing-mode, and agreed to the following:

  • RESOLVED: use the writing mode of the container
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.

@fantasai
Copy link
Collaborator

Holding off on edits to consult i18n.

@r12a
Copy link
Contributor

r12a commented Nov 11, 2019

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?

@r12a
Copy link
Contributor

r12a commented Nov 11, 2019

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.

@fantasai
Copy link
Collaborator

@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 start alignment, and each one is in a different language... you align them all, and I guess you could argue either way for which side Arabic snaps to when the cards are smaller than the viewport, but if the cards are larger than the viewport... then you might want it to snap to the card's own start edge. No?

@fantasai
Copy link
Collaborator

Agenda+ to review the use cases

@css-meeting-bot
Copy link
Member

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
Copy link
Contributor

When the two writing modes are orthogonal, which values should be used to compare when computing "element is larger"?

@fantasai
Copy link
Collaborator

@litherum You use the size in the relevant axis. Scroll snapping is essentially one-dimensional.

fantasai added a commit that referenced this issue Sep 16, 2020
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jan 21, 2021
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Jan 25, 2021
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted by CSSWG Resolution Commenter Timed Out (Assumed Satisfied) css-scroll-snap-1 Current Work i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. Needs Testcase (WPT)
Projects
None yet
Development

No branches or pull requests

9 participants