Re: [css3-multicol] overflow inside multicol elements

On Mar 4, 2013, at 8:18 AM, James Holderness <j4_james@hotmail.com> wrote:

> I've been looking at the way various browsers handle overflow in a multicol element, and every one of them appears to handle things differently. I'm unsure which, if any, is correct.
> 

You should know that in WebKit, I am working on a brand new multicolumn implementation to replace the old one, so you will undoubtedly find lots of bugs with the old code. ;)

> As a test case, I created a two-column, constrained-height container, with a number of single-line paragraphs of text, which were relatively positioned in different ways so as to overflow the various boundaries of the container.
> 
> You can see the test case here: http://codepen.io/j4_james/pen/DqFbK
> 
> I tested this on Windows builds of the following:
> - Firefox 19
> - Chrome 25.0.1364.97
> - Opera 12.14 (build 1738)
> - IE 10 (via NetRender)
> 
> As far as positioning goes, I would have expected the items simply to be moved in the specified direction, and for most that was the case. On Chrome, however, items were moved within the flow of the columns - so, an item with a negative top property at the top of the second column, would be moved back into the first column rather than up out the top of the multicol container.
> 

This is deliberate behavior in WebKit, and I do not consider it a bug. I strongly believe relative positioning and transforms should happen within the column flow. There are several reasons why I believe this should be the preferred behavior.

(1) Multicolumn layout is often used to paginate other authors' content. As such, you don't want the use of relative positioning or transforms in that content to "break" pagination. If you apply transforms and positioning outside of the column flow, the inevitable result is that you move the content outside of the bounds of the "pages", which will often make it inaccessible. 

(2) The way items paginate shouldn't change just because you did printing vs. overflow paged-x vs. overflow paged-y vs. columns. When the pagination direction happens to be horizontal, that should not imply that relative positioning and transforms suddenly become unsafe to use.

> For elements that overflowed vertically (i.e. out the top or bottom of the multicol container), IE and Firefox both displayed the entire element; Opera displayed all of the text content, but clipped the background, and constrained the outline to the edge of the container; and Chrome clipped any part of the element that was outside the container.
> 

This is a bug in WebKit that is fixed by the new code.

> For elements that overflowed horizontally (i.e. out the left or right of the multicol container), IE, Firefox and Opera displayed the entire element, but on Opera the element wouldn't contribute to the overflow width of the page itself (so if the item was positioned off screen there would be no scroll bar); and Chrome clipped any part of the element that was outside the container.
> 
> For elements that overflowed into the column gap, Firefox displayed the entire element; IE and Opera clipped the element at the middle of the column gap (although Opera constrained the outline rather than clipping it); and Chrome clipped the element at the edge of the column (i.e. before the column gap).
> 

This is a bug in WebKit that is fixed by the new code.

> 
> Chrome seems completely wrong to me, both in its positioning and its clipping. Opera at least got the column gap clipping right I think - not sure how outlines should be effected though.

WebKit's clipping is wrong, but I believe our positioning behavior is not. To do otherwise means routinely placing content outside of columns and breaking pagination. I don't believe saying "paged-x" instead of "paged-y" should result in inaccessible paginated content, and this paragraph in CSS Fragmentation seems to favor WebKit:

http://dev.w3.org/csswg/css3-break/#transforms

"However, the separation and transfer of page boxes should occur last; thus a transformed fragment that spans pages should be sliced at the page breaks and print in its entirety rather than being clipped by its originating page."

dave
(hyatt@apple.com)

Received on Monday, 4 March 2013 16:31:26 UTC