Re: [csswg-drafts] [css-anchor-position] Absolutely positioned element does not find fixed anchor (#10419)

@Westbrook Hm, that example definitely looks broken to me. [Reproducing it myself](https://codepen.io/TabAtkins/pen/MWMqgay), I find that it's the specific combination of (1) the container being abspos or fixpos, (2) the anchor being fixpos, and (3) the dialog being in the top layer, that break the positioning. Change any of those three, and it works successfully. This suggests a bug.

I think it's caused by the ["acceptable anchor element" definition](https://drafts.csswg.org/css-anchor-position/#acceptable-anchor-element) not really mentioning top layer stuff. I'm considering rewriting the relevant ordering conditions to the following:

 * |possible anchor| is painted strictly before |positioned el|,
  aka one of the following is true:
  * |positioned el| is [=in a higher top layer=] than |possible anchor|
  * Both elements are [=in the same top layer=]
   but have different [=containing blocks=], 
   and |positioned el|'s [=containing block=]
   is an ancestor of |possible anchor|'s [=containing block=]
   in the [=containing block chain=],
   aka one of the following:
   * |positioned el|'s [=containing block=] is the viewport,
    and |possible anchor|'s [=containing block=] isn't.
   * |positioned el|'s [=containing block=] is the [=initial containing block=],
    and |possible anchor|'s [=containing block=] is generated by an element,
   * both elements' [=containing blocks=] are generated by elements,
    and |positioned el|'s containing block
    is an ancestor in the [=flat tree=]
    to that of |possible anchor|'s [=containing block=].
  * Both elements are [=in the same top layer=]
   and have the same [=containing block=],
   and are both [=absolutely positioned=],
   and |possible anchor| is earlier in [=flat tree=] order
   than |positioned el|.
  * Both elements are [=in the same top layer=]
   and have the same [=containing block=],
   but |possible anchor| isn't [=absolutely positioned=].

(The constraints that aren't about relative ordering stay as they are.)

@lilles or @bfgeek , do these revised conditions sound correct to you? @fantasai, do these read better than the current text?

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10419#issuecomment-2319563972 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 30 August 2024 00:41:54 UTC