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

This section of the spec was rewritten as a result of this thread:
http://lists.w3.org/Archives/Public/www-style/2013Apr/0639.html

It's maybe worth revisiting.




± -----Message d'origine-----
± De : L. David Baron [mailto:dbaron@dbaron.org]
± Envoyé : mardi 20 août 2013 18:18
± À : www-style@w3.org
± Cc : Scott Johnson
± Objet : 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.htm
± > l
± >
± > 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-re
± > lpos.html
± > http://people.mozilla.org/~sjohnson/junkyard/b700367/columnbox-clip-
± ab
± > spos.html
± > http://people.mozilla.org/~sjohnson/junkyard/b700367/columnbox-clip-tr
± > ansform.html
± > http://people.mozilla.org/~sjohnson/junkyard/b700367/columnbox-clip-fi
± > xed.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)

Received on Wednesday, 21 August 2013 01:44:00 UTC