- From: Ian Kilpatrick via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Oct 2019 16:49:35 +0000
- To: public-css-archive@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