Skip to content

[css-sizing] Does indefinite stretch behave as automatic size or as initial value? #11006

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

Open
Loirooriol opened this issue Oct 5, 2024 · 11 comments

Comments

@Loirooriol
Copy link
Contributor

First, consider

<!DOCTYPE html>
<div style="min-height: max-content; height: 0; width: 200px; border: solid">lorem ipsum</div>
Spec, Blink Gecko, WebKit

@bfgeek told me that Blink had to deal with some breakage when they adopted this behavior, but that it's the correct thing to do. But what about stretch?

<!DOCTYPE html>
<div style="min-height: -moz-available; min-height: -webkit-fill-available; min-height: stretch; 
            height: 0; width: 200px; border: solid">lorem ipsum</div>
Spec Gecko, Blink WebKit

(WebKit seems to stretch elements with an indefinite height that contain some -webkit-fill-available, so it's always definite)

From https://drafts.csswg.org/css-sizing-4/#stretch-fit-sizing

Formally, its behavior is the same as specifying an automatic size together with a self-alignment property value of stretch

But here Blink is not implementing this, not sure if due to an oversight.

And then the situation is that browsers are implementing stretch, but nobody follows the spec here. It may be too late for *-content, but I would like to have an agreement for stretch before it ships. So Agenda+.

@Loirooriol
Copy link
Contributor Author

For Servo following the spec seems a bit simpler than aligning with Blink, so I guess I will go with that for now.

@bfgeek
Copy link

bfgeek commented Oct 8, 2024

Formally, its behavior is the same as specifying an automatic size together with a self-alignment property value of stretch

So I think this was intended just to be applicable to main sizes, (e.g. not min/max-sizes).

IMO this should be consistent with min-height: 100%, e.g. if a percentage is indefinite it behaves as zero for min-height, and Infinity for max-height.

(e.g. The Blink/Gecko behaviour).

For example it'd be pretty weird if:

<!DOCTYPE html>
<div style="max-height: stretch; height: 200px; width: 200px; border: solid">lorem ipsum</div>

got clamped by the intrinsic size (when stretch is an extrinsic constraint).

cc/ @tabatkins

@Loirooriol
Copy link
Contributor Author

I'm not convinced we should treat it like a percentage. For example, with a min/max-content of 100px, fit-content is basically clamp(100px, stretch, 100px), and in Blink max-height: fit-content behaves as 100px but max-height: clamp(100px, 100%, 100px) behaves as none. And doing this like Blink seems more annoying to implement in Servo.

So I think we should either:

@bfgeek
Copy link

bfgeek commented Oct 9, 2024

I'm not convinced we should treat it like a percentage. For example, with a min/max-content of 100px, fit-content is basically clamp(100px, stretch, 100px)

This isn't correct - we recently did a change to follow Firefox in this regard. See: #10721
When the stretch is indefinite - min-size: fit-content resolves to min-size: min-content, and max-size: fit-content to max-size: max-content respectively.

And doing this like Blink seems more annoying to implement in Servo.

I'm curious why this is difficult in Servo? This might result in difficulty when attempting to implement calc-size() for example.

I'm pretty convinced that we should just be consistent with 100% here, (again see the max-height:stretch example above, it'd be super weird if we coerce an explicitly extrinsic constraint to be intrinsic).

@Loirooriol
Copy link
Contributor Author

we recently did a change to follow Firefox in this regard. See: #10721

Not sure if that is the best behavior, I have commented there.

I'm curious why this is difficult in Servo?

I misunderstood what you were doing for fit-content, I thought it was trickier. Resolving keywords in different ways depending on the property and having a potentially indefinite stretch size during layout still adds some complexity. But not a big deal I guess.

it'd be super weird if we coerce an explicitly extrinsic constraint to be intrinsic

Maybe a bit weird indeed.

@Loirooriol
Copy link
Contributor Author

It's worth noting that there is a difference among major browsers:

  • Gecko treats an indefinite min-height: stretch as the initial auto
  • Blink and WebKit treat it as 0px
<!DOCTYPE html>
<div style="display: flex; flex-direction: column; border: solid cyan; min-height: 100px; width: 200px;">
  <div style="min-height: -moz-available; min-height: -webkit-fill-available; min-height: stretch;
              flex-basis: 0; border: solid">lorem ipsum</div>
</div>
Gecko Blink, WebKit

Interestingly, they all treat min-height: 0% as 0px.

@bfgeek
Copy link

bfgeek commented Oct 17, 2024

I wouldn't read too much into the block direction behaviour with FF (support was lacking last time I checked).

@dholbert
Copy link
Member

dholbert commented Oct 17, 2024

Indeed, the FF behavior is just because I haven't implemented stretch behavior in the block axis yet (keep getting distracted by other tasks, but made a little local progress this week, hope to be done soonish).

@Loirooriol
Copy link
Contributor Author

