1. Introduction
Traditional document layout, and many of the formatting primitives in CSS, are based on the model where sizes in the inline dimension (in Latin text, widths) are the input to the layout algorithm and sizes in the block dimension (in Latin text, heights) are the output. For example, when laying out a newspaper article, the width of the column is the input, and the words then fill a certain height, which is the output. In a layout algorithm based on a tree structure like HTML or XML, this means that inline sizes (widths) are computed from the top of the tree down to the leaves, and block sizes (heights) are computed from the leaves back up to the root.
However, there are cases where layout algorithms want to use widths that are derived from the content. For example, table layout should size the table columns so that the ones with more content consume more of the space, or figures floated (with float) to the side of the layout should use the width that the figure requires.
For this purpose, CSS describes two intrinsic inline-sizes (widths). These are the min-content size, which is intended to be the smallest inline-size that an element can become without overflowing, and the max-content size, which is intended to be the largest inline-size that an element can be without wasting extra space that was allocated to it. The rules for calculating these sizes vary between the layout primitives in CSS (roughly corresponding to the values of display). These are calculated while traversing the tree from leaves towards the root: the intrinsic sizes of an element depend on those of its descendants, but not those of its ancestors. These sizes can be computed prior to the layout algorithm, which sometimes depends on them. Thus the overall process of layout could be thought of as an upward pass over the tree to compute intrinsic inline sizes, followed by a downward pass over the tree to compute final inline sizes, and then an upward pass over the tree to compute final block sizes. (This is a simplification, and doesn’t apply to all formatting primitives.)
The rules for calculating intrinsic sizes do not always produce the results that the CSS author wants. Sometimes this is because the rules are approximations; other times this is because the intrinsic sizes are used in specific ways that the author would like to modify, without modifying properties that affect the final layout of the element.
Therefore, I propose adding properties that allow CSS authors to modify the intrinsic sizes directly, without having other effects on layout.
2. Assigning Intrinsic Inline Sizes
| Name: | min-content-inline-size, max-content-inline-size |
|---|---|
| Value: | auto | [ [ <length> | contents ] && use-inline-size? && use-min-inline-size? && use-max-inline-size? ] |
| Initial: | auto |
| Applies to: | all elements but non-replaced inline elements, table rows, and table row groups, and table column groups |
| Inherited: | no |
| Percentages: | n/a |
| Media: | visual |
| Computed value: | as specified, with lengths made absolute |
| Canonical order: | per grammar |
| Animation type: | length or discrete The animation type needs to be more formal |
- auto
- Equivalent to contents use-inline-size use-min-inline-size use-max-inline-size.
- <length>
- Use the given length as the min-content inline size or the max-content inline size of the element.
- contents
- Compute the min-content inline size or the max-content inline size of the element as normal. (This is the normal behavior.)
- use-inline-size
- When computing the min-content contribution or the max-content contribution of the element, consider the computed value of inline-size. (This is the normal behavior.)
- use-min-inline-size
- When computing the min-content contribution or the max-content contribution of the element, consider the computed value of min-inline-size. (This is the normal behavior.)
- use-max-inline-size
- When computing the min-content contribution or the max-content contribution of the element, consider the computed value of max-inline-size. (This is the normal behavior.)
The current proposal uses logical names only (inline-size) without providing physical names (width, height). Providing physical names could be done. However, it would significantly increase the number of new properties, while creating some new properties that would only work some of the time, and require yet another set of properties that have physical and logical equivalents.
The way this proposal allows separately ignoring or honoring inline-size, min-inline-size, and max-inline-size adds a good bit of complexity. Is it useful enough to be worthwhile?
Need to decide whether the <length> value affects the min-content, max-content, and fit-content keywords for inline-size, min-inline-size, max-inline-size, width, etc.
Need to describe the meaning on table cells and columns in a little more detail. Presumably cells are straightforward, and setting on a column overrides the contributions from all of the cells, and the use-inline-size etc. keywords only apply to the inline-size of the element they’re specified on.
Add example of some 100%-width images in a grid track whose size is determined by something else.
3. Security and Privacy Considerations
By changing the math of layout calculations, this document introduces no new security or privacy considerations.
4. Acknowledgements
The author wishes to thank Rachel Andrew, Elika J. Etemad (fantasai), Jen Simmons, and the CSS Working Group for participating in various discussions that led to this proposal.