W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2019

Re: [csswg-drafts] [css-shapes] Allow new formatting contexts to be sized based on *bounding* float-area. (#1970)

From: Ting-Yu Lin via GitHub <sysbot+gh@w3.org>
Date: Sat, 02 Nov 2019 06:34:13 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-549015994-1572676452-sysbot+gh@w3.org>
> Firefox fails this relatively simple testcase:
> https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=7328
> Here _I believe_ Firefox assumes that an element will always shrink in block-size as its inline-size grows, which isn't always the case as show by the testcase. To do this properly you can't assume that a height of a given element will larger or smaller given a different inline-size.

This is an interesting test. The `flex` container's block-size depends on its inline-size because the `<img>` uses percentage width. So if `flex`'s inline-size shrink, both `<img>`'s inline-size and block-size become smaller, resulting in a smaller block-size for `flex`.

What Firefox does to layout this test case is: before the `flex` container's block-size is known, it uses the full 200px inline space provided by `test` to calculate `flex`'s dimension. Once `flex`'s block-size is known,  it realizes it will overlap the float, so it will find the first available inline coordinate which has large enough block space to fit `flex`, and calculate `flex`'s dimension again. But this time, as the inline-space shrink, both `flex`'s inline-size and block-size shrink as well. The block space at the given inline coordinate is now too *big*, but Firefox is happy about it because `flex` already fits.

I think if either of the `flex` container or `<img>` has a fixed dimension like `width: 100px`, Firefox can layout this test without any issue. 

GitHub Notification of comment by aethanyc
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1970#issuecomment-549015994 using your GitHub account
Received on Saturday, 2 November 2019 06:34:15 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:56 UTC