Sure, but if the spec changes, we need to decide whether min-height: stretch should behave as auto or as 0px or whatever 100% would do (the spec says that 100% should behave as 0px, but browsers don't follow the spec in general).

@davidsgrogan
Copy link
Member

davidsgrogan commented Dec 9, 2024

Formally, its behavior is the same as specifying an automatic size together with a self-alignment property value of stretch

So I think this was intended just to be applicable to main sizes, (e.g. not min/max-sizes).

IMO this should be consistent with min-height: 100%, e.g. if a percentage is indefinite it behaves as zero for min-height, and Infinity for max-height.

(e.g. The Blink/Gecko behaviour).

For example it'd be pretty weird if:

<!DOCTYPE html>
<div style="max-height: stretch; height: 200px; width: 200px; border: solid">lorem ipsum</div>

got clamped by the intrinsic size (when stretch is an extrinsic constraint).

cc/ @tabatkins

I talked to @tabatkins about this a few weeks ago. He confirmed that the spec editors intended the Blink/Gecko behavior (min-size:stretch resolves to 0 and max-size:stretch resolves to infinity when available size is indefinite) and that it was indeed on the editors to better define the spec around min/max sizes behaving as auto, which should hopefully clear up the confusion here.

@astearns astearns moved this to FTF agenda items in CSSWG January 2025 meeting Jan 22, 2025
@astearns astearns moved this from FTF agenda items to Regular agenda items in CSSWG January 2025 meeting Jan 22, 2025
@Loirooriol Loirooriol moved this from Regular agenda items to FTF agenda items in CSSWG January 2025 meeting Jan 23, 2025
@astearns astearns moved this from FTF agenda items to Friday morning in CSSWG January 2025 meeting Jan 28, 2025
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-sizing] Does indefinite `stretch` behave as automatic size or as initial value?, and agreed to the following:

  • RESOLVED: min-size: stretch behaves as zero, max-size; stretch as infinity, when in an indefinite container
The full IRC log of that discussion <fantasai> oriol: Spec says stretch size is same behavior as automatic size + stretch alignment
<fantasai> oriol: but it doesn't restrict this defintion to preferred size property
<fantasai> oriol: my understanding is you can set this in min or max property
<fantasai> oriol: I've been implementing in servo, but doesn't match other browsers
<fantasai> oriol: they don't support keywords in the block axis
<fantasai> oriol: it ignores it in min-size, and in max-size it treats it as none
<fantasai> oriol: from what davidsgrogan said, this was the intention of the editors of the spec ?
<TabAtkins> fantasai: that seems a bit weird, if we're not supporting it we just shoudln't parse it
<TabAtkins> oriol: the status is inconsistent because browsers have been implementing these things...
<fantasai> oriol: state is inconsistent because actively changing implementations
<fantasai> oriol: in Firefox these keywords work in inline axis, but not in block one
<fantasai> oriol: and then you need to parse the value because you don't know the writing mode
<fantasai> oriol: Blink obeys these keywords in both axes
<fantasai> fantasai: is there a reason we can't make it mean what it says in the min/max properties?
<TabAtkins> fantasai: from an authors' perspective, stretch means "i want to fill the container"
<TabAtkins> fantasai: so if you said "i would like this box to have a width of 100px but a max-width of stretch", then it should be 100px if the container is larger than 100px but filling it exactly if it's smaller
<TabAtkins> fantasai: that's what i'd expect
<TabAtkins> oriol: this is just when the stretch size is indefinite, so we don't know the container size
<TabAtkins> oriol: so it happens in the block axis in block layout
<fantasai> fantasai: Ah, in that case that make ssense
<fantasai> oriol: Ian says 'stretch' is an extrinsic value, would be weird to treat it as intrinsic.
<fantasai> oriol: what I did in servo is slightly simpler to implement, but aligning with Blink is ok
<fantasai> astearns: resolving stretch to zero, infinity when available size is indefinite
<fantasai> astearns: can we resolve on it?
<fantasai> astearns: any objections
<fantasai> RESOLVED: min-size: stretch behaves as zero, max-size; stretch as infinity, when in an indefinite container

Loirooriol added a commit to Loirooriol/servo that referenced this issue Feb 24, 2025
We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Loirooriol added a commit to Loirooriol/servo that referenced this issue Feb 24, 2025
We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
servo-wpt-sync pushed a commit to servo/wpt that referenced this issue Feb 24, 2025
We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Loirooriol added a commit to Loirooriol/servo that referenced this issue Feb 24, 2025
We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
servo-wpt-sync pushed a commit to servo/wpt that referenced this issue Feb 24, 2025
We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Loirooriol added a commit to Loirooriol/servo that referenced this issue Feb 24, 2025
We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
servo-wpt-sync pushed a commit to servo/wpt that referenced this issue Feb 24, 2025
We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
Loirooriol added a commit to Loirooriol/servo that referenced this issue Feb 24, 2025
We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
servo-wpt-sync pushed a commit to servo/wpt that referenced this issue Feb 24, 2025
We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
github-merge-queue bot pushed a commit to servo/servo that referenced this issue Feb 24, 2025
…35630)

We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
servo-wpt-sync pushed a commit to web-platform-tests/wpt that referenced this issue Feb 24, 2025
We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Feb 28, 2025
…in and max sizing properties, a=testonly

