- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Apr 2023 16:54:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain] content-visibility: auto visibility check timing needs details`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> vmpstr: emilio raised that the language in the current Contain spec is hard to implement<br> <TabAtkins> vmpstr: specifically, the behavior of content-visiblity:auto elements when determining visibility<br> <TabAtkins> vmpstr: intended behavior is that the very first time we determine vis, that determination happens sync, and if it changes the state of the visibility, the style/layout pass happen sync with it so the first frame is consistent and correct<br> <TabAtkins> vmpstr: Adding content-vis:auto on an element alreayd in the viewport would otherwise cause a flash of blank, because the typical (non-first) determination of visibility is deferred to next frame<br> <TabAtkins> vmpstr: In my last comment in issue, I tried to propose spec changes to capture this rigorously<br> <TabAtkins> vmpstr: Proposal is to adopt that text<br> <TabAtkins> emilio: I agenda+'d befor eyou added that comment, thanks for writing it<br> <TabAtkins> emilio: Specifics of timing are observable in different ways<br> <TabAtkins> emilio: iiuc, the way chrome does it fires right before ResizeObserver<br> <TabAtkins> emilio: scroll events, anchoring, etc all see this<br> <TabAtkins> emilio: I'd love if someone from WK could go over this and confirm it's fine<br> <TabAtkins> emilio: I'm not opposed to doing this just before RO, just want to make sure it's interop<br> <flackr> https://github.com/w3c/csswg-drafts/issues/8694 is also related<br> <flackr> q+<br> <TabAtkins> emilio: I find it a bit unfortunate we can't just use an IO to explain how this behavior, but I understand the use-case of appending<br> <astearns> ack flackr<br> <TabAtkins> flackr: I linked a related issue for scroll anims, the determination of frames can depend on alyout and we don't want the flash either<br> <TabAtkins> flackr: We should think thru before/after RO for that other use-case too. I specifically put it *after* because the user-defined sizing might affect things we want to respond to<br> <TabAtkins> flackr: But for c-v i'm concerned it might go both ways. An RO might make something visible, but also people might want RO positioning to rely on correct c-v.<br> <TabAtkins> emilio: Right, and in Chrome right now if you append a c-v:auto element within an RO, it just won't work, right?<br> <TabAtkins> vmpstr: If you make a new element in an RO callback it works in the same way, it hits the RO for that call in the same loop<br> <TabAtkins> vmpstr: The RO itself causes a flash of rendering, so if it changes things we do sync run style/layout<br> <TabAtkins> emilio: Oh so this also happens if you gBCR() on the element, you get new size?<br> <TabAtkins> vmpstr: I don't.... believe so? At least not per spec<br> <TabAtkins> vmpstr: To address why we wanted it before, we just don't really want to add a lot of script determining visibility/rendering. But if you put RO before, you get script running that can observe it.<br> <TabAtkins> emilio: It feels like this needs a bit more care. Maybe done along the RO loop somehow?<br> <TabAtkins> emilio: From what you wrote, I understood - in partiuclar the second-to-lst sentence you wrote "this always happens in lifecycle before RO steps", it sounded like a new lifecycle step, but it seem syou're not doing that if appending an el in an RO causes this to run somehow<br> <TabAtkins> astearns: Take back to the issue, then?<br> <TabAtkins> emilio: think that's fine, and again if someone from WK could look it would be great<br> <TabAtkins> smfr: I saw it. Agree that the interactions are hard to understand, maybe just have to implement to see what's happening.<br> <TabAtkins> smaug: I agree that using IO in a way that differs from the web version is weird - makes me question why authors can't get a non-flashing IO too?<br> <TabAtkins> emilio: that's fair<br> <TabAtkins> astearns: Let's close discussion and take it back to the issue, please add comments on what you'd like to see changed<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8542#issuecomment-1505609279 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 April 2023 16:54:19 UTC