- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 11 Apr 2011 14:34:52 -0700
- To: "www-style@w3.org" <www-style@w3.org>
I've been thinking about multi-col shrinkwrap wwidths a lot due to the interesting situations we get into with vertical-horizontal mixed text. I think it's not very well defined in the multicol spec right now, and I'd like us to do better and solve some more use cases, both for vertical text and for other things (some situations Tab's coworkers were struggling with come to mind). I also think we need to explicitly specify the min-content and max-content widths, not just the fit-content (shrinkwrap) width, since they are used independently in many layout calculations (e.g. tables) as well as selectable via keywords on 'width' and 'height' in CSS3. [1] [1] http://dbaron.org/log/20080613-firefox3-css#new-width-values http://lists.w3.org/Archives/Public/www-style/2007Nov/0119.html http://lists.w3.org/Archives/Member/w3c-css-wg/2007OctDec/0267.html I'll start by showing a couple examples of problems with the current definition, to demonstrate that there's a problem we should fix. :) Problems with the current definition of multi-col fit-content ============================================================= The current definition of multi-col's fit-content width is to use the fit-content width of the contents as the available width. This results in some funny behavior. Example 1: |<-------------------width of containing block------------------->| |This is a long but not too long sentence. | The fit-content width here (as for floats, etc.) is |<--------shrinkwrap width--------------->| | If I set column-count: 2; column-gap: 2em; (represented by ##), I get this: |This is a long but ## sentence. | | |not too long ## | | Unless you're thinking about CSS layout algorithms, the result makes no sense. It's based on a hypothetical calculation that has no basis in any measurements used in the resulting layout. Logically, I would expect maybe this: |This is a long but not ## too long sentence.| | or this (which is easier to calculate) |This is a long but not too long ## sentence. | I'm not actually sure of the best way to define the layout here, because I don't understand the use case for setting column-count and asking for shrink wrap. But I think the result we get right now is definitely weird. Example 2: Let's say I have a fixed height and a set column-width: height: 3em; column-width: 22ch; column-gap: 2em; I have enough content to fill 2 columns. It would be nice if the multicol element were sized to fit my two columns, like this: | This is some content ## narrow columns like | | | ... ## this. | | | that fits into two ## | | But in fact, because the shrinkwrap width of the content is equal to the available width, I get this: | This is some content that would ## leave some room to spare, but| | fit into two narrow columns and ## now we fill the block. | So I think we could use a slightly more sophisticated algorithm here. Proposed Definition of Multicol Intrinsic Widths ================================================ There are three concepts of "intrinsic width" in CSS: the min-content width, which takes all possible line breaks; the max-content width, which takes no unforced line breaks; the fit-content width, which is defined as max(min-content,min(max-content, available)) As the available width approaches infinity, the max-content and fit-content widths become equivalent. (Max-content has sometimes been explained as shrinkwrapping with infinite available width.) In CSS2, the available width is always defined, even if it is big enough that it is not used in the fit-content calculation. However, this is not so in CSS3; sometimes the available width is infinite, and instead we have an "available height", which is another concept that doesn't appear in CSS2. (This happens when you place a horizontal block inside a vertical block formatting context.) In such cases, some substitute value must be provided to certain layout calculations that need a definite value for the available width. This value, which I will call the /fallback width/, and is currently defined to be the size of the initial containing block. Anyway. Now that we have all that defined up front, here's some proposed definitions, Take I. min-content width: Defined as the min-content width of the contents (same as now). * (Alternatively, define as the width of a multicol element with the column count and column gap as specified and the column-width as the min-content width of the contents.) max-content width: If the used column count is 1, then the max-content width is the minimum of the max-content width of the contents and the used column width. * If the used column count is more than 1, then the max-content width is calculated from the used column width, used column count, and used column gap. ** - If both column-width and column-count are set, these give the used column width and used column count. *** - If only column-width is set, the used column count is found by filling columns of exactly column-width, using any applicable height constraints. - If only column-count is set, the used column width is the maximum of - the min-content width of the contents and - the column width that results in a balanced columns height that most closely fits within any given height constraints, or, - if there are no height constraints, the column width that would be that would be calculated for a normal auto-width block (using the fallback width if the available width is undefined). **** fit-content width: max(min-content,min(max-content, available)) Equivalent to max-content if available width is not defined. Use case notes: * This exception allows shrinkwrapping to the content, which is an important capability, especially for vertical-in-horizontal or horizontal-in-vertical situations. If the author wants a specified column width to be the minimum, he can set min-width to the column width explicitly. This definition makes both reasonable behaviors available. ** When there are multiple columns, they have equal widths even under shrinkwrap. ***This rule allows setting column-width and column-count explicitly and having "width: max-content" make the width depend only on the given column settings. Using "width: fit-content" then does the same thing except it maxes out at the available width, thus also preventing overflow. ****I couldn't think of a good use case for this situation, so I chose a behavior that tries to minimize overflow (content clipping) within the multi-col element and otherwise respects whatever constraints were given. The second condition (which tries to respect height when given) may be hard to implement, though. I'd be interested in what other people expect this situation to result in. ~fantasai
Received on Monday, 11 April 2011 21:35:23 UTC