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

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

From: Ian Kilpatrick via GitHub <sysbot+gh@w3.org>
Date: Wed, 30 Oct 2019 16:49:35 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-548004199-1572454174-sysbot+gh@w3.org>
The issue here is that the solution to #2452 is far more computationally complex here. Typically there aren't that many floats on the page which limits the computational complexity of the previous resolution.

Implementations today current "cheat" in different ways, leading to different implementation bugs and iterop issues:

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.

I haven't tested Safari recently, but if it had the same issues with the previous Blink implementation, it probably uses hysteresis (using data from a previous layout, for the next layout) which got things mostly correct, but was unstable.

Essentially to get this perfect you need to perform layout at almost every available inline-size.
We (blink) prioritize users and want to avoid a computational explosion like this :).

Further - we haven't seen demand from web developers for this type of usecase. We have usecounters in place that which show that css-shapes are very popular! But nobody was depending on sizing a BFC in this way. Further since we removed this feature, we haven't received any bug reports etc.

-- 
GitHub Notification of comment by bfgeek
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1970#issuecomment-548004199 using your GitHub account
Received on Wednesday, 30 October 2019 16:49:37 UTC

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