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

@bfgeek

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+.

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

@tabatkins

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'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:

Keep the spec as-is, or
Treat both fit-content and stretch as containing a cyclic percentage.
More specifically, treat fit-content as fit-content(100%) and stretch as 100%, so:
- For preferred and max properties they both behave as the initial value (with some special behavior for replaced elements)
- For min properties see [css-sizing] Nobody follows the spec about cyclic percentages in min sizing properties #10969

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).

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.

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.

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

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).

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).

@tabatkins

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.

Bug 1950067 [wpt PR 50899] - layout: Ignore indefinite `stretch` on m…

[layout] Fix fit-content on min/max inline-sizes for contributions.

Bug 1954553 [wpt PR 51392] - [layout] Fix fit-content on min/max inli…

Bug 1950067 [wpt PR 50899] - layout: Ignore indefinite `stretch` on m…

Bug 1954553 [wpt PR 51392] - [layout] Fix fit-content on min/max inli…

[css-sizing-3] Clarify indefinite stretch sizing #11006

Navigation Menu

Repository navigation

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

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

Loirooriol commented on Oct 5, 2024

bfgeek commented on Oct 8, 2024

Loirooriol commented on Oct 9, 2024

bfgeek commented on Oct 9, 2024

Loirooriol commented on Oct 17, 2024

Loirooriol commented on Oct 17, 2024

bfgeek commented on Oct 17, 2024

dholbert commented on Oct 17, 2024

Loirooriol commented on Oct 18, 2024

davidsgrogan commented on Dec 9, 2024

21 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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