[scroll-animations-1] ViewTimeline values of startOffset/endOffset in RTL writing mode

[ydaniv]

Currently the spec says:

Note: The value of startOffset can be greater than endOffset, for example in the horizontal axis in a right-to-left (rtl) writing mode.

Which would render scroll-animations very awkward when actually having to deal with in RTL mode. Even more so if we're considering that the names of these properties are logical (start/end) and they should work the same for any writing mode.

The issue noted below in the spec says:

This makes the offsets compatible with the way scrollLeft and scrollTop work, which go negative from zero in RTL scroll containers, is this how we want it to work here?

Which seems less relevant since scrollTop/Left are in fact non-logical APIs.

So, I'd expect the logical APIs, startOffset and endOffset, to behave the same depending on writing mode.

cc @fantasai @flackr

[flackr]

In terms of developers writing animations for RTL mode (or other writing modes), the math works the same, i.e. the timeline still goes from 0% to 100% as you go from the writing-mode dependent start to the writing-mode dependent end so it shouldn't make a difference to the way you write effects AFAICT.

I could see an argument for the accessors returning logical coordinates, though the primary reason for reading back the coordinates would be debugging or associating scroll positions with the effect. If we use a system that doesn't match the srcolling APIs then doesn't that make it harder? Maybe this just means we need logical scroll offsets on scrolling boxes.

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1] ViewTimeline values of startOffset/endOffset in RTL writing mode, and agreed to the following:

• RESOLVED: SLA uses logical interpretations of scrolling (rather than scrollLeft/Top always)

The full IRC log of that discussion

<fantasai> s/Topic/Subtopic/
<TabAtkins> flackr: on SL timelines we have start-offset and end-offset giving resolved scroll position
<TabAtkins> flackr: right now i think they're aligned with scrollTop and scrollLeft, so they're not WM-aware
<TabAtkins> flackr: The math works out fine with potentially negative ranges
<TabAtkins> flackr: But question is if they should be logical, or stay aligned?
<TabAtkins> fantasai: and you brought up suggestion that maybe we need logical scroll offset accessors
<TabAtkins> ydaniv: We have some logical options for the visual viewport
<TabAtkins> fantasai: I feel like it would be nice ot have logical accessors on the element, and also made this logical as a result.
<fantasai> TabAtkins: If you're RTL< it defaults to being scrolled all the way to the right
<fantasai> TabAtkins: So my opinion is that the default behavior should match the experience of the person working with it
<fantasai> TabAtkins: even if the accessors don't yet exist
<TabAtkins> flackr: sure, we can go with logical, and have a followup to do logical accessors on scrollports
<TabAtkins> astearns: so proposed resolution is that for SLA we use the logical interpretations of scrolling?
<TabAtkins> flackr: yep
<fantasai> wfm
<TabAtkins> ydaniv: yeah sounds good
<TabAtkins> RESOLVED: SLA uses logical interpretations of scrolling (rather than scrollLeft/Top always)
<TabAtkins> astearns: And flackr will raise a separate issue for logical scroll-position accessors