[csswg-drafts] [css2] Clarify 10.6.2: height with auto sizing, intrinsic ratio, and intrinsic height (#12254)

gitspeaks has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css2] Clarify 10.6.2: height with auto sizing, intrinsic ratio, and intrinsic height ==
The logic in [10.6.2](https://drafts.csswg.org/css2/#inline-replaced-height) for resolving height when `height` is `auto` can be a bit confusing, mainly due to the ordering of conditions and the repeated use of “Otherwise.”

The section says:

> If [`height`](https://www.w3.org/Style/css2-updates/css2/visudet.html#propdef-height) and [`width`](https://www.w3.org/Style/css2-updates/css2/visudet.html#propdef-width) both have computed values of `auto` and the element also has an intrinsic height, then that intrinsic height is the used value of height.
>  Otherwise, if `height` has a computed value of `auto`, and the element has an intrinsic ratio, then the used value of height is:
>
> > (used width) / (intrinsic ratio)
>
> Otherwise, if `height` has a computed value of `auto`, and the element has an intrinsic height, then that intrinsic height is the used value of height.

The way the first “Otherwise” is written makes it seem like the intrinsic ratio is only used when intrinsic height isn’t available. That might be the intent, but the structure could be clearer.

It’s also confusing that intrinsic height appears twice once when both dimensions are `auto`, and again later when only height is `auto`. This raises the question of what happens when **both** an intrinsic height and an intrinsic ratio are available, especially when width is defined. The spec doesn’t explain how to resolve that situation or which one takes precedence.

There’s also a case that isn’t addressed at all: when both `height` and `width` are `auto`, and the element **only** has an intrinsic ratio (with no intrinsic height or width). According to [10.3.2](https://drafts.csswg.org/css2/#inline-replaced-width), that means the width is **undefined**  and if width is undefined, then calculating height from `(used width) / ratio` doesn’t work either. This seems like an intentional omission (because width is undefined, so height can’t be resolved), but it’s not obvious unless the reader is familiar with how 10.3.2 interacts with 10.6.2.


I suggest adding a short note to 10.6.2 to make this edge case clear. For example:

> **Note:** If both `height` and `width` are `auto`, and the element has only an intrinsic ratio (with no intrinsic width or height), then width is undefined (see 10.3.2), so height can't be resolved from the ratio either.

It’s a small clarification, but it would make the relationship between these two sections easier to follow.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12254 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 30 May 2025 08:16:18 UTC