Re: [css-grid] Content-size tracks and orthogonal flows

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
   * the sum of all definite min or max row sizes spanned by the item
   * the max-content size, if any row was max-content sized
   * the min-content size, if any row was min-content sized
but I'm not sure...

~fantasai (and TJ)

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