W3C home > Mailing lists > Public > www-style@w3.org > January 2015

[css-sizing] variations on max-content/preferred sizing

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 23 Jan 2015 22:01:35 -0500
Message-ID: <54C30B0F.5040901@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
This was raised in reference to Flexbox [1], but I wanted to raise
it again for discussion.

We have a definition for max-content size. But there are really two
different sizes that we're interested in here:

   * the maximum possible size the element can take without wasted space
     (this will generally result in the shortest height)
   * the size the element is "happiest" to be

In general, they're the same thing, but for multi-column elements,
at least, they're not the same thing. A multicolumn element's
"happiest" size, if it has both column-width and column-count set,
is column-width x column-count.

However, if you place a multicol element inside a container that
is wider than that, it will stretch itself out to fill that container;
and if some of its content has an unwrapped size wider than column-width,
then this will cause the columns to shorten; and it won't be until the
column width is as wide as the widest max-content child that the extra
space is "wasted". [2]

Currently Tab and I are thinking of naming the first concept
'max-content' size (since it is a true maximum) and the second concept
'preferred' size, at least in the spec.

But as far as authors are concerned, they probably really want the
'preferred' size. It's just the layout engine that might need to
know the max-content size.

Thoughts?

[1] http://www.w3.org/mid/CAAWBYDAj1-hKTPC00VNj=CzjDP-QjxXRTgd3KHvP6sYRKO+VxQ@mail.gmail.com
[2] A similar situation could be said to exist with floats in blocks,
     given that engines shrink-to-fit around floats that are stacked,
     even though they are able to fill more space if they happen to
     fit side-by-side.

~fantasai
Received on Saturday, 24 January 2015 03:02:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:50 UTC