[css-align] fully specify the "Overflow and Scroll Positions" section

[dbaron]

I think the current Overflow and Scroll Positions section, whose entire normative contents are currently:

The content distribution properties also affect the initial scroll position, setting it to display the appropriate portion of the scrollable area. In other words, the scrollable overflow region is aligned relative to the viewport as specified by the content distribution properties. Additionally, so that the content remains in the scrollable overflow region in order to be scrollable, the scroll and auto values of overflow trigger safe content alignment always.

is insufficient for what it's trying to specify.

I think there are a number of issues here:

• In the first sentence, "also affect" doesn't say how it affects the initial scroll position. For example, what does baseline do? What does center do? Do safe and unsafe influence the decision?
  • I'd note that I think it's a bad idea for the initial scroll position not to be at the edge of the scrollport, since existing scrolling user interfaces can make it hard to get back to a position that's not at the edge.
• The second sentence appears to confuse viewport and scrollport.
• The third sentence appears to completely contradict the first two, at least as I understand them. In other words, there only exists an initial scroll position when the content overflows, so this forces content-alignment on anything that is scrollable with more than one possible scroll position to be content-aligned to start. That, in turn, seems to imply that the initial scroll position would always be at the start edge like it's always been.

[tabatkins]

1. It has the effect stated - it aligns the scrollable overflow region within the scrollport, for the purpose of finding the initial scroll position. You appear to be reading this as talking about, more or less, where the scrollOffset=0 position is - it's not. What we're trying to describe is what, for example, Chrome does for an overflowing column-reverse flexbox - it starts the element scrolled down to the bottom.

   There's def some cleanup we need to do here, tho - fantasai and I are discussing this now.

2. Yeah, it does. Will fix.

3. I think this is also caused by your confusion regarding our use of "initial scroll position" vs "0 scroll offset". But also: we've some cleanup to do here.

[fantasai]

Okay, we've edited the section to hopefully be more precise. Let us know if you have any further concerns! https://drafts.csswg.org/css-align/#overflow-scroll-position

[dbaron]

The section appears to be unchanged from what I originally quoted.

[tabatkins]

Ah, looks like I accidentally reverted this text when I was rearranging sections in e693915#diff-77b45f4d92eb4bee76c4242f1752be4c

[fantasai]

