Re: [css3-multicol] Section 8.1: Overflow inside of multicol elements and positioning

On Friday 2013-08-16 10:30 -0500, Scott Johnson wrote:
> I have a couple of questions about the specification for css3-multicol.
> The specification states the following, in section 8.1
> (http://dev.w3.org/csswg/css-multicol/#overflow-inside-multicol-elements):
> 
> "Floated or in-flow content that extends into column gaps (e.g., long
> words or images) is clipped in the middle of the column gap."
> 
> However, when we have an unbreakable item, e.g. an image, that extends
> vertically outside of the column block such that the unbreakable content
> is larger than the column box, how should we treat this? Webkit splits
> the image between two columns. I believe this is considered a bug,
> though: https://bugs.webkit.org/show_bug.cgi?id=25633 Presto (v12.16),
> on the other hand, allows the unbreakable content to extend vertically
> outside of the column box. The column box is the height that would be
> expected, based on the column rule in the following test case:
> 
> http://people.mozilla.org/~sjohnson/junkyard/b700367/vertical-clip.html
> 
> I would have expected that Opera would have pushed all the breakable
> content (the text after the image) into the next column, rather than
> leaving some text in the first column.
> 
> My first question is: What is the desired behavior in this situation? We
> should probably adjust the spec to account for this type of situation.

So the thread so far has focused on the splitting behavior.  But the
key question about the spec text Scott quoted isn't the splitting
behavior, it's the clipping behavior.  Does the above quoted
sentence imply that any vertical clipping happens, or not?

(Interpreted literally, it doesn't, but it's not clear to me that
that's what was intended; it's a very loosely formulated sentence
that doesn't describe its intent or mechanism very carefully.  And
it's unusual to have spec define clipping to a region that has
horizontal edges but is infinite in vertical extent.  It is
implementable in Gecko, but I don't think it's a concept we've
implemented before.)

> In the same section, the spec doesn't explicitly define what should
> happen with absolutely-positioned, relatively-positioned, or transformed
> content. So, in the following situations:
> 
> http://people.mozilla.org/~sjohnson/junkyard/b700367/columnbox-clip-relpos.html
> http://people.mozilla.org/~sjohnson/junkyard/b700367/columnbox-clip-abspos.html
> http://people.mozilla.org/~sjohnson/junkyard/b700367/columnbox-clip-transform.html
> http://people.mozilla.org/~sjohnson/junkyard/b700367/columnbox-clip-fixed.html
> 
> Presto, in the relatively-positioned case, clips the image content to
> the column box (plus a width of 1/2 of the column gap), such that the
> clipping is based off of the final position of the image. This is what I
> would expect, but we should probably define in the spec what the
> behavior should be.
> 
> In the absolutely positioned case and the transform case, should we be
> clipping the image/content based on the original position of the
> content, or the new position after the absolute positioning/transform is
> applied?
> 
> Presto, in the case of absolute/fixed positioning, doesn't apply
> clipping to the column box boundaries. I think this is probably correct,
> but again, I feel that the specification should probably talk about this
> case.
>  
> Finally, Presto, in the case of the transform, handles the situation as
> it does in the relatively positioned case. Again, I think this is what
> we want, but we should probably indicate the desired behavior in the spec.
> 
> Given all of this, I would recommend the following text in section 8.1:
> 
> "Floated or in-flow content that extends into column gaps (e.g., long
> words or images) is clipped in the middle of the column gap."
> 
> be replaced with the following text:
> 
> "Content within a multicolumn element that extends into column gaps
> (e.g., long words or images) which is not absolutely or fixed positioned
> should be clipped in the middle of the column gap such that the content
> displayed is that which lies within the rectangle that is the
> intersection of the column box with width extending 1/2 of the way into
> the column gap on either side of the column box, and the rectangle
> representing the content's bounds after the positioning is applied."

I think the definition needs to be described in a way that aligns
well with the definition of painting order in Appendix E of CSS 2.1.

For example, this definition implies that an extra wide relatively
positioned element (even with z-index) is clipped, but absolutely
positioned descendants of that rel-pos element are *not* clipped
(even though this rel-pos element is their containing block, and if
it has z-index, also their stacking context).  Implementing that
correctly requires a huge amount of implementation complexity, for
no value that I can see.

I think this spec text needs to be re-thought more carefully.  We
should go back to the use cases for this clipping, decide what's
important, and then define a behavior that can be implemented
efficiently and simply to meet those use cases.  If it's *really*
necessary to define that only *some* content should be clipped, I
think that content should be defined in terms of the painting layers
described in Appendix E.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)