[css-anchor-position] Rephrase the text specifying that later positioned elements can't cause earlier ones to relitigate their fallback position. Remove issue about this.

Author: tabatkins

css-anchor-position-1/Overview.bs

@@ -1360,9 +1360,8 @@ Applying Position Fallback {#fallback-apply}
 
 When a positioned element overflows its [=inset-modified containing block=],
 and has a non-empty [=position options list=],
-it iterates the [=position options list=],
-applying each [=position option's=] styles over the element's base styles,
-and attempts to find an option that avoids overflow.
+it [=determines the position fallback styles=] for the element
+to attempt to find an option that avoids overflow.
 
 These modified styles are applied to the element via [=interleaving=],
 so they affect [=computed values=]
@@ -1419,50 +1418,36 @@ as part of a theoretical UA-controlled final cascade layer.
 	only |el|'s own [=margin box=].
 </div>
 
+During a full layout pass,
+once an element has determined its fallback styles
+(or determined it's not using any),
+laying out later elements cannot change this decision.
+
+<div class=example>
+	For example, say you have two positioned elements,
+	A and B,
+	with A laid out before B.
+	If B overflows and causes A's containing block to gain scrollbars,
+	this <em>does not</em> cause A
+	to go back and re-determine its fallback styles
+	in an attempt to avoid overflowing.
+	(At best, this can result in exponential layout costs;
+	at worst, it's cyclic and will never settle.)
+
+	Layout does not "go backward", in other words.
+</div>
+
 Issue: Make sure the snapshotted scroll offset stuff is correct now,
 given interleaving.
 
 Issue: Add conditions for forgetting the [=last successful position option=],
 similar to the [=last remembered size=]
 
-The styles returned by [=determining the position fallback styles=]
-are taken as the final values for the specified properties.
-
 Implementations may choose to impose an implementation-defined limit
 on the length of [=position options lists=],
 to limit the amount of excess layout work that may be required.
 This limit must be <em>at least</em> five.
 
-<div class=issue>
-	Nested anchors
-	(an anchored element inside of another anchored element)
-	present the potential for exponential blow-up of layouts
-	when doing fallback,
-	since the grandchild anchored element can cause scrollbars on an ancestor,
-	changing the IMCB for the child anchored element,
-	thus possibly causing the fallback choice to change for it.
-
-	There are strategies to avoid this,
-	but they're not without costs of their own.
-	We should <em>probably</em> impose a <strong>maximum</strong> limit as well,
-	to avoid this.
-
-	However, since *most* usages won't be problematic in the first place,
-	we don't want to restrict them unduly
-	just to prevent weird situations from exploding.
-	Perhaps a complexity budget based on the branching factor at each level?
-	Like, accumulate the product of the fallback list lengths from ancestors,
-	and your fallback list gets limited to not exceed a total product
-	of, say, 1k.
-	Get too deep and you're stuck with your first choice only!
-	But this would allow large, complex fallback lists for top-level stuff,
-	and even some reasonable nesting.
-	(Length-five lists could be nested to depth of 4, for example,
-	if we did go with 1k.)
-
-	More thought is needed.
-</div>
-
 <div class=example>
 	For example,
 	the following CSS will first attempt to position a "popover"
@@ -1474,47 +1459,16 @@ This limit must be <em>at least</em> five.
 	<pre highlight=css>
 	#myPopover {
 		position: fixed;
-		position-fallback: --button-popover;
-		overflow: auto;
+		top: anchor(--button bottom);
+		left: anchor(--button left);
+		position-try-options: flip-inline, flip-block, flip-block flip-inline;
 
 		/* The popover is at least as wide as the button */
 		min-width: anchor-size(--button width);
 
 		/* The popover is at least as tall as 2 menu items */
 		min-height: 6em;
 	}
-
-	@position-fallback --button-popover {
-		/* First try to align the top, left edge of the popover
-		with the bottom, left edge of the button. */
-		@try {
-			top: anchor(--button bottom);
-			left: anchor(--button left);
-		}
-
-		/* Next try to align the bottom, left edge of the popover
-		with the top, left edge of the button. */
-		@try {
-			bottom: anchor(--button top);
-			left: anchor(--button left);
-		}
-
-		/* Next try to align the top, right edge of the popover
-		with the bottom, right edge of the button. */
-		@try {
-			top: anchor(--button bottom);
-			right: anchor(--button right);
-		}
-
-		/* Finally, try to align the bottom, right edge of the popover
-		with the top, right edge of the button. Other positions are possible,
-		but this is the final option the author would like the rendering
-		engine to try. */
-		@try {
-			bottom: anchor(--button top);
-			right: anchor(--button right);
-		}
-	}
 	</pre>
 </div>