-
Notifications
You must be signed in to change notification settings - Fork 711
[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
Comments
For Servo following the spec seems a bit simpler than aligning with Blink, so I guess I will go with that for now. |
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 (e.g. The Blink/Gecko behaviour). For example it'd be pretty weird if:
got clamped by the intrinsic size (when cc/ @tabatkins |
I'm not convinced we should treat it like a percentage. For example, with a min/max-content of 100px, So I think we should either:
|
This isn't correct - we recently did a change to follow Firefox in this regard. See: #10721
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 |
Not sure if that is the best behavior, I have commented there.
I misunderstood what you were doing for
Maybe a bit weird indeed. |
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 |
Sure, but if the spec changes, we need to decide whether |
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. |
The CSS Working Group just discussed
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 |
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>
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>
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>
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>
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>
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>
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>
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>
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>
…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>
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>
…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
…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
…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
…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
…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
…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
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
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}
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}
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}
…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
…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
First, consider
@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
?(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
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 forstretch
before it ships. So Agenda+.The text was updated successfully, but these errors were encountered: