Re: [css3-multicol] overflow inside multicol elements

On Mar 4, 2013, at 12:51 PM, Alan Stearns <stearns@adobe.com> wrote:

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

Ignoring the issue of transforms for a moment, special casing vertical offsets only for relative positioning makes little sense to me. In all of the following cases, contents actually move backwards inside the column flow:

(1) Negative margins can push a block into a previous column/region.
(2) An absolute positioned object inside a relative positioned object with no translation. The absolute positioned object can and does move backwards in the flow.

In general, vertical offsets that move content forwards or backwards do so inside the column flow. Objects that spill out of a 0-height block don't suddenly escape the column just because they overflowed the block. They fragment into the next flow.

We are basically saying that relative positioning is somehow different and should behave in a way that is inconsistent with all other offsets. Maybe the argument is that relative positioning isn't "layout overflow", but of course it is. Browsers make relative positioned and transformed content reachable via scrollbars.

With this model you're basically saying that the only reason printing works is that the pages happened to be joined vertically with a gap of 0 between the pages, and you're just "getting lucky" that this layout overflow happened to show up on the previous page and not get lost. That's a stupid model IMO, since it obviously breaks the minute you decide that the pages are being placed horizontally instead of vertically.

I see no reason why vertical offsets just for relative positioning should be applied outside of the columns when all other vertical offsets (e.g., margins, fragmented absolute positioning, etc.) are applied inside the columns. This is just inconsistent.

Transforms are a trickier case, since you do have to decide if the transform applies per-box or not, so I can see how that might require more thought.

Basically I would ask that we not have two completely different overflow models here and that we not make the default model one where printing happens to just "get lucky"  because of vertical connection of pages.

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

It doesn't matter whether it's multicolumn or not. paged-x still means you're fragmenting content in the inline direction. Regardless of whether or not you call it multi-column, the same problem exists.
> 
>> 
>> 
>> (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.

What if the horizontal paginated layout fills the viewport? In the case of overflow:paged-x that will certainly typically be the case. What if you set overflow:hidden on the multi-column block? i don't see why we should endorse a model where page content gets "lost" just because we arbitrarily decided that relative-positioned offsets shouldn't be in-flow when all other offsets are. 

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

I see no reason to distinguish between page boxes and other boxes here. Perhaps the distinction should be between clipped boxes and unclipped boxes, with the UA treating the offsets as in-flow when the boxes are clipped to avoid content being lost. Still, I don't really see any reason why we should be inconsistent with relative positioning here compared to other vertical offsets.

dave
(hyatt@apple.com)

Received on Monday, 4 March 2013 19:47:35 UTC