- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Sep 2024 19:00:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-conditional][css-anchor-position][scroll-animations] Snapshotting post-layout State`, and agreed to the following: * `RESOLVED: run snapshot post-layout state steps` * `RESOLVED: add it to cssom-view` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> futhark: there are multiple specs that do some sort of snapshotting of particular scroll state<br> <kbabbitt> ...some specs try to specify this timing and some have not<br> <kbabbitt> ...for scroll driven animations there is a spec that refers to the HTML spec<br> <kbabbitt> ...that scroll position is snapshotted in the HTML ? at the begining of the animation<br> <kbabbitt> ...there's a separate snapshotting that happens after resize observers<br> <kbabbitt> ...in order to have a stable first frame and avoid flickering<br> <kbabbitt> ...then there is the anchor positioning spec that emilio pointed out<br> <kbabbitt> ...that has an issue to specify when this scroll position / adjustment snapshotting happens<br> <kbabbitt> ...now we're working on state queries and I need the exact same thing for sticky pos state queries<br> <kbabbitt> ...in this issue I propose we try to unify scroll snapshotting to a common point<br> <kbabbitt> ...instead of referring to modified HTML ? from CSS spec<br> <kbabbitt> ...the CSS specs that need to do snapshotting can say it needs to be done during these steps in CSS<br> <kbabbitt> ...what I propose is that we introduce a new step called run snapshot<br> <TabAtkins> "run snapshot post-layout state steps"<br> <kbabbitt> ... do this between media query and ??<br> <kbabbitt> ...basically aligns with where scroll animations spec specifes to do it<br> <kbabbitt> ...and then update the snapshots again and if the snapshots have changed beacuse of layout change, there is a second run of style and layout<br> <emilio> q+<br> <TabAtkins> s/??/update animations/<br> <kbabbitt> ...that is my proposal<br> <Rossen4> ack futhark<br> <Rossen4> ack emilio<br> <kbabbitt> emilio: first, why do we need two steps?<br> <kbabbitt> ...could we do it as part of the resize observer step<br> <kbabbitt> ...do content visibility stuff to prevent unstable frame issue<br> <kbabbitt> .<br> <kbabbitt> ...I think that would be nice because you wouldn't need resize observer updates<br> <kbabbitt> futhark: right, that is actulaly what the current chrome implementation does<br> <kbabbitt> I talked to flackr and he said dieally in terms of the specification have it after the resize steps<br> <kbabbitt> flackr: it's fairly common that devs use resize observer to change the shape of something on screen<br> <kbabbitt> ...you expect that these things that respond to scroll or anchoring or other things to be able to anchor to the content or the size based on developer ?<br> <kbabbitt> emilio: the loop is basically: update style and layout, then figure out ??, then figure out for resize observers wehtehr something's changed<br> <kbabbitt> emilio: if you ? you would potentially run multiple layout loops<br> <kbabbitt> emilio: and you could make it so that you ? resize observations probably<br> <kbabbitt> flackr: I agree and that's probably better, you could have resize observers respond to updated snapshot<br> <kbabbitt> emilio: other question is why do we need snapshot at beginning?<br> <kbabbitt> flackr: usually the scroll position doesn't change and you need to do some layout in your initial pass<br> <kbabbitt> flackr: so in the case where the thing that you're responding to hasn't changed as a result of scrolll, we onlyl have one pass through style and layout<br> <kbabbitt> flackr: whereas if you did it after you'd always have second pass<br> <kbabbitt> flackr: [missed]<br> <kbabbitt> flackr: and unless the result of running that caused scroll position to change, you have your result<br> <kbabbitt> emilio: you are doing the thing right after scroll events get sent<br> <kbabbitt> ...but you have no guarantee that you have updated layout here right?<br> <kbabbitt> ...and you would snapshot a potentially dirty tree or you would run layout there<br> <emilio> https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model<br> <kbabbitt> emilio: proposal is iintroducing a step right after step 10 [in link above]<br> <kbabbitt> futhark: yes, that was our proposal, inspired by scroll animations spec<br> <kbabbitt> emilio: but you either run layout there, in which case it's not more efficient, or just snapshot ?<br> <kbabbitt> flackr: but there is a known scroll position at the least<br> <kbabbitt> ...I guess you're saying some of these things could have snapshot there<br> <kbabbitt> emilio: in order to get consistent bejavior and not depend on... you would get different behavior if a media query change had updated layout versus not which seems bad<br> <kbabbitt> ....so to get consistent behavior you need to update style and layout before doing snapshot<br> <kbabbitt> flackr: other reason to run at this time is I believe it's before rAF callbacks<br> <kbabbitt> emilio: no, it's after<br> <kbabbitt> emilio: nm, it's before<br> <kbabbitt> flackr: this also puts things in a correct animation state which is good for scroll driven animations<br> <kbabbitt> ...your animations are based on the correct input state<br> <kbabbitt> ...would be open to moving that around<br> <kbabbitt> emilio: if we put it before the update animations and send events you also need to update style & layout<br> <kbabbitt> ...that seems promising because rAF is something people use to move content around<br> <kbabbitt> ...so you want to update style & layout as late as possible<br> <kbabbitt> flackr: I think it might be okay to remove that early snapshot<br> <kbabbitt> emilio: that would be great because then snapshot the right thing, resize observer can react properluy<br> <kbabbitt> emilio: update events or animations can ? that snapshot<br> <kbabbitt> emilio: other than anchor positioning where the snapshot doesn't affect what the page can observe ...<br> <kbabbitt> flackr: I suppose if you had a rAF observer that was looking at the position of an anchor element, that observatio nwould forcea style and layout to make it correct<br> <kbabbitt> emilio: you would use the snapshot from your last frame<br> <kbabbitt> flackr: then it would be a correct ?<br> <kbabbitt> emilio: potentially<br> <kbabbitt> futhark: [missed]<br> <kbabbitt> emilio: yes and that's unfortunate because it causes inconsistent behavior if someone has updated style & layout before<br> <kbabbitt> ...anything that changes frame that updates style & layout causes different offsets<br> <kbabbitt> futhark: we use information from last frame<br> <kbabbitt> emilio: not necessarily, you use info from last layout update<br> <kbabbitt> futhark: should be information from ?<br> <kbabbitt> emilio: would prefer to move this only to resize observer, then you get that behavioor automatically<br> <kbabbitt> ...without changing depending on whether someone has updated ?<br> <kbabbitt> ...the whole frame sees the updated offsets until the resize observer<br> <kbabbitt> flackr: right, it makes these scroll dependent queries basically equivalent to a developer observer<br> <kbabbitt> emilio: if we decided that we need for some reason after the offsets from before rAF then I think we should update style & layout to be consistent<br> <kbabbitt> ...that's unfortunate<br> <kbabbitt> futhark: there are a couple of things I'd like to resolve on regardless of orderting<br> <kbabbitt> ...creating this new run steps where we collect all these kinds of snapshotting in the same space for CSS specs<br> <kbabbitt> emilio: think that's great<br> <kbabbitt> futhark: strictly this forum cannot decide the order of the HTML event loop<br> <kbabbitt> ...but creating that step is one resolution I'd lie to make<br> <kbabbitt> ...propose CSSOM-view for it<br> <kbabbitt> Rossen4: back to first resolution which is adding this step for snapshotting<br> <kbabbitt> ...is there anything else we need to discuss about it?<br> <kbabbitt> ...not sure if there was agreement<br> <kbabbitt> flackr: I think we have agreement, I think this is okay to draft<br> <kbabbitt> ...my only concern is things devs to in rAF<br> <kbabbitt> ...but that's also a problem with anything they do in resize observers<br> <kbabbitt> emilio: already the case if author has updated layout manually<br> <kbabbitt> flackr: I do think that case is less common, still common but majority of updates are scroll with no dirty layout<br> <kbabbitt> emilio: in that case we're observing a dirty tree because you haven't done layout yet<br> <kbabbitt> flackr: if the animation time is updated according to the new scroll position, then a rAF observing some style or layout property will force an update, getting the correct for now position<br> <kbabbitt> Rossen4: back to resolution, any objections?<br> <futhark> “run snapshot post-layout state steps”<br> <kbabbitt> RESOLVED: run snapshot post-layout state steps<br> <kbabbitt> Rossen4: second part was figuring out where this should go<br> <kbabbitt> ...was suggested to put in cssom-view<br> <kbabbitt> futhark: that's kind of arbitrary based on where scroll steps were<br> <kbabbitt> emilio: seems fine to me<br> <kbabbitt> RESOLVED: add it to cssom-view<br> <kbabbitt> futhark: the rest here is really WHATWG's HTML spec change<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10796#issuecomment-2379885032 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 September 2024 19:00:46 UTC