Open
Bug 1499443
Opened 6 years ago
Updated 1 year ago
[css-align] Implement CSS Alignment "Overflow and Scroll Positions" section (justify-content/align-content should influence initial scroll pos)
Categories
(Core :: Layout: Scrolling and Overflow, enhancement, P3)
Core
Layout: Scrolling and Overflow
Tracking
()
NEW
Webcompat Priority | P3 |
People
(Reporter: dholbert, Unassigned)
References
(Depends on 1 open bug, )
Details
Filing this bug on CSS Alignment section 5.3, which has two basic requirements for justify-content/align-content on a scrollable element:
(1) they set the initial scroll position
(2) non-default (non-"normal") values cause end-padding to be honored/scrollable (notable because it traditionally hasn't been scrollable).
For background, see this comment:
https://github.com/w3c/csswg-drafts/issues/129#issuecomment-417525242
...and this issue:
https://github.com/w3c/csswg-drafts/issues/1425
...which resulted in this spec text:
###
When the content-distribution properties are set on a scroll container with an overflowing alignment subject, rather than shifting the layout positions of its content, they instead change its initial scroll position so that the initially-visible content of the scroll container satisfies the expected alignment of the alignment subject and alignment container.
Because the scroll container’s end-edge padding is not always included in the scrollable overflow region (see CSS Overflow 3 §2.2 Scrollable Overflow), performing such alignment might require that the alignment subject be positioned in a way that would normally not be possible just by scrolling. To resolve this problem (and be consistent across alignment values), all non-normal values of align-content/justify-content cause the scrollable overflow region to be extended in the relevant axis however much would be required to make it possible to scroll to a position satisfying end alignment in that axis. (In general, this means that the scroll container’s padding is added to the bounding rectangle of its in-flow children on both sides of the scrollable overflow region.
###
https://drafts.csswg.org/css-align/#overflow-scroll-position
(Note that this will kind of create a workaround for bug 748518 --> adding that to "see also".)
Updated•6 years ago
|
See Also: → https://webcompat.com/issues/24856
Reporter | ||
Updated•6 years ago
|
Updated•3 years ago
|
Webcompat Priority: --- → ?
Comment 2•2 years ago
|
||
The issue on Dropbox appears to be gone. Daniel, is this still an issue?
Webcompat Priority: ? → P3
Flags: needinfo?(dholbert)
Reporter | ||
Comment 3•2 years ago
|
||
AFAICT we haven't yet implemented the spec change in comment 0.
However, the associated Dropbox webcompat issue seems like it says bug 748518 was the real underlying issue there, and bug 748518 is fixed, which is presumably why the issue at Dropbox is no longer reproducible.
I'll move the see-also from this bug to bug 748518.
(Also: while I'm here, I'm clearing the one-off & ancient "affected" flag; all preexisting builds are implicitly/trivially affected by spec-change bugs.)
status-firefox64:
affected → ---
Flags: needinfo?(dholbert)
See Also: https://webcompat.com/issues/24856 →
Updated•2 years ago
|
Severity: normal → S3
Summary: [css-align] Implement CSS Alignment "Overflow and Scroll Positions" section (justify-content/align-content should influence initial scroll pos & cause end padding to be honored) → [css-align] Implement CSS Alignment "Overflow and Scroll Positions" section (justify-content/align-content should influence initial scroll pos)
End padding is now unconditional, so updating the summary to focus on the initial scroll position. :)
Depends on: 1684236
Fixing this has two parts:
- Add the following to nsBlockFrame::AlignContent()--and something equivalent to every other frame type that honors align-content:
// Don't pull content up into the unscrollable region
if (Style()->GetPseudoType() == PseudoStyleType::scrolledContent) {
shift = std::max(0, shift);
}
- Set the initial scroll position to align mScrolledFrame inside nsGfxScrolledFrame according to the specified alignment. I have no idea where this is done, though. (We're clearly doing it properly for RTL frames and scroll snapping somehow...)
You need to log in
before you can comment on or make changes to this bug.
Description
•