[css-anchor-position][editorial] Provide some detail on exactly what the limitations of scroll adjustment are.

Author: tabatkins

css-anchor-position-1/Overview.bs

@@ -988,6 +988,44 @@ we define:
 	before style recalc.
 </div>
 
+<details class=note>
+	<summary>Implied restrictions of scroll adjustment</summary>
+
+	In short: a positioned element
+	is able to have its <em>position</em>
+	rely on a scrollable anchor in a different scroll container,
+	but cannot have its <em>size</em> depend on that.
+	This restriction allows "composited scrolling" to continue to be used,
+	where the actual shifting of a scrollable element's contents
+	is done in a separate "compositing thread" in the UA,
+	and the rest of the CSS
+	(in particular, layout)
+	can't directly depend on its results.
+
+	This is why only <em>one</em> anchor
+	(the [=default anchor element=])
+	is used for scroll adjustment--
+	if multiple anchors could be adjusted for,
+	then a positioned element could use different ones for opposite sides,
+	and trigger layout as a result of either of them scrolling.
+
+	Position fallback *can* end up depending on scroll adjustment,
+	which can cause re-layout
+	since the [=sizing properties=] are [=accepted @position-try properties=].
+	However, it's acceptable for fallback due to scrolling
+	to happen <em>a frame late</em>,
+	after the UA has had time to receive scrolling information
+	from the compositing thread.
+	This is not the case for simple position tracking--
+	if the positioned element is meant to sit snug against the anchor,
+	having it lag a frame behind is very user-visible,
+	and a pretty bad experience.
+
+	If you want to have a positioned element's size
+	depend on an anchor's scroll position,
+	the positioned element must be inside of the same scroll container,
+	so the two elements are never scrolled relative to each other at all.
+</div>
 
 Validity {#anchor-valid}
 --------