W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: [css3-flexbox] Calculating flexbox dimensions

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 25 Feb 2011 09:37:00 -0800
Message-ID: <AANLkTikxO1pigKMs1jzGHvkJ3CRjKKiD4dbOjLRu7kM3@mail.gmail.com>
To: Alex Mogilevsky <alexmog@microsoft.com>
Cc: www-style list <www-style@w3.org>
On Thu, Feb 24, 2011 at 11:46 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> I think your questions are about mixed-direction layout in general, not just about flexbox. When content in orthogonal direction is unconstrained, there is no god solution for default size. We have discussed that in Beijing (it looks like the minutes were not public yet then, but you can find them).
> There is a few of ways to deal with underconstrained orthogonal flows
> 1) Do nothing. Authors have to provide appropriate sizes or constraints to get any reasonable results. Also, the situation is rare, so if poorly authored document is displayed poorly it is not really a problem.
> 2) Try to produce layout of a reasonable shape that can work with the orthogonal flow. For example, estimate amount of text and lay it out as a square.
> 3) Put an arbitrary constraint that can make underspecified content usable (although not necessarily elegant). For example constrain orthogonal content with viewport width or height.
> In IE5.5 (first to have vertical text) we in fact did (2). If a piece of vertical text in the middle of horizontal document (or in a table cell) didn't have specified height we tried to make it a square (which involved binary search layout). It was fun, but since then I have converted to philosophy that being too smart in technology is not always good.
> In Beijing, we have decided that constraining orthogonal flow with viewport height (or width) is a reasonably good default, because it (a) allows to scroll content to a point when it is readable and (b) is actually a very good default when the orthogonal element is the first element with content in the document (e.g. body).
> The latter is what we did in IE8 and IE9, with adjustment by applicable margins, borders and paddings. CSS3 writing-mode spec should be saying the same thing (not sure where).

That was an excellent and really useful summary, Alex.  Thanks!  I
think you're right that using the constraint of 100vh is reasonable -
it's roughly analogous to the restriction to the container's width in
horizontal flow.

I think I can now write the section I was stumped on.

> I am not sure if I am really answering your question, but I really don't think flexbox needs to have any code that deals with orthogonal flow. Whatever shrink-to-fit does in floats, tables or inline blocks it should do in flexbox.

It would be great if I could ignore the issue and simply defer to
existing layout algorithms, but I'm not sure that these are defined
anywhere.  I'd rather not rely on undefined behavior simply because
other things already rely on the same undefined behavior.

I'll work on defining this for Flexbox explicitly right now, and if we
do have (or will have) a more general algorithm with sufficient hooks,
I'll switch over to that.  I really want to get this Editor's Draft
finished first, though.  ^_^

Received on Friday, 25 February 2011 17:37:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC