w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.49k stars 662 forks source link

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

Open dbaron opened 6 years ago

dbaron commented 6 years ago

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 commented 6 years ago

To resolve this issue, we need to

tabatkins commented 6 years ago

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 commented 6 years ago

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 commented 3 months ago

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.