NEW 249100
PROGRESSION(STP159) [WPT] css/CSS2/floats/floats-zero-height-wrap-002.xht
https://bugs.webkit.org/show_bug.cgi?id=249100
Summary PROGRESSION(STP159) [WPT] css/CSS2/floats/floats-zero-height-wrap-002.xht
zalan
Reported 2022-12-11 11:11:06 PST
ssia
Attachments
rendering in firefox, chrome, safari (96.18 KB, image/png)
2022-12-11 15:21 PST, Karl Dubost
no flags
Radar WebKit Bug Importer
Comment 1 2022-12-11 11:11:26 PST
zalan
Comment 2 2022-12-11 11:16:50 PST
regressed at 256530@main, it looks like empty floats with "clean" act non-empty. need to check the relevant spec.
Karl Dubost
Comment 3 2022-12-11 15:21:02 PST
Created attachment 463994 [details] rendering in firefox, chrome, safari safari, firefox have the same behavior chrome is different The original bug at Mozilla for this test http://wpt.live/css/CSS2/floats/floats-zero-height-wrap-002.xht https://bugzilla.mozilla.org/show_bug.cgi?id=81710 In 9.4.2 Inline formatting contexts https://www.w3.org/TR/CSS22/visuren.html#inline-formatting > Line boxes are created as needed to hold inline-level content within an inline formatting context. Line boxes that contain no text, no preserved white space, no inline elements with non-zero margins, padding, or borders, and no other in-flow content (such as images, inline blocks or inline tables), and do not end with a preserved newline must be treated as zero-height line boxes for the purposes of determining the positions of any elements inside of them, and must be treated as not existing for any other purpose. and in https://www.w3.org/TR/CSS22/visuren.html#floats 9.5 Floats > A line box is next to a float when there exists a vertical position that satisfies all of these four conditions: (a) at or below the top of the line box, (b) at or above the bottom of the line box, (c) below the top margin edge of the float, and (d) above the bottom margin edge of the float. > > Note: this means that floats with zero outer height or negative outer height do not shorten line boxes. The "and must be treated as not existing for any other purpose." seems to say that it should be ignored and not contribute to anything. I also wondered what it means to rotate such a box for the layout.
zalan
Comment 4 2022-12-11 17:25:43 PST
The gecko report seems to be about non-zero width, but zero height floats in general. It looks like Blink, Gecko and WebKit are all agree on their contribution to layout when "clear" is set to "none". The consensus is that zero height floats don't take up space (and they don't shrink the line box when IFC is involved). However when "clear" is not "none", zero height floats start taking up space and push other float avoiders around. I find it puzzling that "clear" triggers such behavior change.
zalan
Comment 5 2023-01-17 20:05:43 PST
let's start with a simple example: <style> .float_box { float: left; width: 50px; height: 10px; } .first { background-color: green; } .second { float: left; background-color: red; } </style> <div class=container> <div class="float_box first"></div> <div class="float_box second"></div> <div class="inline_content">inline content with intrusive float</div> <div> this produces the following rendering: _____ _____ |green|| red | inline content with intrusive float ----- ----- let's collapse _second_ float by setting "height: 0px" (and also make it wider, let's say 200px) as per CSS spec (https://www.w3.org/TR/CSS2/visuren.html#floats) " ... Note: this means that floats with zero outer height or negative outer height do not shorten line boxes. ... " .second { float: left; height: 0px; width: 200px; background-color: red; } it should produce a collapsed red float box and we should not shrink the available horizontal space and should not "indent" the line box. _____ |green|[]inline content with intrusive float ----- ^ zero height second float is here ([] <- means no horizontal space taken) now force the second float below the first one by setting "clear: left" on the _second_ float .second { float: left; height: 0px; width: 200px; clear: left; background-color: red; } since the second float is still collapsed (zero height) this should render the same as before _____ |green|inline content with intrusive float ----- [] ^ collapsed and cleared float comes here. does not affect line box. and this is where Safari's previous behavior is different than current trunk behavior where _____ |green| inline content with intrusive float ----- [ ] the inline content is indented by 200px. After a bit of debugging I noticed that the reason why "clear" changes behavior is simply because it pushes the float downward making it not sit at the top of the content box anymore and "force overlap" the inline_content box (vertically) (i.e inline_content box starts at 0px and ends at 20px and float box with clear starts (and ends) at 10px (vs 0px before clear)). So "clear" may not be required if we could push down the float and still overlap it with "inline_content" (vertically) something like this: .container { padding: 1px; } (push down the float -and all other boxes) .inline_content { margin-top: -1px; } (and pull up the block container with inline content) This ensures that the float box "overlaps" the inline_content block container (vertically) just like when it had "clear". so now we've got no "exotic" clear, just a simple float with 0px height <style> .container { padding-top: 1px; } .float_box { float: left; width: 50px; height: 10px; } .first { background-color: green; } .second { float: left; height: 0px; width: 200px; background-color: red; } .inline_content { margin-top: -1px; } </style> <div class=container> <div class="float_box first"></div> <div class="float_box second"></div> <div class="inline_content">inline content with intrusive float</div> <div> since the second float's height is 0px, it should not indent the line box (as we've seen it before ^^^) should renderer this: _____ |green|[]inline content with intrusive float ----- ^ zero height float and yet shipping Safari renders it like this: _____ |green|[ ]inline content with intrusive float ----- ^^ no red is shown (height: 0px;) but it indents the line box. and if I make the same set of changes to the original test case (clear is removed on 0px tall float, container gets padding-top: 1px, inline content gets margin-top: -1px) <div style="padding-top: 1px; width: 500px; height: 500px; float: left; font-size: 12px;"> <div style="float: left; width: 10px; height: 30px; background-color: black;"></div> <div style="float: left; width: 100px; height: 0; background-color: brown;"></div> <div style="margin-top: -1px"> <span style="display:inline-block; vertical-align: bottom; height: 20px; width: 300px; background: blue;"></span> <span style="display:inline-block; vertical-align: bottom; height: 20px; width: 300px; background: purple;"></span> <span style="display:inline-block; vertical-align: bottom; height: 20px; width: 300px; background: fuchsia"></span> </div> </div> suddenly the 0px tall float indents the first inline-block I think this test case has incorrect expectation.
Note You need to log in before you can comment on or make changes to this bug.