Re: [css3-flexbox] hypothetical size with orhogonal writing modes

On Thu, May 10, 2012 at 12:51 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> ± From: fantasai [mailto:fantasai.lists@inkedblade.net]
> ± Sent: Wednesday, May 09, 2012 3:37 PM
> ±
> ± On 05/08/2012 05:40 PM, Alex Mogilevsky wrote:
> ±
> ± > Actually I think at the hypothetical main size step, all items should just have
> ± infinite available space on main axis and actual available size on cross axis (defined
> ± or not), and it will do the right thing in parallel and orthogonal flows. Working on a
> ± proof.
> ±
> ± This is identical to what's there already except in the case of ''fill-available''
> ± and ''fit-content'' sizing, in which case you do need the available size to not be
> ± infinite in the main axis if it's in fact defined. So we think the spec is currently
> ± correct.
> ±
> ± Are we missing anything?
>
> It may be correct already, then I am just confused by what it says about orthogonal writing modes. If ever the algorithm branches based on writing mode and it actually changes the results, it should follow the same branch when the child is an orthogonal flexbox or if it is a parallel block that has orthogonal children.
>
> If all off the above just works, then the algorithm doesn't even need to mention writing modes here...

The only reason it branches at all is because an ''auto'' size has a
very slightly different resolution in orthogonal flows - it resolves
as min(100vmin, available size from parent) even if the parent's
available size is definite.  The branch in the layout algo ensures
that we properly trigger that case in the Writing Modes algo.

Ignoring that branch, the two clauses actually just split into "row
flexbox" and "column flexbox".

~TJ

Received on Wednesday, 9 May 2012 23:09:27 UTC