From 23b0235af2915e4aac13f9bdda6ebaf24c22e349 Mon Sep 17 00:00:00 2001 From: fantasai Date: Fri, 3 Dec 2021 17:12:54 -0500 Subject: [PATCH] [css-contain-3] Simplify notes about inline-size containment. #6426 --- css-contain-3/Overview.bs | 95 ++++++++++++++++----------------------- 1 file changed, 38 insertions(+), 57 deletions(-) diff --git a/css-contain-3/Overview.bs b/css-contain-3/Overview.bs index a1863afd0ee..f8f3837ca83 100644 --- a/css-contain-3/Overview.bs +++ b/css-contain-3/Overview.bs @@ -108,63 +108,45 @@ Inline-Size Containment and the box is allowed to [=fragmentation|fragment=] normally in the [=block axis=].
- In some cases, - changes in the [=block size=] can impact layout in the parent formatting context, - which then impacts the [=inline axis|inline=] [=available space=] - (e.g. by triggering scrollbars on an ancestor element) - or the result of [=container size queries=], - which then impacts the element’s [=inline size=], - creating a dependency of this [=inline size=] on the element’s content. - - This sort of "cycle" is not new; - it is possible to construct examples of this - using elements with aspect ratios, - or complex usages of floats and clearing. - In general, the relationship between an element's available inline space - and it's resulting block size + Note: In some cases, + a box’s [=block-axis=] [=intrinsic sizes=] + can impact layout in the parent [=formatting context=] + in ways that affect the box’s [=inline size=] + (e.g. by triggering scrollbars on an ancestor element), + creating a dependency of the box’s [=inline size=] on its own content. + If this changed [=inline size=] results in a different [=block size=], + that new [=block size=] can loop into further impacting the parent formatting context, + but not in a way that reverts it to the previously-problematic layout. + + For example, if scrollbars were introduced, + they are not then removed, + even if the consequent [=block size=] is small enough to not need them; + or if a box’s logical height collides with a lower-placed float and is cleared down + to where it also has more available inline space + and thus becomes short enough to not have collided, + it is not them moved back up to its previous problematic size and position. + + Thus, although [=inline-size containment=] prevents + the box’s content from directly affecting its [=inline size=] + through its [=inline-axis=] [=intrinsic sizes=], + its [=inline size=] can still indirectly depend on its contents + by their effect on its [=block size=]. +
+ + ISSUE: + In general, the relationship between an element's inline size + and it's block size is unpredictable and non-monotonic, - with the block size capable of bouncing up and down arbitrarily - as the available inline space is changed. - - Implementations today prevent infinite cycling - by ensuring that layout always "moves forward"; - in other words, - that certain aspects of a container's layout - do not "revert" to a previous (known-problematic) state, - even if a naive analysis of the constraints would allow for such. - The mitigation for these issues - is that certain aspects of layout - are on a "ratchet", - allowed to progress in one direction but not another: - the available size a container presents to its contents is one such example, - allowed to shrink - (as a result of scrollbars, etc) - but not to then reverse and grow again; - the presence of scrollbars themselves is another, - allowed to be added to an element - but not to then be removed - if the reduced inline available size - causes the contents to no longer overflow; - the "starting point" for elements to be laid out - along the block axis is another, - allowed to move downward as a result of floats - but not to then move back upward - and possibly cause already laid-out floats - to have to move again. - - These algorithm ratchets are well-known and common among implementations, - and container queries - (and the associated [=inline-size containment=]) - do not introduce any conceptually new problems here. - To the best of the specification editors' knowledge, - existing layout techniques suffice to ensure that layout cycles do not occur, - and the design of this feature - attempts to make them rare in practice in any case. - - The precise details of each implementation's mitigation strategies - are not fully interoperable, - unfortunately, - so we hope to capture them in a future specification. + with the block size capable of shifting up and down arbitrarily + as the inline size is changed. + Infinite cycles are prevented + by ensuring that layout does not revert to a previous (known-problematic) state, + even if a naive analysis of the constraints would allow for such; + in other words, layout always “moves forward”. + We believe that current CSS layout specifications incorporate such rules, + but to the extent that they don't, + please inform the CSSWG + so that these errors can be corrected.
For example, @@ -232,7 +214,6 @@ Inline-Size Containment would be positioned at the top of the container, between the first two floats.
- However, giving an element [=inline-size containment=] has no effect if any of the following are true: