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

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

From: Morten Stenshorne <mstensho@opera.com>
Date: Fri, 16 Aug 2013 22:11:39 +0200
To: www-style@gtalbot.org
Cc: "Scott Johnson" <sjohnson@mozilla.com>, "www-style\@w3.org" <www-style@w3.org>
Message-ID: <871u5tqttw.fsf@aeneas.oslo.osa>
"Gérard Talbot" <www-style@gtalbot.org> writes:

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

That's orphans and widows at work (although it sure looks stupid in this
case). Set them both to 1 to "fix" this.

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

I'm not sure. The Presto behavior (don't break unbreakable content; just
overflow at the bottom of the column) is nice if overflow is actually
visible, which is the case for regular multicol, but not so nice if
overflow is hidden and unreachable, e.g. for paged media or
overflow:paged.

While it may be ugly to brutally slice unbreakable content, at least
what WebKit does can be done consistently for all kinds of fragmented
content, regardless of it being multicol, paged media or regions, since
it guarantees that everything will be visible and reachable somehow.

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

<div style="position:relative; columns:3;">
  <img style="position:absolute; width:1000%;" src="...">

?

I think the abspos should be clipped at column boundaries then, since
the multicol is the containing block. This is similar to how an abspos
behaves inside a relpos container with non-visible overflow (it gets
clipped and/or scrolled).

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

-- 
---- Morten Stenshorne, developer, Opera Software ASA ----
------------------ http://www.opera.com/ -----------------
Received on Friday, 16 August 2013 20:11:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:33 UTC