- From: David Hyatt <hyatt@apple.com>
- Date: Sat, 22 May 2010 23:06:39 -0500
- To: Alex Mogilevsky <alexmog@microsoft.com>
- Cc: Håkon Wium Lie <howcome@opera.com>, Bert Bos <bert@w3.org>, "www-style@w3.org list" <www-style@w3.org>
On May 22, 2010, at 5:37 PM, Alex Mogilevsky wrote: >> -----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. I don't think it alters any existing definitions. This can all be described using existing terminology. > 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: I disagree that column and page breaks can actually occur anywhere. What does it mean for some content inside a table cell to say that it wants to break a column? Do we really expect that to work? I sure don't. Can content inside a float really break a column? I don't expect that to work either. I don't think how forced page breaks work has ever been specified in detail, but it definitely isn't the case that implementations honor them just anywhere. I think we're better off with restrictions, especially at first. We can always broaden allowed behavior later. dave (hyatt@apple.com)
Received on Sunday, 23 May 2010 04:07:16 UTC