Re: [css3-multicol] Intrinsic Widths of Multi-column elements (Take I)

On 05/18/2011 03:04 PM, Alex Mogilevsky wrote:
> On the topic of today's discussion, here is how it is currently handled in IE10:

Note that there are multiple concepts of intrinsic width, that
come together into the shrink-wrap algorithm.

min-intrinsic -- the smallest that the element's content can take. This
   plays into table layout, for example a table cell will not ever be
   narrower than the min-intrinsic width of its contents.

max-intrinsic -- the largest width that the element's content can take.
   This is the size that the table cell will take if it is given an
   infinitely-wide containing block.

fit-content (shrinkwrap) -- equal to
   max(min-content, min(max-content, containing-block))

On 05/18/2011 10:36 AM, Peter Salas wrote:
>
> Column-count: auto, column-width:specified: produce a single column
> with the specified column width.

I assume you're talking about shrinkwrap sizing here.

Are you saying that the column-width gives the width of the multicol
element even when that column-width is wider than the containing block?
Note that for a typical element, the column-width will drop so that it
fits inside the containing block. I personally think this is an important
behavior to preserve.

I assume your explanation means that if the element contains a word that
is longer than the column-width, it will get truncated. Is that correct?

> Column-count: specified, column-width:auto: min-content and max-content
> are computed by setting the used column width to the min-content and
> max-content widths of the content, respectively.
>
> It's natural to want to "fill" columns as needed if column-count is auto,
> the height is constrained, and column-fill is auto, but I think spanning
> elements makes this ambiguous (imagine a spanning element with height:120%
> set -- how many columns do you stop at?  What if the spanning element is
> overflowing just because the MC is too narrow?).  If spanning elements
> didn't exist,  I would think this would be both feasible and desirable.
> However, it's not reasonable to ignore spanning elements in this case
> because now layout is dependent on whether the width was determined
> through STF or not, which seems like a bad thing.

This is a good point. However I'm also confronted by the use case that
authors want to be able to set the width of the multi-col element to
match exactly the number of columns that it will take to fill the element.
If we don't support that in CSS, they will do (and have done) it in
JavaScript, and that's silly. Note this is also much more likely to be a
desired layout situation in mixed writing-mode documents, which we are
about to add to CSS...

So, not that I have a good answer to this atm, but I'd like to find a
solution that doesn't involve dropping the ball here, if we can.

~fantasai

Received on Thursday, 19 May 2011 01:21:55 UTC