Re: [css-multicol][css-sizing] Intrinsic Sizes of Multi-column Elements

Hi,

I was requested to follow up on my own reply here, with moar opinions:

Morten Stenshorne <mstensho@opera.com> writes (Thu, 19 Mar 2015 11:57:50 +0100):

> fantasai <fantasai.lists@inkedblade.net> writes:
>
>> Been looking into the intrinsic size of multi-column elements.
>> Testcase here:
>>   http://fantasai.inkedblade.net/style/tests/multi-col/intrinsic-sizing
>>
>> Here's my suggestions:
>>
>>
>> col-count only
>>   min = #cols * min-content [of contents]
>>   max = #cols * max-content
>>   Implemented by: Firefox, Chrome, IE
>
> + the column gaps ((#cols - 1) * column-gap). Yeah, makes sense.
>
>>   Rationale:
>>     Width of columns is totally flexible,
>>     so pick a size that respects min/max-content

I agree. This one is straight-forward and trivial.

>> col-width only
>>   min = min(col-width, min-content)
>>   max = col-width
>>   Implemented by: Firefox, IE
>>
>>   Rationale:
>>     Widest possible column is column-width*2-ɛ.
>>     But if columns happen to be column-width (as requested),
>>     then any content outside that overflows and is clipped.
>>     It makes sense that the column-width becomes a limit
>>     on the content's size contribution.
>>
>>     The narrowest possible column is zero. If the min-content
>>     is less than the column-width, then we can become that
>>     small.

So the result will always be a used column-count of 1. That's pretty
useless, but I cannot think of anything better that's not weird. Except
for this, perhaps: One could imagine that it could be useful and not
super-weird to take explicit column breaks (break-foo:always) breaks
into account:

    tentative-column-count = number of explicit breaks + 1
    max = col-width * tentative-column-count + col-gap * (tentative-column-count - 1)

>> col-width + col-count
>>   min = min(col-width, min-content)
>>   max = col-count * col-width
>
> Again, don't forget the gaps.
>
>>   Implemented by: Firefox, IE
>>
>>   Rationale:
>>     The layout as the container gets narrower (fewer columns)
>>     approaches the col-width only case (reduce columns as
>>     width reduces in order to keep each column >= col-width),
>>     so it makes sense to have the same behavior.
>>
>>     The multi-column spec wanted column-width * column-count,
>>     when both were defined, to be the preferred width, and
>>     the implementations reflect this. Authors would probably
>>     prefer that shrink-to-fit sizing landed on this answer
>>     for maxed-out cases as well.

Looks fine, but additionally we should make sure that max >= min.

>> col-width + height
>>   min = used col-count == 1 ?
>>           min-content : column-width * used column count
>>   max = column-width * used column count
>>   Implemented by: Nobody
>
> I think you'd need to lay out to find the column count here. Sounds bad.
>
> And did you mean "actual column count" (not "used column count", BTW)?
> See http://dev.w3.org/csswg/css-multicol-1/#pseudo-algorithm
>
>>   Rationale:
>>     Any other answer results in overflow, which no intrinsic
>>     size should ever result in.
>>
>>     Also this case hits a number of real-world use cases,
>>     and they would like the max-content size to be as described.
>>
>> Notes:
>>   The original "definition" (goal, really) of max-content
>>   was the narrowest size that resulted in the shortest
>>   possible height. However, because of the desire of multicol
>>   elements to have their column-width respected, it's kindof
>>   less obvious what the max-content size ought to be.
>>
>>   Chrome factors in the intrinsic size of the contents in a
>>   few more cases, e.g. using that as a minimum for the column
>>   widths. But since multi-column layout doesn't actually work
>>   that way, this isn't a valid approach. (Once the intrinsic
>>   size is greater than 2*column-width, the used column width
>>   *will* be less than the intrinsic size of the content.)
>>
>>   (We could add the intrinsic size keywords to column-width if
>>   we want the ability to ensure they are wide enough for their
>>   contents. Right now said contents are required to be clipped.)

-- 
---- Morten Stenshorne, developer, Opera Software ASA ----
------------------ http://www.opera.com/ -----------------

Received on Monday, 13 April 2015 10:50:52 UTC