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

Le Ven 16 août 2013 11:30, Scott Johnson a écrit :
>
> 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

In

http://people.mozilla.org/~sjohnson/junkyard/b700367/columnbox-clip-abspos.html

the containing block of the abs. pos. img is the initial containing block
and not the wrapping div. And so, such entire image (without clipping)
should overlap the multi-col element.

And in case of the containing block of the abs. pos. img was the wrapping div
(eg
http://www.gtalbot.org/BrowserBugsSection/CSS3Multi-Columns/Opera/NewTests/multicol-containing-002.xht
although the image is short, narrow)
, then the image should not be clipped and should overlap the multi-column
element.

Your code (in your 4 columnbox-clip-* tests) could be improved and tweaked
a bit
- with a doctype decl.
- removal of unnecessary code: div.clipwrapper is declared but not used
- without prefix, column-gap is 0 but with vendor-prefix, *-column-gap is 1em
- Opera 12.16 does not require a vendor-prefix; so, o-column-* can be
safely removed



> http://people.mozilla.org/~sjohnson/junkyard/b700367/columnbox-clip-transform.html
> http://people.mozilla.org/~sjohnson/junkyard/b700367/columnbox-clip-fixed.html

I'd say same thing with columnbox-clip-fixed.html: the initial containing
block of the fixed image is the initial containing block.

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

This is also what I would expect to happen in your
columnbox-clip-relpos.html


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

Wrt fixed positioning, the initial containing block will be the containing
block for the image. Wrt abs. pos., you need to set the wrapping div to be
relatively positioned.

For situations where the multi-column element is the containing block of
an abs. pos. element (say, an image), I am convinced that such abs. pos.
img should not be clipped. It should be in front of the rel. pos.
multi-column element and its column boxes.


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

Scott,

I believe I understand your proposed text but ... it would be best to
break it into smaller sentences and/or smaller (main, secondary)
propositions. A 82-word long sentence is not an ideal way to cover
situations.

Gérard

> 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



-- 
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html

Received on Friday, 16 August 2013 16:52:09 UTC