[css-contain-3] Simplify notes about inline-size containment. #6426

css-contain-3/Overview.bs

@@ -108,63 +108,45 @@ Inline-Size Containment</h3>
 	and the box is allowed to [=fragmentation|fragment=] normally in the [=block axis=].
 
 	<div class=note>
-		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
+		<span class="marker">Note:</span> 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=].
+	</div>
+
+	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 <a href="https://github.com/w3c/csswg-drafts/issues">inform the CSSWG</a>
+		so that these errors can be corrected.
 
 		<div class=example>
 			For example,
@@ -232,7 +214,6 @@ Inline-Size Containment</h3>
 			would be positioned at the top of the container,
 			between the first two floats.
 		</div>
-	</div>
 
 	However, giving an element [=inline-size containment=]
 	has no effect if any of the following are true: