[css-sizing] need to be clear about inputs to computation of min-content, max-content, and fit-content sizes

[dbaron]

Prior to the presence of orthogonal flows introduced by css-writing-modes, min-content and max-content sizes were a function only of an element and its descendants (their content and their styles, though excluding the (min-/max-/)(width/height) properties on the element itself). The fit-content size is derived from these sizes, but is also a function of an additional input that is provided (an "available width").

To accomodate orthogonal flows, this has changed so that these sizes are a function of a width in the opposite dimension. For example, the min-content width is now a function of an available height, since if the content is in a vertical writing mode it needs to lay out at that available height to determine the resulting layout width.

css-sizing-1 should be clearer about these concepts requiring this external input and not being purely a function of the content. This is important because every spec that uses these concepts needs to provide this input. Then, all of the other specs that refer to these concepts need to say what inputs they are providing. (To provide a random example, the definition of min-content main size in flexbox says it depends on the min-content contributions of the flex items, but it doesn't say what cross-size is used as the available width input to that computation.)

Furthermore, it's not clear to me that this is the only input. These concepts may also require a containing block size in one or both dimensions to be provided in order to allow percentage sizes to be resolved. (The containing block size may be different from the available size in the dimension in which the available size is provided.) For example,, when performing layout of horizontal text within an available width, the height resulting from that layout depends on how percentage heights and widths are resolved. It's not clear to me if some of the users of these intrinsic sizes require these percentages to be resolved against something nonzero or whether layout-based intrinsic size calculations should work like traditional intrinsic size calculations by treating percentage sizes as zero.

[fantasai]

To resolve this issue, we need to

• Prove that the intrinsic width of a box does not depend on its available width, only (sometimes) on available height.
• Be clear in sizing that its intrinsic size can depend available height, and ensure that the available height is always defined for this calculation.

[tabatkins]

For first bullet point, I want to make sure that, whenever a layout might ask for the available space in an axis that we're calculating the intrinsic size of, we correctly report that it's an infinite size. (Rather than trying to figure out an available space, or asking calling locations to provide one.) Then, yeah, make sure that any time a layout algorithm depends on a size, and that size turns out to be infinite, it has a fallback behavior defined.

[tabatkins]

For second bullet point, hopefully we can define that the available other-axis space is always either (a) fixed, or (b) infinite, with "fixed" meaning "a length", or "definite", or something in-between. Generally speaking, "fixed" should be trivially determinable from the tree, so any calling code (that is, layout algos that ask for an intrinsic size) don't have to provide an other-axis available space themselves.

[nicoburns]

The inputs I have been using when implementing this is a SizingConstraint and a ContainingBlockLength in each axis where:

enum SizingConstraint = MinContent | MaxContent | FitContent(px_available_space) | Exact(px_size_override)
and
enum ContainingBlockLength = Some(px_length) | None

The Exact sizing constraint is used in cases where the size of a child in one axis has already been determined by a previous step in the parent's layout algorithm. For example, it would be used for the main axis of a Flexbox item when resolving the cross-sizer of that item once it's main size has been resolved.