Re: [csswg-drafts] [css-grid] Can the sizing algo be made to deal with this (#2356)

So a few observations on the problem of computing intrinsic widths of columns in a table in the presence of column-spanning cells, which is a problem somewhat related to this one.  (I feel like I've written this down before, but I can't find it, so I may as well write it down again.)  The table case only has to deal with one set of widths at a time; I'm not sure whether that's the same for grid.

The simplest solution to the problem, and the one that gives the mathematically minimal solution, is to progressively compute the widths of each from one side of the table to the other, assigning the column the smallest width needed to accomodate all of the cells that end (in the direction the columns are being traversed) in that column.  This solution is not useful because, while it gives the smallest possible table, the assignment of widths to columns is often poor.  For example,

```html
<table border>
  <tr><th colspan=3>This is a long heading
  <tr><td>1<td>2<td>3
</table>
```

produces a table that looks like:

<table border>
  <tr><th colspan=3>This is a long heading</tr>
  <tr><td width=1>1<td width=1>2<td>3</tr>
</table>


So in practice, the algorithm used is roughly the following (at least in Gecko [since 2007](https://wiki.mozilla.org/Gecko:Reflow_Refactoring) and Chromium [since 2022](https://www.chromium.org/blink/layoutng/)); WebKit may differ in a few respects as described below although I haven't really tested any of this stuff since around 2007 or 2008:

1. for each column, maintain two copies of the intrinsic width that we're computing (note that we may compute min-content and max-content and percentage widths at the same time, but each one requires holding two values): the permanent value and the temporary value.
2. Initially, take all the non-column-spanning cells, and store the width needed for the largest cell in the column in the permanent value for its column.  (Note that there's some interaction between the max-content and percentage values that I'll ignore here since it's not relevant.)
3. Then, for each value of column-span that exists in the table, in increasing order (2, 3, 4, etc.):
   1. Examine all the cells with that column-span value, and for each such cell, if the sum of the values already allocated to the permanent width values of the columns that it spans is not sufficient to hold the width needed by the cell, distribute that excess to the columns according to roughly the same width distribution algorithm that is used to distribute excess table width to the cells, and increase the temporary value for the column to be at least that column's portion of the excess
   2. Add each column's temporary value to the permanent value, and set the temporary value back to zero for the next iteration of the loop over column-span numbers.  This separation of the temporary and permanent values means that the order that the column-spanning cells are traversed doesn't affect the layout, since no cell with colspan N affects the widths distributed by a different cell that also has colspan N or smaller, but it affects the widths distributed by all cells that have colspan larger than N.

Note that some implementations do not do all of these things.  In particular, at least some of (Gecko pre-2007, Chromium pre-LayoutNG, WebKit, and EdgeHTML) did not do the temporary/permanent buffer setup, which leads to similarly (as above) bad distributions of widths when there are column-spanning cells whose spanned columns partially overlap.  It's also possible that there may be some of those implementations that did the temporary/permanent buffer setup but didn't do the integer sort, although I don't think so (at least not in the long term).  I think there were also some implementations whose distribution of the width of spanning cells may have followed rules more different from the regular table width distribution rules.

The above rules tend to strike a good balance between producing smallest-possible results and producing results with a balanced distribution of widths between columns.

-- 
GitHub Notification of comment by dbaron
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2356#issuecomment-1940409358 using your GitHub account


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

Received on Tuesday, 13 February 2024 04:34:22 UTC