W3C home > Mailing lists > Public > www-style@w3.org > August 2013

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

From: Scott Johnson <sjohnson@mozilla.com>
Date: Fri, 16 Aug 2013 10:30:03 -0500
Message-ID: <520E457B.4050702@mozilla.com>
To: "www-style@w3.org" <www-style@w3.org>

Hello www-style:

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.

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

Further, I am unsure as to whether there are additional cases that we
should specify in the specification text in this section. Any discussion
or comments would be appreciated!

~Scott Johnson
Platform Engineer, Mozilla
Received on Friday, 16 August 2013 15:30:31 UTC

This archive was generated by hypermail 2.3.1 : Friday, 16 August 2013 15:30:31 UTC