- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 12 Oct 2010 12:40:25 -0700
- To: shelby@coolpage.com
- Cc: David Storey <dstorey@opera.com>, www-style@w3.org
On Tue, Oct 12, 2010 at 11:25 AM, Shelby Moore <shelby@coolpage.com> wrote: > Tab Atkins wrote: >> If >> the height is constrained, then overflow always results in generating >> new columns in the "after" direction. From the spec, section 8.2: "A >> declaration that constrains the column height (e.g., using ?height?) >> must be honored, if possible. ... In continuous media, columns that do >> not fit within the multicol element are added in the inline >> direction." > > > But the spec is apparently ambiguous as to what to do when the _BOTH_ the > height and width are constrained. > > As per my tests in all browsers (IE6, FF3.5.x, FF3.6.0, latest Chrome), > when column-width, width, and height are all set, then the overflow:auto > flows out the bottom, i.e. no extra columns are created. I'm not sure how you're seeing that result. On both FF and Chrome on my Linux and Windows machines, the following style: div { -moz-column-width: 50px; -webkit-column-width: 50px; width: 200px; height: 100px; border: 1px solid black; -moz-column-rule: 1px solid black; -webkit-column-rule: 1px solid black; } ...results in many 50px-wide columns being created and placed to the right. Switching that to column-count:3 gives a similar rendering. Specifying both -width and -count together give me the same rendering as one or the other (Chrome and FF differ on which they feel like honoring, which means a bug in at least one of them). The only way I can get columns to grow vertically is to keep height:auto. > But alas, without any pagination, so thus is not ideal. Given that the > spec is ambiguous on the case of simultaneous height and width constraint, > I suppose we are free to specify now what should be done? Normally we > would adopt what all the browsers are already doing? Thus we would have to > add a non-default setting for column-overflow:paginate? But that is a > shame, as I think the default should be to paginate. It's not ambiguous. It's defined. >> This is the >> situation you're running into. > > No my situation is to constrain both the height and the width. Ah, that wasn't clear to me. You were describing a situation where you had a set number of columns that were growing too tall, which afaict is only achievable if the height of the multicol element is unconstrained. >> will indeed >> require a new mode-switch, something like "column-overflow: inline | >> block" to specify where overflow columns get created. > > Okay, so if block is in the same direction as column rows, then it means > there must be pagination, because maximum column height has to be > respected from section 8.2: "A declaration that constrains the column > height"? > > So thus block is equivalent result in to my suggestion > column-overflow:paginate? (I like it, more orthogonal then my paginate > suggestion) Yes, roughly. It would make the columns be equal to the block's height, with more sets of columns placed below. It's then up to the overflow method to decide how to display that. ~TJ
Received on Tuesday, 12 October 2010 19:41:18 UTC