css-meeting-bot
commented
2 years ago 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-sRESOLVED: Replace ResizeObserver editors with Oriol and Emilio
The full IRC log of that discussion
<emilio> Topic: [css-sizing] How does 0x0 size affect last remembered size?<emilio> github: https://github.com/w3c/csswg-drafts/issues/7539
<JakeA> Thanks all. I'm going to finish some spec edits for SET. Ping me if you need me and I'll rejoin.
<emilio> oriol: Not sure if I should do a quick intro about contain-intrinsic-size: auto
<emilio> ... which is a feature that remembers the last size of an element
<emilio> ... and then uses that instead of collapsing the contribution of the contents
<emilio> ... when you have size containment
<emilio> ... this specific issue is about 0x0 size. The spec seems to assume that using ResizeObserver is the way to track this size
<emilio> ... since it mentions that the size is updated at ResizeObserver time
<emilio> ... when implementing this I found a problem when the size is 0x0
<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
<dbaron> This sounds like a spec bug, and the spec should handle 0x0 sizes just like other sizes.
<emilio> ... but you don't get it without it
<emilio> ... so the question is should we still store this size as the last remembered size?
<emilio> ... seems like Chromium wasn't doing it
<emilio> ... so I don't see a reason about why special-casing it
<emilio> q+
<TabAtkins> q+
<fantasai> scribe+
<Rossen_> ack emilio
<fantasai> emilio: now that you've explained this, this is only observable in some cases, right?
<fantasai> emilio: if there's not stored size, you use 0x0
<fantasai> emilio: e.g. in one axis
<emilio> oriol: when you have c-i-s: auto you need to provide a fallback value
<flackr> q+
<emilio> ... so if you get the fallback you can detect it's not stored
<Rossen_> ack TabAtkins
<emilio> TabAtkins: this appears to be a corner case falling from the implementation details
<emilio> ... so I don't mind either way
<emilio> ack dbaron
<Rossen_> ack dbaron
<emilio> dbaron: I think this is just a spec bug that was copied to the spec because it was written based on impl
<emilio> ... I think 0x0 should be handled like any other size
<emilio> TabAtkins: the spec doesn't special-case this
<emilio> ... so it's an impl bug
<emilio> q+
<emilio> oriol: yeah, this is because the ResizeObserver inits its size to 0x0
<Rossen_> ack flackr
<emilio> TabAtkins: we only reuse the RO timing
<emilio> dbaron: it might be a bug in ResizeObserver
<emilio> flackr: should we remember 0x0 only if the element was visible? This is intended for content-visibility
<emilio> oriol: there are some issues with storing the size
<Rossen_> q
<emilio> oriol: you need to be size-contained at the time, which c-v provides in some cases
<emilio> ... so if you lay out the content normally without size-containment etc it gets saved
<emilio> flackr: if the element has never been on screen we shouldn't be remembering 0x0 for its size
<emilio> ... we'd lay out 0x0 with c-v: hidden
<emilio> oriol: if it has c-v from the beginning you don't store the size
<emilio> flackr: but c-v: auto changes dynamically when you scroll
<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
<emilio> flackr: so we won't save the size if it has size containment, so my concern is addressed
<emilio> ... resizeobserver will still fire
<emilio> oriol: yeah, but you won't store the last remembered size
<fantasai> emilio: I think I agree with dbaron , but it feels like ??
<fantasai> emilio: IntersectionObserver does fire an observation immediately, regardless of whether on the screen
<dbaron> s/but it feels like ??/that it feels like a bug in ResizeObserver/
<fantasai> emilio: so it feels to me like a bug that ResizeObserver doesn't fire on zero
<flackr> +1
<fantasai> emilio: and that would fix this by extension
<fantasai> emilio: so I suspect we just move this to the ResizeObserver spec
<fantasai> emilio: idk who's the editor of that?
<fantasai> emilio: but given the precedent of IntersectionObserver always firing as well, it doesn't seem to me that this would be ???
<vmpstr> s/???/objectionable/
<Rossen_> q?
<fantasai> emilio: It seems the editors are no longer working on CSS specs
<fantasai> emilio: so we need new editors for this spec?
<fantasai> Rossen_: Let's figure out what we want to fix and then figure out who is going to do it
<fantasai> oriol: Proposed resolution would be that 0x0 size is not special, is just like any other size
<fantasai> emilio: that's the current spec behavior
<fantasai> Rossen_: that doesn't require any change to the spec, simply requires implementations to fix their bugs
<fantasai> emilio: but then we need to file a ResizeObserver bug
<fantasai> Rossen_: yeah, but we're here to fix specs
<fantasai> Rossen_: seems we don't need a spec change, if hte bugs are not filed, please go and file them
<fantasai> Rossen_: Anything else on this topic?
<fantasai> Rossen_: objections to resolving on 0x0 is not a special size?
<fantasai> RESOLVED: 0x0 is not special wrt ResizeObserver or c-i-s
<fantasai> emilio: This means we need ResizeObserver spec changes
<fantasai> [discussion of possible editors]
<fantasai> RESOLVED: Replace ResizeObserver editors with Oriol and Emilio
Loirooriol
This seems designed so that it can be implemented with an internal
ResizeObserver.There is a catch, though https://drafts.csswg.org/resize-observer-1/#dom-resizeobservation-resizeobservation-target-options initializes lastReportedSizes slot to [(0,0)].
This means that observing an element with a 0x0 size will not invoke the callback. But I guess 0x0 should still be stored as the last remembered size (if the conditions hold), right? It's not happening in Chromium.