Re: [css3-multicol] overflow inside multicol elements

On 3/4/13 8:30 AM, "David Hyatt" <hyatt@apple.com> wrote:

>On Mar 4, 2013, at 8:18 AM, James Holderness <j4_james@hotmail.com> wrote:
>
>> 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.

While no two browsers render that pen in exactly the same way,
Firefox/Opera/IE do position the boxes the way James expected.
WebKit-based browsers are the odd men out, here. The last time the working
group talked about this, it was decided that for on-screen fragmentation,
transforms and relative positioning occur after fragmentation, so they
should be relative to the fragment container.

> 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.

I don't think multicolumn should be used to fake on-screen pagination.
That's a hack we should replace with actual paginated views. You mentioned
on IRC that you currently use multicol for 2-up pagination - that's a
requirement that should be added to the paged-x and paged-y discussion.

> 
>
>(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.

I agree that pagination should be consistent, but I don't understand the
horizontal/vertical distinction you're making here. I don't think that
pagination necessarily needs to be consistent with columns and regions. If
you have a paginated view or are printing, slicing content across the page
break makes sense, as there's no where else to put it. Without slicing,
you can lose content. But for columns and regions, they can be nestled in
a larger design that can accommodate some 'painting outside the lines'
and/or scrolling could reach content.
>
>> 
>> 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."

That sentence is meant to distinguish page boxes from other fragment
containers. For fragment containers that are not page boxes, you are
supposed to fragment first, then transform or relatively position content.

Thanks,

Alan

Received on Monday, 4 March 2013 18:52:14 UTC