[css-grid] Content-size tracks and orthogonal flows from fantasai on 2016-01-20 (www-style@w3.org from January 2016) (original) (raw)

On 12/18/2015 09:55 AM, Javier Fernandez wrote:

Hi,

Using this old thread to add some additional doubts that came out while implementing orthogonal flows support for Grid Layout.

On 12/19/2014 09:38 PM, fantasai wrote:

On 02/10/2014 01:47 PM, Simon Sapin wrote:

However, this only works if the grid item and grid container have "parallel" writing modes. (Ie. both vertical or both horizontal.) What happens if a grid item is an "orthogonal flow"? (As defined in css-writing-modes.)

If the minimum content size of any Grid item has changed based on available height for the Grid item as computed in step 2, adjust the min content size of the Grid item and restart the Grid track Sizing algorithm (once only).

Assuming a grid item establishing an orthogonal flow, with both width and height as 'auto', I'd like to clarify if the following assumptions are correct and compliant with the current Grid Layout spec.

1- Column track's size is based on item's logical height for orthogonal flows.

The track sizing algorithm defined in the spec states that we must start computing the column track's width. In the case of an item with an orthogonal flow, this operation would imply using its logical height. This may be kind of obvious but I'd prefer someone confirming this is a valid assumption because the rest of my arguments are based on it.

Yes.

2- We may have to estimate row track's size in order to determine item's logical height.

So, since we might not know yet the item's logical height (width could be auto and it would depend on the row track breadth, which we haven't computed yet), we can estimate it, as the spec indicates:

"If calculating the layout of a grid item in this step depends on the available space in the block axis, assume the available space that it would have if any row with a definite max track sizing function had that size and all other rows were infinite."

Based on the assumed row track's breadth, we can determine grid item's logical height and set the column track's breadth accordingly.

Yes.

3- Row track's size is based on item's (min/max) preferred width for orthogonal flows.

Next step in the track sizing algorithm is to determine row track's breadth, which would depend on the item's width. We are assuming that in case of orthogonal flows, row track's size doesn't depend on column track's size, but just on its content (like it happens when computing column track's size based on parallel items).

For content-sized column tracks and items with parallel flow we are using minPreferredWidth and maxPreferredWidth for min-content and max-content track's sizes respectively. These values are then used as track's baseSize and growthLimit, respectively, during the track sizing algorithm.

In order to compute row track's min-content and max-content sizes, based on orthogonal grid items, we are using also those minPreferredWidth and maxPreferredWidth values. Is this assumption compliant with the specs ?

Yes... but note that this will give incorrect sizes in some cases if you forget step #3 in https://drafts.csswg.org/css-grid/#algo-overview :)

On that note, step #3 should probably say "min-content or max-content contribution" in place of "min-content contribution".

I'm wondering now if having a smarter heuristic up front for the row-height, instead of infinity, would result in better (more accurate and/or faster) layouts. E.g. for the orthogonal item we're trying to size columnwise, assume the row-height is the max of

~fantasai (and TJ)

Received on Wednesday, 20 January 2016 00:09:49 UTC