Re: [csswg-drafts] [css-anchor-position] Better handling of scroll position for fixpos elements on first layout (#10999)

The CSS Working Group just discussed `[css-anchor-position] Better handling of scroll position for fixpos elements on first layout`, and agreed to the following:

* `RESOLVED: accept what I said in the thread with caveat from here. when an anchor position element is first rendered or change fallback position, use the current scroll offset to calculate its position area`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> https://github.com/w3c/csswg-drafts/issues/10999#issuecomment-2415284548<br>
&lt;matthieud> TabAtkins:  anytime you do something which respond to scroll state, it is generally do on compositor thread<br>
&lt;matthieud> TabAtkins:  so no layout or ok do be a frame delayed<br>
&lt;matthieud> TabAtkins:  anchor-positioning is careful about being mostly doable on compositor except some spec defined part<br>
&lt;matthieud> TabAtkins:  this is about one specific section : customisable select is not responding to scrolling as much as it could<br>
&lt;matthieud> TabAtkins: cf link comment<br>
&lt;matthieud> if you scroll the viewport, and reopen the popup, you don't get what is expected (the second image)<br>
&lt;matthieud> TabAtkins:  it doesnt look very right because currently spec mandates that the calcul is done on the initial position<br>
&lt;matthieud> TabAtkins: we generally need this restriction<br>
&lt;matthieud> TabAtkins: some cases we should remove it though : when  ??? or when doing fallback<br>
&lt;emilio> q+<br>
&lt;matthieud> PROPOSAL: change the rule for calculating position-area : when an element is first rendered or switch from fallback, calculate its position form the current scroll offset, not the initial scroll position<br>
&lt;flackr> q+<br>
&lt;matthieud> TabAtkins: we need this to make customisable select correct otherwise it's very weird (specially when they start off screen)<br>
&lt;TabAtkins> s/???/first creating boxes/<br>
&lt;matthieud> emilio: same similarity with last remember ??? stuff<br>
&lt;matthieud> emilio: not objecting, we need more details<br>
&lt;TabAtkins> s/???/size/<br>
&lt;Rossen16> ack emilio<br>
&lt;Rossen16> ack flackr<br>
&lt;matthieud> flackr:  one case im worried is if you scroll up, recomputing the size based on current scroll, it would then fit and you dont want it to try to resize using the original position area<br>
&lt;emilio> s/we need more details/we need the details very well defined/<br>
&lt;kizu> q+<br>
&lt;matthieud> TabAtkins: when you trigger fallback it might move to a new fallback position<br>
&lt;matthieud> flackr: reusing the first position would be bad<br>
&lt;fserb> (got to go)<br>
&lt;matthieud> TabAtkins:  it could be weird, we need to treat this size as tainted<br>
&lt;matthieud> flackr: we need to do something to force it to a different fallback<br>
&lt;matthieud> flackr:  like not recomputing the available area<br>
&lt;matthieud> TabAtkins:  stuff about remembering fallback ???<br>
&lt;matthieud> kizu: +1<br>
&lt;Rossen16> ack kizu<br>
&lt;matthieud> kizu:  I got this issue<br>
&lt;matthieud> TabAtkins:  how solved it statically or a frame delayed ?<br>
&lt;matthieud> kizu:  it was dynamic, and it would be better if static<br>
&lt;matthieud> kizu: we are using a library for this : they are dynamic<br>
&lt;matthieud> kizu: static is better here<br>
&lt;matthieud> TabAtkins: everybody is okay with this approach<br>
&lt;matthieud> RESOLVED: accept what I said in the thread with caveat from here. when an anchor position element is first rendered or change fallback position, use the current scroll offset to calculate its position area<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10999#issuecomment-2417388395 using your GitHub account


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

Received on Wednesday, 16 October 2024 16:50:57 UTC