-
Notifications
You must be signed in to change notification settings - Fork 707
[css-align] fully specify the "Overflow and Scroll Positions" section #1425
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
Comments
|
…nd scroll containers clearer per #1425
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 |
The section appears to be unchanged from what I originally quoted. |
Ah, looks like I accidentally reverted this text when I was rearranging sections in e693915#diff-77b45f4d92eb4bee76c4242f1752be4c |
:( |
…nd scroll containers clearer per #1425
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 |
I think this requires somewhat careful review to see if this definition influences the way |
…or both correctness and understandability. #1425.
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. |
Agenda+ to discuss #1425 (comment) |
The Working Group just discussed 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 |
I think the first paragraph of the new text is mostly reasonable. However, it contains the text:
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. |
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". |
@dbaron OK, adjusted the wording a bit. https://drafts.csswg.org/css-align-3/#overflow-scroll-position Does it make sense now? |
And adjusted it a bit more. |
The CSS Working Group just discussed
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 |
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.) |
I think the current Overflow and Scroll Positions section, whose entire normative contents are currently:
is insufficient for what it's trying to specify.
I think there are a number of issues here:
safe
andunsafe
influence the decision?start
. That, in turn, seems to imply that the initial scroll position would always be at the start edge like it's always been.The text was updated successfully, but these errors were encountered: