Intent to Deprecate & Remove: Position and size New Formatting Contexts like floats when shapes are present.
Ian Kilpatrick
Primary eng (and PM) emails
Summary
shape-outside allows web developers to wrap text around a floats with a non-rectangular area. In our implementation this also currently affects how new formatting contexts (FCs) are sized and positioned.
In short... as the “float area” (defined by shape-outside) affects the inline-size of the FC, which affects the block-size, and the block-size of the FC determines where it’ll be positioned, which affects what its inline-size might be. (There is a circular dependency). In order to implement this sub-feature correctly you need to iterate over all the potential places in the document where the FC could be placed.
(This is expensive).
Our current implementation currently relies on hysteresis - that is, it re-uses state from the previous layout. This, while fast, means that for the same CSS+HTML input, you can get multiple different layout outputs. (See this video, demo link).
This is also inconsistent with how floats are positioned. By the specification they aren’t affected by the shape-outside property. (“float positioning and stacking are not affected by defining a float area with a shape”). The proposed change is to size and place FCs as if the shape-outside property wasn’t applied (similar to floats).
Motivation
The feature is buggy in our implementation (see video above). There hasn’t been a clear efficient algorithm for implementing this feature proposed which is required to make this fast and non-buggy.
We can’t see an easy way to implement the current behaviour in a fast/non-buggy way based on our current or future layout engines.
It isn’t clear that the specification ever intended for this to be the behaviour. The specification has no examples for the behaviour of new formatting contexts, and only ever shows/describes behaviour with line-boxes.
Interoperability and Compatibility Risk
We think this has low interop and compat risk, due to the low usage (see use-counters below).
Edge: Not supported.
Firefox: Not supported.
Safari: Supported.
I filed: https://github.com/w3c/csswg-drafts/issues/1970 on the CSSWG for the spec to clarify its intention here.
The tests added when this part of the feature was initially implemented, didn’t actually test this behaviour at all. I plan on adding a WPT test with our behaviour.
Firefox are currently implementing shape-outside and I communicated via. email a few months back that they probably shouldn’t implement this.
Alternative implementation suggestion for web developers
None.
Usage information from UseCounter
We added two use-counters for this case:
https://www.chromestatus.com/metrics/feature/timeline/popularity/2205
https://www.chromestatus.com/metrics/feature/timeline/popularity/2206
The use-counters above show how many times our alternative method for sizing and positioning these would have been triggered. As both these use-counters are sufficiently low, we feel like the breakages caused will be minimal. (This may be desirable for web developers as the page layout stability will be increased).
Entry on the feature dashboard
https://www.chromestatus.com/feature/5226946044624896
Rick Byers
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpS7TFe%2BAKeHVkeJpigGk%2BrG2eeJehsdV6LMhcmTEs0hxg%40mail.gmail.com.
Ian Kilpatrick
Simplifying the design seems clearly better than trying to "correctly" support crazy complexity like this that nobody is actually depending on in practice. Thank you for pushing in this direction!Ideally we'd supply a spec PR before landing this change, but given that there's been no response to the spec bug you filed in November I wonder how likely a spec PR would be to get review (certainly don't want you wasting your time on a PR that's unlikely to land). Thoughts?
LGTM1 with the addition of a web-platform-test somewhere. Since our behavior will violate the spec, you might want to write a test that conforms to the spec but shows that no implementation matches (I assume WebKit has the same hysteresis, which I presume I test could detect). Alternately (or in addition) you might want to land a tentative test which all the non-WevKit engines would presumably pass.
Ojan Vafai
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpQERzYXKYoV4moZLr75%2BueOqhHPZ-DsDsHyfd0qk1FSOQ%40mail.gmail.com.
Chris Harrelson
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMdWTtO4i3B3CbPXmjKgRb_sD30zu-m20K%2BFDi3jubz2qHovw%40mail.gmail.com.