Automatic update from web-platform-tests
layout: Ignore indefinite `stretch` on min and max sizing properties

We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>

--

wpt-commits: 240b357348202856b077417a3ebf944301776a89
wpt-pr: 50899
i3roly pushed a commit to i3roly/firefox-dynasty that referenced this issue Feb 28, 2025
…in and max sizing properties, a=testonly

Automatic update from web-platform-tests
layout: Ignore indefinite `stretch` on min and max sizing properties

We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>

--

wpt-commits: 240b357348202856b077417a3ebf944301776a89
wpt-pr: 50899
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Mar 1, 2025
…in and max sizing properties, a=testonly

Automatic update from web-platform-tests
layout: Ignore indefinite `stretch` on min and max sizing properties

We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufauigalia.com>

--

wpt-commits: 240b357348202856b077417a3ebf944301776a89
wpt-pr: 50899

UltraBlame original commit: 87b514ad66067255350da365930ea427338a299e
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Mar 1, 2025
…in and max sizing properties, a=testonly

Automatic update from web-platform-tests
layout: Ignore indefinite `stretch` on min and max sizing properties

We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufauigalia.com>

--

wpt-commits: 240b357348202856b077417a3ebf944301776a89
wpt-pr: 50899

UltraBlame original commit: 87b514ad66067255350da365930ea427338a299e
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Mar 1, 2025
…in and max sizing properties, a=testonly

Automatic update from web-platform-tests
layout: Ignore indefinite `stretch` on min and max sizing properties

We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufauigalia.com>

--

wpt-commits: 240b357348202856b077417a3ebf944301776a89
wpt-pr: 50899

UltraBlame original commit: 87b514ad66067255350da365930ea427338a299e
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Mar 5, 2025
…in and max sizing properties, a=testonly

Automatic update from web-platform-tests
layout: Ignore indefinite `stretch` on min and max sizing properties

We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>

--

wpt-commits: 240b357348202856b077417a3ebf944301776a89
wpt-pr: 50899
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Mar 17, 2025
fit-content for the min-contribution calculation should be treated as
min-content, and for the max-contribution max-content. As per:
w3c/csswg-drafts#10721

Fixes tests for min-width:stretch to resolve as zero, and
max-width:stretch as infinity as per:
w3c/csswg-drafts#11006

Fixed: 402760799
Change-Id: I109ffdd057db45236e3f95f174e0ab8b684060d5
aarongable pushed a commit to chromium/chromium that referenced this issue Mar 17, 2025
fit-content for the min-contribution calculation should be treated as
min-content, and for the max-contribution max-content. As per:
w3c/csswg-drafts#10721

Fixes tests for min-width:stretch to resolve as zero, and
max-width:stretch as infinity as per:
w3c/csswg-drafts#11006

Fixed: 402760799
Change-Id: I109ffdd057db45236e3f95f174e0ab8b684060d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6357845
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1433610}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Mar 17, 2025
fit-content for the min-contribution calculation should be treated as
min-content, and for the max-contribution max-content. As per:
w3c/csswg-drafts#10721

Fixes tests for min-width:stretch to resolve as zero, and
max-width:stretch as infinity as per:
w3c/csswg-drafts#11006

Fixed: 402760799
Change-Id: I109ffdd057db45236e3f95f174e0ab8b684060d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6357845
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1433610}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Mar 17, 2025
fit-content for the min-contribution calculation should be treated as
min-content, and for the max-contribution max-content. As per:
w3c/csswg-drafts#10721

Fixes tests for min-width:stretch to resolve as zero, and
max-width:stretch as infinity as per:
w3c/csswg-drafts#11006

Fixed: 402760799
Change-Id: I109ffdd057db45236e3f95f174e0ab8b684060d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6357845
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1433610}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Mar 18, 2025
…ne-sizes for contributions., a=testonly

Automatic update from web-platform-tests
[layout] Fix fit-content on min/max inline-sizes for contributions.

fit-content for the min-contribution calculation should be treated as
min-content, and for the max-contribution max-content. As per:
w3c/csswg-drafts#10721

Fixes tests for min-width:stretch to resolve as zero, and
max-width:stretch as infinity as per:
w3c/csswg-drafts#11006

Fixed: 402760799
Change-Id: I109ffdd057db45236e3f95f174e0ab8b684060d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6357845
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1433610}

--

wpt-commits: bd81ee4af33248ccd3a153a9389876d8f4b51166
wpt-pr: 51392
glandium pushed a commit to mozilla-firefox/firefox that referenced this issue Apr 1, 2025
…in and max sizing properties, a=testonly

Automatic update from web-platform-tests
layout: Ignore indefinite `stretch` on min and max sizing properties

We were always treating an indefinite `stretch` as the automatic size.
This instead treats it as `0px` on min sizing properties, and as `none`
on max sizing properties, aligning with Blink and this recent CSSWG
resolution: w3c/csswg-drafts#11006

Signed-off-by: Oriol Brufau <obrufau@igalia.com>

--

wpt-commits: 240b357348202856b077417a3ebf944301776a89
wpt-pr: 50899
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Friday morning
Development

No branches or pull requests

6 participants