- From: Oriol Brufau via GitHub <noreply@w3.org>
- Date: Mon, 16 Feb 2026 03:00:40 +0000
- To: public-css-archive@w3.org
Actually, this depends on #12333. Because if we accept that replaced elements resolve intrinsic keywords in the block axis in order to resolve intrinsic keywords in the inline axis, then the behavior that we get is basically the same as in my proposal 2 above. Basically, the process is: 1. Find the tentative inline size that we would get if all sizing properties (in both axes) were set to their initial values. In this case, it's the stretch size 2. Find the tentative block size by looking at the sizing properties in the block axis, resolving intrinsic keywords to the result of transferring (1) thru the aspect ratio 3. Find the final inline size by looking at the sizing properties in the inline axis, resolving intrinsic keywords to the result of transferring (2) thru the aspect ratio 4. Find the final block size by looking at the sizing properties in the block axis, resolving intrinsic keywords to the result of transferring (3) thru the aspect ratio So we don't really need to redefine min/max-content to get this behavior, we get it automatically. Since at (2) we can resolve everything, (3) gets an exact sizing constraint from the block axis, so that's the only choice for `min/max-content`. I'm quite puzzled that Blink does this weird thing of varying the behavior depending on the property, and WebKit has a completely different behavior. Stretching only for `auto` but not for `min/max-content` only makes sense if in #12333 we decide to make replaced elements consistent with non-replaced ones. Then at (2) we can't resolve intrinsic keywords, so (3) can indeed get just a min and a max constraints from the block axis, thus being able to choose which value to pick within that interval (e.g. stretch size or 300px). -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13149#issuecomment-3906189463 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 16 February 2026 03:00:41 UTC