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

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:
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 using your GitHub account

Received on Wednesday, 30 October 2019 16:49:37 UTC