[css-sizing-4] Splitting intrinsic size / content-based size into two concepts #5305
Comments
|
The abridged version of https://drafts.csswg.org/css-sizing-4/#aspect-ratio-minimum is
Today, engines don't use min-content size for the automatic minimum size of the ratio-dependent axis. They use min-intrinsic or whatever the final name of "content-based size ignoring aspect ratio" is going to be. If I'm wrong, I hope someone corrects me. |
webkit-early-warning-system
pushed a commit
to sammygill/WebKit
that referenced
this issue
Oct 22, 2022
…lex items. https://bugs.webkit.org/show_bug.cgi?id=246755 rdar://101346126 Reviewed by Rob Buis. There has been a lot of conversation on computing the min-content size for flex items when computing the content size suggestion. In particular, there were potential issues when computing the min-content size for non-replaced flex items that were given an aspect-ratio property. This issue was brought up in the following CSSWG conversation: w3c/csswg-drafts#6794 When the conversation was initially created, browsers all had different behaviors. A patch was added to make WebKit behavior similar to the behavior of Blink: WebKit#3025 The patch added behavior to take the aspect ratio into consideration when computing these sizes. This behavior ended up being incorrect by the time consensus was reached. The final decision seems to be that we should be computing the min-intrinsic size, which does not take into consideration the aspect-ratio and is just based off of the content. The idea of the min-intrinsic size was introduced here: w3c/csswg-drafts#5305 Since our initial behavior was close to the behavior that was eventually agreed upon, this patch ends up being mostly a revert. It is not completely a revert, however, since there are still some pieces left in from the initial patch. If the item is a replaced element, we will start take into consideration the aspect-ratio and compute the size using computeMainSizeFromAspectRatioUsing. If the item is a non-replaced element, instead we will compute the size using computeMainAxisExtentForChild. This will compute the min-intrinsic size by calling either child.computeLogicalWidthInFragmentUsing or child.computeContentLogicalHeight. Spec reference: https://drafts.csswg.org/css-flexbox-1/#min-size-auto Follow up discussion: web-platform-tests/interop#139 * LayoutTests/TestExpectations: * LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/aspect-ratio/flex-aspect-ratio-002.html: * LayoutTests/imported/w3c/web-platform-tests/css/css-sizing/aspect-ratio/flex-aspect-ratio-004.html: Newest version of the tests * Source/WebCore/rendering/RenderFlexibleBox.cpp: (WebCore::RenderFlexibleBox::computeFlexItemMinMaxSizes): Canonical link: https://commits.webkit.org/255858@main
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Following up on #5032 (comment) and https://lists.w3.org/Archives/Public/www-style/2020Jul/0004.html
The min-content and max-content sizes are defined to take aspect-ratio into account (see above discussion for why). However, in our specs at least, we probably need a separate set of terms for talking about the content-based size ignoring aspect ratio. This issue is for naming this concept, auditing our specs to use it, and maybe also deciding whether not we want a separate set of keywords to represent it explicitly in our sizing properties.
Whatever that term is, it's probably good to match it with the middle part of what is currently
contain-intrinsic-size, also.Using
intrinsicis a bit tricky since we've been using intrinsic to refer to the min-content/max-content sizes for awhile. Also it's hard to pronounce/spell, so not a great candidate for author-facing APIs. Another suggestion wasnaturalsize, to match the DOM APIs on images. Other suggestions welcome, this is a bikeshedding issue.The text was updated successfully, but these errors were encountered: