- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Aug 2022 13:48:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing] How does 0x0 size affect last remembered size?`, and agreed to the following: * `RESOLVED: 0x0 is not special wrt ResizeObserver or c-i-s` * `RESOLVED: Replace ResizeObserver editors with Oriol and Emilio` <details><summary>The full IRC log of that discussion</summary> <emilio> Topic: [css-sizing] How does 0x0 size affect last remembered size?<br> <emilio> github: https://github.com/w3c/csswg-drafts/issues/7539<br> <JakeA> Thanks all. I'm going to finish some spec edits for SET. Ping me if you need me and I'll rejoin.<br> <emilio> oriol: Not sure if I should do a quick intro about contain-intrinsic-size: auto<br> <emilio> ... which is a feature that remembers the last size of an element<br> <emilio> ... and then uses that instead of collapsing the contribution of the contents<br> <emilio> ... when you have size containment<br> <emilio> ... this specific issue is about 0x0 size. The spec seems to assume that using ResizeObserver is the way to track this size<br> <emilio> ... since it mentions that the size is updated at ResizeObserver time<br> <emilio> ... when implementing this I found a problem when the size is 0x0<br> <emilio> ... if you start observing an element with ResizeObserver and the element doesn't have a 0x0 size then you get an observation with the current size<br> <dbaron> This sounds like a spec bug, and the spec should handle 0x0 sizes just like other sizes.<br> <emilio> ... but you don't get it without it<br> <emilio> ... so the question is should we still store this size as the last remembered size?<br> <emilio> ... seems like Chromium wasn't doing it<br> <emilio> ... so I don't see a reason about why special-casing it<br> <emilio> q+<br> <TabAtkins> q+<br> <fantasai> scribe+<br> <Rossen_> ack emilio<br> <fantasai> emilio: now that you've explained this, this is only observable in some cases, right?<br> <fantasai> emilio: if there's not stored size, you use 0x0<br> <fantasai> emilio: e.g. in one axis<br> <emilio> oriol: when you have c-i-s: auto you need to provide a fallback value<br> <flackr> q+<br> <emilio> ... so if you get the fallback you can detect it's not stored<br> <Rossen_> ack TabAtkins<br> <emilio> TabAtkins: this appears to be a corner case falling from the implementation details<br> <emilio> ... so I don't mind either way<br> <emilio> ack dbaron<br> <Rossen_> ack dbaron<br> <emilio> dbaron: I think this is just a spec bug that was copied to the spec because it was written based on impl<br> <emilio> ... I think 0x0 should be handled like any other size<br> <emilio> TabAtkins: the spec doesn't special-case this<br> <emilio> ... so it's an impl bug<br> <emilio> q+<br> <emilio> oriol: yeah, this is because the ResizeObserver inits its size to 0x0<br> <Rossen_> ack flackr<br> <emilio> TabAtkins: we only reuse the RO timing<br> <emilio> dbaron: it might be a bug in ResizeObserver<br> <emilio> flackr: should we remember 0x0 only if the element was visible? This is intended for content-visibility<br> <emilio> oriol: there are some issues with storing the size<br> <Rossen_> q<br> <emilio> oriol: you need to be size-contained at the time, which c-v provides in some cases<br> <emilio> ... so if you lay out the content normally without size-containment etc it gets saved<br> <emilio> flackr: if the element has never been on screen we shouldn't be remembering 0x0 for its size<br> <emilio> ... we'd lay out 0x0 with c-v: hidden<br> <emilio> oriol: if it has c-v from the beginning you don't store the size<br> <emilio> flackr: but c-v: auto changes dynamically when you scroll<br> <emilio> oriol: if you have c-v: auto initially outside of the screen we won't store the last remembered size because it has size containment, we'll store it once you enter the screen<br> <emilio> flackr: so we won't save the size if it has size containment, so my concern is addressed<br> <emilio> ... resizeobserver will still fire<br> <emilio> oriol: yeah, but you won't store the last remembered size<br> <fantasai> emilio: I think I agree with dbaron , but it feels like ??<br> <fantasai> emilio: IntersectionObserver does fire an observation immediately, regardless of whether on the screen<br> <dbaron> s/but it feels like ??/that it feels like a bug in ResizeObserver/<br> <fantasai> emilio: so it feels to me like a bug that ResizeObserver doesn't fire on zero<br> <flackr> +1<br> <fantasai> emilio: and that would fix this by extension<br> <fantasai> emilio: so I suspect we just move this to the ResizeObserver spec<br> <fantasai> emilio: idk who's the editor of that?<br> <fantasai> emilio: but given the precedent of IntersectionObserver always firing as well, it doesn't seem to me that this would be ???<br> <vmpstr> s/???/objectionable/<br> <Rossen_> q?<br> <fantasai> emilio: It seems the editors are no longer working on CSS specs<br> <fantasai> emilio: so we need new editors for this spec?<br> <fantasai> Rossen_: Let's figure out what we want to fix and then figure out who is going to do it<br> <fantasai> oriol: Proposed resolution would be that 0x0 size is not special, is just like any other size<br> <fantasai> emilio: that's the current spec behavior<br> <fantasai> Rossen_: that doesn't require any change to the spec, simply requires implementations to fix their bugs<br> <fantasai> emilio: but then we need to file a ResizeObserver bug<br> <fantasai> Rossen_: yeah, but we're here to fix specs<br> <fantasai> Rossen_: seems we don't need a spec change, if hte bugs are not filed, please go and file them<br> <fantasai> Rossen_: Anything else on this topic?<br> <fantasai> Rossen_: objections to resolving on 0x0 is not a special size?<br> <fantasai> RESOLVED: 0x0 is not special wrt ResizeObserver or c-i-s<br> <fantasai> emilio: This means we need ResizeObserver spec changes<br> <fantasai> [discussion of possible editors]<br> <fantasai> RESOLVED: Replace ResizeObserver editors with Oriol and Emilio<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7539#issuecomment-1202608735 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 August 2022 13:48:38 UTC