- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 18 May 2011 18:21:19 -0700
- To: www-style@w3.org
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