Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-sizing] How does 0x0 size affect last remembered size? #7539

Open
Loirooriol opened this issue Jul 26, 2022 · 2 comments
Open

[css-sizing] How does 0x0 size affect last remembered size? #7539

Loirooriol opened this issue Jul 26, 2022 · 2 comments

Comments

@Loirooriol
Copy link
Contributor

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.

@css-meeting-bot
Copy link
Member

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
The full IRC log of that discussion <emilio> Topic: [css-sizing] How does 0x0 size affect last remembered size?
<emilio> github: https://github.com//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
Copy link
Contributor Author

There is #3664 about 0x0 in ResizeObserver.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Tuesday
Development

No branches or pull requests

2 participants