w3c / w3c/csswg-drafts

[css-sizing] Define precise timing for setting last remembered size?

Open
#7,659 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

css-sizing-4 Needs Edits
Dominant language
Bikeshed
Stars
4.9k
Forks
816
PR merge metrics
PR metrics pending

Description

From https://drafts.csswg.org/css-sizing-4/#last-remembered, the last remembered size is recorded

At the time that ResizeObserver events are determined and delivered

But what if the author is already observing the element with some ResizeObservers? When an observed element changes size, the various callbacks are invoked in order of the creation of the ResizeObservers. And the callbacks can check whether the last remembered size has been recorded or not.

Then webpages can tell that both Firefox and Chromium:

  • Reuse the same ResizeObserver instance for updating the last remembered size of all elements that need it.
  • This ResizeObserver instance is created the 1st time that an element with contain-intrinsic-size: auto and no size containment is laid out.
  • This ResizeObserver instance is never removed (during the lifetime of the document).

Are we fine exposing these implementations details? Should we define a more precise timing, e.g. that the last remembered size is set just before invoking the (other) ResizeObservers callbacks for that element?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read the CSS Sizing Level 4 section on last remembered size and the linked Resize Observer specification. Compare the stated timing with the reported Firefox and Chromium behavior, including observer callback ordering and the lifetime of the shared ResizeObserver. Done means resolving whether implementation details should remain observable or defining more precise timing.

Written by the indexing model from the issue text.

Assessment

Tech stack
css
Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.