You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-align] Does stretch work when width/height only behaves as auto? #4525
When the box’s computed width/height (as appropriate to the axis) is auto and neither of its margins (in the appropriate axis) are auto, sets the box’s used size to the length necessary to make its outer size as close to filling the alignment container as possible
The quote says "computed height is auto", which technically doesn't hold. So in Chromium, the item is not stretched. But Firefox thinks that the spec actually means "behaves as auto" (which has been a very frequent mistake in the specs), so it stretches the item.
Which is it? I prefer Chromium's behavior, if an author sets height: max-content, I think it's reasonable to assume they desire to size it according to the content, not stretch it to fill the container.
I think the intention here is indeed to check the computed value, and that Chromium's behavior is correct. The "behaves as auto" cases that are not computed 'auto' keywords are primarily for sizing behaviors where we can't do the thing requested...
Furthermore, there's an open issue on whether the content-based size keywords should be treated as auto in the general case, see #3973 I think the central mistake there was assuming that 'auto' resolved to "content-based height" as it does in block layout, in which case that would be appropriate... but in Grid and Flexbox that's not the case, and there is special behavior associated with 'auto' that would not be appropriate to trigger if the author specifically wanted to request content-based heights.
I agree that Chrome's behavior is probably better here, but the note in the "Behaves as 'auto'" section seems to imply that all the places where we check for a computed value of "auto" are legacy and should be fixed; if there are valid use-cases for this, we should be a lot more specific about that (maybe, unfortunate as it may be, inventing a new term that specifically means "computed value is auto" for this, just so we can distinguish legacy uses from intentional new uses).
I prefer Chromium's behavior, if an author sets height: max-content, I think it's reasonable to assume they desire to size it according to the content, not stretch it to fill the container.
The CSS Working Group just discussed Does stretch work when width/height only behaves as auto?, and agreed to the following:
RESOLUTION: Keep the spec text about auto and stretching that aligns with Chromium behavior, but add some clarification.
The full IRC log of that discussion
<heycam> Topic: Does stretch work when width/height only behaves as auto?
<heycam> github: https://github.com//issues/4525
<heycam> oriol: this is about grid items the default alignment is stretch
<heycam> ... this is supposed to stretch an element to cover tis container
<heycam> ... but not if the computed width computes to auto
<heycam> ... the spec has some ambiguity about computing to auto
<heycam> ... but it's "behaves" as auto
<heycam> ... FIrefox thinks this is the case, and instead of checking the computed value being auto, it checks whether it behaves as auto
<heycam> ... e.g. if you set the height to max-content it behaves as auto, in Firefox it stretches, but in Chromium it doesn't
<RossenF2F> q?
<heycam> ... the question is whether if the width/height is set to a value that behaves as auto but isn't auto itself, does this stretch?
<RossenF2F> q+
<heycam> fantasai: I think the author did not want automatic behavior
<heycam> ... in the most common behavior, automatic behavior is sizing to the content
<RossenF2F> Zakim, open queue
<Zakim> ok, RossenF2F, the speaker queue is open
<heycam> ... in the context of grid and flex, auto isn't equivalent to that
<heycam> ... if the author has set it to a value that's not auto, we shouldn't automatically stretch
<heycam> ... I think the spec is correct to rely on computing to auto, so we should align on Chromium's behavior
<heycam> TabAtkins: mats also says that sounds reasonable
<tantek_> is there a test case for Chromium's behavior?
<heycam> emilio: it's a bit weird that it max-content behaves as auto for some things but not others
<rego> tantek_:
<rego> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23grid%20%7B%0A%20%20display%3A%20grid%3B%0A%20%20width%3A%20100px%3B%0A%20%20height%3A%20100px%3B%0A%20%20grid-template%3A%20100%25%20%2F%20100%25%3B%0A%20%20background%3A%20yellow%3B%0A%7D%0A%23item%20%7B%0A%20%20height%3A%20max-content%3B%0A%20%20align-self%3A%20stretch%3B%0A%20%20background%3A%20cyan%3B%0A%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20id%3D%22grid%22%3E%0A
<rego> %20%20%3Cdiv%20id%3D%22item%22%3EText%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
<tantek_> IRC broke that
<tantek_> across a line
<rego> yep, linked on the issue
<rego> at the begginig
<rego> https://github.com//issues/4525
<tantek_> thank you
<heycam> RESOLUTION: Keep the spec text about auto and stretching that aligns with Chromium behavior, but add some clarification.
<heycam> astearns: let's get that test case into WPT
<fantasai> s/RESOLUTION/RESOLVED?
<fantasai> s/RESOLUTION/RESOLVED/
Activity
fantasai commentedon Jan 9, 2020
I think the intention here is indeed to check the computed value, and that Chromium's behavior is correct. The "behaves as auto" cases that are not computed 'auto' keywords are primarily for sizing behaviors where we can't do the thing requested...
Furthermore, there's an open issue on whether the content-based size keywords should be treated as auto in the general case, see #3973 I think the central mistake there was assuming that 'auto' resolved to "content-based height" as it does in block layout, in which case that would be appropriate... but in Grid and Flexbox that's not the case, and there is special behavior associated with 'auto' that would not be appropriate to trigger if the author specifically wanted to request content-based heights.
tabatkins commentedon Jan 9, 2020
I agree that Chrome's behavior is probably better here, but the note in the "Behaves as 'auto'" section seems to imply that all the places where we check for a computed value of "auto" are legacy and should be fixed; if there are valid use-cases for this, we should be a lot more specific about that (maybe, unfortunate as it may be, inventing a new term that specifically means "computed value is auto" for this, just so we can distinguish legacy uses from intentional new uses).
fantasai commentedon Jan 9, 2020
I think we should just audit the specs, fix them where necessary, and limit the note's target to CSS2.
tabatkins commentedon Jan 9, 2020
Agenda+ to verify with Emilio (and anyone else who cares) that the Chrome behavior is preferable.
MatsPalmgren commentedon Jan 15, 2020
Seems reasonable to me, fwiw.
cbiesinger commentedon Jan 22, 2020
#3973 may change this again
But I guess that still leaves the question on whether this applies to indefinite percentages?
fantasai commentedon Jan 22, 2020
@cbiesinger Indefinite percentages don't compute to
auto.css-meeting-bot commentedon Jan 22, 2020
The CSS Working Group just discussed
Does stretch work when width/height only behaves as auto?, and agreed to the following:RESOLUTION: Keep the spec text about auto and stretching that aligns with Chromium behavior, but add some clarification.The full IRC log of that discussion
<heycam> Topic: Does stretch work when width/height only behaves as auto?<heycam> github: https://github.com//issues/4525
<heycam> oriol: this is about grid items the default alignment is stretch
<heycam> ... this is supposed to stretch an element to cover tis container
<heycam> ... but not if the computed width computes to auto
<heycam> ... the spec has some ambiguity about computing to auto
<heycam> ... but it's "behaves" as auto
<heycam> ... FIrefox thinks this is the case, and instead of checking the computed value being auto, it checks whether it behaves as auto
<heycam> ... e.g. if you set the height to max-content it behaves as auto, in Firefox it stretches, but in Chromium it doesn't
<RossenF2F> q?
<heycam> ... the question is whether if the width/height is set to a value that behaves as auto but isn't auto itself, does this stretch?
<RossenF2F> q+
<heycam> fantasai: I think the author did not want automatic behavior
<heycam> ... in the most common behavior, automatic behavior is sizing to the content
<RossenF2F> Zakim, open queue
<Zakim> ok, RossenF2F, the speaker queue is open
<heycam> ... in the context of grid and flex, auto isn't equivalent to that
<heycam> ... if the author has set it to a value that's not auto, we shouldn't automatically stretch
<heycam> ... I think the spec is correct to rely on computing to auto, so we should align on Chromium's behavior
<heycam> TabAtkins: mats also says that sounds reasonable
<tantek_> is there a test case for Chromium's behavior?
<heycam> emilio: it's a bit weird that it max-content behaves as auto for some things but not others
<rego> tantek_:
<rego> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23grid%20%7B%0A%20%20display%3A%20grid%3B%0A%20%20width%3A%20100px%3B%0A%20%20height%3A%20100px%3B%0A%20%20grid-template%3A%20100%25%20%2F%20100%25%3B%0A%20%20background%3A%20yellow%3B%0A%7D%0A%23item%20%7B%0A%20%20height%3A%20max-content%3B%0A%20%20align-self%3A%20stretch%3B%0A%20%20background%3A%20cyan%3B%0A%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20id%3D%22grid%22%3E%0A
<rego> %20%20%3Cdiv%20id%3D%22item%22%3EText%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
<tantek_> IRC broke that
<tantek_> across a line
<rego> yep, linked on the issue
<rego> at the begginig
<rego> https://github.com//issues/4525
<tantek_> thank you
<heycam> RESOLUTION: Keep the spec text about auto and stretching that aligns with Chromium behavior, but add some clarification.
<heycam> astearns: let's get that test case into WPT
<fantasai> s/RESOLUTION/RESOLVED?
<fantasai> s/RESOLUTION/RESOLVED/
Don't stretch grid items with non-auto block-size.
Bug 1597055 - Don't stretch grid items with non-auto block-size. r=mats
Bug 1597055 - Don't stretch grid items with non-auto block-size. r=mats
Don't stretch grid items with non-auto block-size.
3 remaining items
fantasai commentedon Mar 6, 2020
Pushed some clarifications. @Loirooriol @MatsPalmgren Please file issues on anything else that looks suspicious. :) Thanks!
layout: Restrict stretch alignment to flex items with computed auto size
layout: Restrict stretch alignment to flex items with computed auto size
layout: Restrict stretch alignment to flex items with computed auto size
layout: Restrict stretch alignment to flex items with computed auto s…
layout: Restrict stretch alignment to flex items with computed auto size
Bug 1958006 [wpt PR 51801] - layout: Restrict stretch alignment to fl…
Bug 1958006 [wpt PR 51801] - layout: Restrict stretch alignment to fl…
Bug 1958006 [wpt PR 51801] - layout: Restrict stretch alignment to fl…
Bug 1958006 [wpt PR 51801] - layout: Restrict stretch alignment to fl…
Bug 1958006 [wpt PR 51801] - layout: Restrict stretch alignment to fl…
Bug 1597055 - Don't stretch grid items with non-auto block-size. r=mats
Bug 1958006 [wpt PR 51801] - layout: Restrict stretch alignment to fl…