:(

[dbaron]

I relanded the above patch. The only difference was the terminology change from "content distribution" to "content-distribution" (now hyphenated), which I made throughout (meaning that I made the substitution not only in the - lines of the patch which were necessary to make it apply, but also in the + lines of the patch and in the commit message).

[dbaron]

I think this requires somewhat careful review to see if this definition influences the way scrollTop etc. are reported.

[tabatkins]

I think this requires somewhat careful review to see if this definition influences the way scrollTop etc. are reported.

On further review, yeah, our text was somewhat wrong. In particular, it was setting the origin incorrectly if the content wasn't big enough to actually trigger overflow.

All in all, the previous text's attempt to align and then hack scroll coordinates back to being correct was weird and hard to understand. So we rewrote it again!

This time the text is more straightforwardly stating what's intended: that aligning an overflowing scroll container should show the same content as it would if it weren't scrollable, and it does so by adjusting the initial scroll position (so you can still scroll to see all the content it should normally be able to show). We also added a note capturing an important detail: that this isn't guaranteed to be identical to just aligning the scroll thumb in the scroll bar (tho it will often be identical).

Finally, we realized that doing this alignment (particularly for end-alignment) might be impossible with the current definition of scrollable overflow region, due to end-side padding being excluded in confusing circumstances. So, we defined that the container's end-edge padding is included as needed for end-alignment, and specified that this occurs for all non-normal alignment values for consistency. This also allows us to address the repeated requests for such padding behavior from the web author community without fear of Web-compat issues.

See https://drafts.csswg.org/css-align/#overflow-scroll-position and 7121795 for details of the edits.

[fantasai]

Agenda+ to discuss #1425 (comment)

[css-meeting-bot]

The Working Group just discussed fully specify the "Overflow and Scroll Positions" section.

The full IRC log of that discussion

<dael> Topic: fully specify the "Overflow and Scroll Positions" section
<dael> github: https://github.com//issues/1425#issuecomment-411930443
<dael> astearns: Edits have been made.
<dael> fantasai: Wanted to call attention to things tryign to fix
<fantasai> https://drafts.csswg.org/css-align/#overflow-scroll-position
<dael> fantasai: This section is about when you have a scroll container and it has align content so you center all the content in the box in the box. When you have a scroll container we decided that rather then ignore alignment or align content to the end and overflow to the top we wanted to make it so you could read the content and be able to scroll to it. That meant moving content down and show as if end aligned
<dael> TabAtkins: Almost same as aligning scroll thumb in scroll track. Not quite same. Some content alignments b/c way some browsers discard padding means it would normally be impossible to achieve same layout wither if overflow:scroll or not.
<dael> TabAtkins: Have a bit about mandating you provide enough padding to match. Also helps solve issue that people want block-end and inline padding. We say if you use can content alignment you get the padding. That makes all padding work as expected.
<dael> florian: Does that solve the legacy or do we have too many legacy behaviors?
<dael> TabAtkins: Still not sure what legacy should be. Lets us have t he good behavior so we can solve legacy separately
<dael> florian: Fair enough
<dael> astearns: dbaron You've been i this issue, have you looked at latest edits?
<dael> dbaron: I don't think so
<dael> astearns: Leave this as please everyone take a look and we come back next week t o resolve?
<dael> TabAtkins: yeah

[dbaron]

I think the first paragraph of the new text is mostly reasonable.

However, it contains the text:

initially-visible content of the scroll container is the same as it would be if it were not a scroll container

which seems problematic since scrollbars can remove some of the available space for the content, which means that the initially-visible content actually can't be the same in some cases. I think, for example, that if you're doing

align-content: end;
justify-content: end;
overflow: scroll;

then you want the scroll-position all the way at the end, not one scrollbar width short of all the way to the end as the spec currently (maybe) defines (at least if you assume that you want the position of the content to match where it would be if it were not a scroll container).

I suspect this means you should define things in terms of alignments -- particularly for center.

---

I don't think I actually understand what the second normative paragraph is trying to say.

[tabatkins]

Second paragraph is trying to say "if you have a non-initial align, apply all the paddings, rather than dropping some of them in hard-to-explain conditions like browsers do today".

[fantasai]

@dbaron OK, adjusted the wording a bit. https://drafts.csswg.org/css-align-3/#overflow-scroll-position Does it make sense now?

[tabatkins]

And adjusted it a bit more.

[css-meeting-bot]

The CSS Working Group just discussed fully specify the "Overflow and Scroll Positions" section, and agreed to the following:

• RESOLVED: take this approach and file separate issues for wording issues

The full IRC log of that discussion

<dael> Topic: fully specify the "Overflow and Scroll Positions" section
<dael> github: https://github.com//issues/1425#issuecomment-413375688
<dael> astearns: fantasai and TabAtkins made edits. Are you asking for dbaron approval?
<dael> fantasai: It looks like we discussed but didn't resolve. Need to resolve and get dbaron review
<dael> fantasai: We were trying to spec the behavior of the content alignment properties on scroll containers. content alignment when applied to element it adjusts content inside it
<dael> fantasai: dbaron asked to tighten. We noticed what we were doing fundementally for a scroll container instead of align by layout and then clipping the alignment instead you're doing safe alginment and then scroll so you get effected alignment
<dael> fantasai: If you said align-conntent:end and the content overflows we start align and then scroll container so you get same effect as if not scroll cotnainer
<dael> fantasai: Tricky thing is scrollable overflow doesn't include padding at bottom. Well, might o r might now depending on UA...open issue on overflow 3. When you scroll to the end the bottom of the visible content that overflows lines up with t he padding edge of scroll cotnainer. needs to be content edge for proper behavior.
<dael> fantasai: To get that alignment effect we're going for so switch between scrollable and not alignment is same we had to spec we extend scrollable overflow area by t hat amount of padding. We extend from edge of inflow content
<dael> fantasai: Authors have asked us to add this.
<dael> fantasai: We have a normal vallue for alignment that lets us do whatever weird things needed for compat. We trigger this extra space for scrollable overflow when you have a not normal value of align or justify content. That's new in spec because didn't look at implications of padding
<dael> fantasai: Asking WG if this is okay and ask for review
<dael> fantasai: Questions or need explanation?
<dael> astearns: Little weird we trigger this on non-normal but I see why it's necessary
<dael> astearns: dbaron comments? Want more time?
<dael> dbaron: Need more time to review
<dael> astearns: Fair enough
<dael> astearns: Other comments?
<dael> fremy: Like the global idea. Haven't checked details
<dael> fantasai: Resolve on global idea and check wording later?
<dael> fantasai: Then we have WG resolved this is behavior we want. Problems with wording can file a specific issue
<dael> florian: If we could do away with odd compat it would be great. not realistic. This approach does seem to work all but a bit strangely.
<dael> florian: Can't think of anything simplier that works and respects compat
<dael> astearns: Objections to resolve to take this approach and filed separate issues for wording issues?
<dael> RESOLVED: take this approach and file separate issues for wording issues

[fantasai]

Closing out this issue. (We still need to make some improvements on the illustrations aka whiteboard drawings which should be SVG with nice captions, but that's a follow-up issue.)