Repository navigation
[css-flexbox] align-content: stretch for abspos children of flex containers should align with browser behavior. #7596
Description
https://drafts.csswg.org/css-flexbox/#align-content-property
Summary
The behavior of Blink, Gecko, and WebKit with respect to align-content: stretch when computing the static position of absolutely-positioned children of flex containers is the same whether the flex container has negative available space or not. This is in contrast to the spec text which specifies fallback behavior to flex-start when there is negative remaining space in the container. I am proposing that we amend the spec to align with the current behavior of browsers for stretch since it is the normal value for align-content and any change is risky for web compatibility.
Details
The static position of absolutely-positioned children of flex containers is determined as if they were the sole flex item in the container. In the case of a multi-line flex container, align-content is used to align flex lines within the container. When the container has available space, align-content: stretch will cause flex lines to fill the container. When the available space in the flex container is negative (the simplest, hand-wavy example is a child that is larger than the flex container) align-content: stretch is specified to fall back to be the same as flex-start. However, the behavior of all major browser engines is that the flex line fills the flex container whether available space is positive or negative. This is reflected in Web Platform Tests such as https://wpt.fyi/results/css/css-flexbox/abspos/flex-abspos-staticpos-align-content-005.html
The spec for align-content: stretch states
Lines stretch to take up the remaining space. If the leftover free-space is negative, this value is identical to flex-start. Otherwise, the free-space is split equally between all of the lines, increasing their cross size.
All browsers currently ignore the second sentence. This is somewhat of an accident in WebKit as we actually ignore align-content entirely, which is what I was working to resolve when I came across this disagreement between the spec and browser behavior.
The problem, as I see it, is that all browsers do not respect the fallback behavior for align-content: stretch when statically positioning abspos children and stretch is the default behavior. A change to match the spec in browser engines is risky for web compatibility as authors who leave align-content unspecified would have their content positioned differently than it is currently. @dholbert provided a great example illustrating surprising behavior when following the current spec.
I propose the spec is amended to remove the fallback behavior to flex-start for absolutely positioned children and to specify behavior as is currently implemented.
Activity
[-][css-flexbox] `align-content: stretch` for abspos children of flex containers should align with browser implementations.[/-][+][css-flexbox] `align-content: stretch` for abspos children of flex containers should align with browser behavior.[/+]rreno commentedon Aug 12, 2022
WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=243882
tabatkins commentedon Aug 16, 2022
I'm in support of removing any effect of the *-content properties on positioned elements. *-content is a property controlling the container's layout; positioned elements don't lay out in the container in the first place. While the static position of a positioned element is meant to reflect, to a reasonable extent, "where the element would lay out if it wasn't positioned", in flexbox we already break from that a decent bit and instead pretend it's a lone element (as flexbox layout is too interdependent to actually do such hypothetical layout).
We've also tried to break more from this dependent model in Position, and anything in support of that would be good. We've delayed on editting Flexbox's definition of staticpos until we had a better idea of the compat impact of the Alignment/Position changes, but if we're making this break official (and tested) we should get all the verbiage aligned.
bfgeek commentedon Aug 17, 2022
I've just added a use-counter for removing Blink's current justify-content logic which affects the static position. We'll have some data in a month or two.
Ian
dholbert commentedon Aug 17, 2022
Seems like this should be doable for
align-contentat least, since AFAIK it already has no effect on positioned flex children in Blink/WebKit. I'm fine making this change in Firefox, if we've got agreement on it and ideally some spec text. It's kind of unfortunate (particularly with the current & maybe long-term asymmetry ofalign-selfvs.justify-content), but it's where we are, I guess.RE hypothetically fixing that asymmetry and ignoring
justify-content: I like this idea in theory (i.e. I like the idea of fully switching to only respectalign-self/justify-selffor aligning the staticpos of abspos flex children), but I'm a bit skeptical that it'll be web-compatible in thejustifyaxis, given that:a) all browsers currently respect
justify-contentfor these children (and we'd need to stop doing that)b) no browsers currently respect
justify-selffor these children (and you're proposing we start doing that)Having said that: if IanK's use-counters prove it to be shippable without breaking the web, it'd be a pretty trivial change for us, implementation-wise, and I'd be happy to make that change as long as we're not the only ones to do so. :)
fantasai commentedon Aug 17, 2022
Agree with @tabatkins comment #7596 (comment) and would be glad to make this change which brings static positioning in flexbox more in alignment with other layout models.
@rreno I have one question, earlier you wrote:
Were you referring here to the behavior of abspos elements or of in-flow elements? Because browsers certainly follow that sentence for in-flow content, afacit.
rreno commentedon Aug 17, 2022
@fantasai
Yes, this issue is specific to abspos elements.
css-meeting-bot commentedon Aug 24, 2022
The CSS Working Group just discussed
[css-flexbox] align-content: stretch for abspos children of flex containers should align with browser behavior., and agreed to the following:RESOLVED: ignore the effect of align-content properties on absolutely positioned elements in flexRESOLVED: open an issue on justify-contentThe full IRC log of that discussion
<astearns> topic: [css-flexbox] align-content: stretch for abspos children of flex containers should align with browser behavior.<astearns> github: https://github.com//issues/7596
<argyle> astearns: first is flexbox align-content
<argyle> astearns: is this something that you want to introduce Ryan?
<argyle> rreno: the specific scenario is flexbox, when your computing the static position of absolultely posistioned children of flex containers
<fantasai> s/posistioned/positioned/
<bramus> s/absolultely/absolutely
<bramus> s/absolultely/absolutely/
<argyle> rreno: the problem is, the spec for alignmen defers to flexbox in this scenario, and flex specifies that when the container has negative available size, like an absolute positioned child that's larger than the container
<argyle> rreno: when that'sthe case, supposed to fallback to flex start, but no browsers do that
<argyle> rreno:
<argyle> rreno: my proposal is align the spec to what the proposal is doing, ignoring alignment content, but the browsers are. lets align spec text with what the browsers are doing
<argyle> rreno: it's essentially the default based on how browsers are currently operating
<argyle> astearns: any other opinions on making this change?
<argyle> TabAtkins: from fantasai and I's opinion, we approve of this change
<astearns> q+ iank_
<argyle> dholbert: firefox does actually honor align-content for abs pos flex children
<argyle> dholbert: in most cases
<argyle> dholbert: this resolution we make us start ignoring it. this would be a behavior change for firefox. i'm ok with it.
<argyle> dholbert: specifically for this align-content for abs pos flex children
<astearns> ack fantasai
<argyle> fantasai: wanted to confirm we keep grid and flexbox aligned on this point
<argyle> fantasai: so they ideally they both grid and flex behave the ssame with regards to this property
<astearns> ack iank_
<bramus> s/ssame/same/
<argyle> iank_: i'm a little bit confused, ryan, previously you wanted to okeep respecting, liek change webkit to match gecko, now that's not the case?
<argyle> rreno: we would like to change webkit ot match geckko, however, i was also trying to match the spec when implementing this..
<argyle> rreno: none of the browsers do the fallback to flex start
<argyle> rreno: my proposal was to remove tha tback to flex-start
<argyle> rreno: we're currently shipping webkit, we can rollout a patch i have. did that answer the question?
<argyle> iank_: yeah, just not sure we're exactly.. maybe if we had a proposed resolution that would clarify
<argyle> iank_: tab you were saying we should ignore both justify and align-content, is that correct?
<argyle> TabAtkins: ignoring the content properties for abs pos children
<argyle> iank_: i think we're taling about 2 separate things here
<argyle> rreno: fwiw, my proposal was a scoped change. maybe a new topic for another time
<argyle> iank_: do we just want to consider dropping align-content behavior, that would mean chromium and webkit stays the same, and firefox does the change
<argyle> rreno:
<argyle> rreno: that's fine with me
<dholbert_webclient> s/rreno/dholbert/
<argyle> astearns: tab, does the scoped proposal make sense? or you want to remove all of the scenarios?
<argyle> TabAtkins: i'm fine with doing this in stages, dont have to do all at once
<iank_> q+
<astearns> ack fantasai
<argyle> fantasai: all browsers honor justify content of abs children, and 2 of them are ignroning align-contenet, firefox is honoring it
<argyle> fantasai: in grid, all brwosers are ignoring both of them
<astearns> ack iank_
<argyle> iank_: that's correct. extra context: i've added a use counter in chrome to see what the impact would be of dropping justify-content
<argyle> iank_: in flex, to see if that had substantial behavior change. we can deal with that later if you like
<argyle> astearns: a proposed resolution could be: ignore the effect of align-content properties on abs pos element in flex and grid. open a new issue on whether or not we make the same change to justify-content
<argyle> astearns: is there anyone who wants to argue against that?
<argyle> dholbert_webclient: not against it, clarifying this is only scoped to flex. no proposed change for gird
<argyle> astearns: is it clear in the spec? that align-content shouhld be ignored in grid
<argyle> dholbert_webclient: i think so
<argyle> iank_: this sort of flex behavior comes from the older logic of how to determine static pos in flex. assume you're the only flex item and positiong yourself and if your not a flex item. grid came along and didnt have that logic. for some history
<argyle> astearns: we are resolved.
<argyle> astearns: proposed resolution: ignore the effect of align-content properties on abs pos element in flex. we are resolved
<argyle> astearns: proposed resolution: ignore the effect of align-content properties on abs pos element in flex
<argyle> astearns: we do need to open a new issue on justify-content
<argyle> astearns: hearing no objections, we're resolved
<argyle> RESOLVED: ignore the effect of align-content properties on absolutely positioned elements in flex
<argyle> RESOLVED: open an issue on justify-content
<argyle> astearns: so who's going to open a new issue. can i ask you iank_ ?
<argyle> iank_: sure, i can do that
<bradk> If the positioned thing is display:flex, then align-content still applies to its children though, right?
<argyle> astearns: brad had a question in the chat
<argyle> iank_: aw yes, this is for abs pos for determining the static pos
<argyle> bradk: make sure, talking about how the align-content on the parent of the abs items effects the abs pos items, but if the abs positioned items is flex, it still applies to their children right?
<argyle> iank_: this is just for static pos
<argyle> bradk: make sure it's clear in the spec
bfgeek commentedon Aug 24, 2022
New issue for justify-content: #7644
3 remaining items
Bug 1786910: Ignore 'align-content' when determining the aligned stat…
Ignore 'align-content' when determining the aligned static position o…
Bug 1786910: Ignore 'align-content' when determining the aligned stat…
Bug 1786910: Ignore 'align-content' when determining the aligned stat…
Bug 1786910: Ignore 'align-content' when determining the aligned stat…
Bug 1786910: Ignore 'align-content' when determining the aligned stat…
tabatkins commentedon Jan 11, 2025
Oh, this was actually fixed back in Aug 2022 as part of #5843. This issue didn't get recognized as a dupe.
Bug 1786910: Ignore 'align-content' when determining the aligned stat…
Bug 1786910: Ignore 'align-content' when determining the aligned stat…
Bug 1786910: Ignore 'align-content' when determining the aligned stat…