- From: Alex Mogilevsky <alexmog@microsoft.com>
- Date: Sat, 22 May 2010 22:37:20 +0000
- To: Håkon Wium Lie <howcome@opera.com>, Bert Bos <bert@w3.org>
- CC: "www-style@w3.org list" <www-style@w3.org>
> -----Original Message----- > From: www-style-request@w3.org [mailto:www-style-request@w3.org] On > Behalf Of Håkon Wium Lie > Sent: Saturday, May 22, 2010 2:38 PM > Bert Bos wrote: > > > > My own proposal for resolving this would be that [..] column-span > > > can only apply to objects within the same block formatting > > context as the > multicol block. That prevents objects inside > > overflow:hidden blocks or > inline-blocks from being considered. > > > > That makes sense. The columns that 'column-span' refers to are those of > > the root of the current block formatting context. (If that root is not > a multi- > column element, then there are no columns to span > and 'column-span' has > no effect.) > > Agree. This looks like a simplification on the first glance but I have a couple of problems with it: 1) This will be the first time "nearest block formatting context parent" is used for anything. It will probably affect the definition of containing block, which is already complex. 2) It is not necessarily a simplification. Column layout already has to handle forced column and page breaks which can occur anywhere. The same code can easily handle column-span: * break * balance columns * insert column-span * continue after coumn-span as if on next page It seems pretty straightforward this way... and it seems if we can avoid a new kind of containing block definition, we should.
Received on Saturday, 22 May 2010 22:37:58 UTC