Skip to content

[css-sizing] Last remembered size for non-atomic inlines? #7606

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

Open
Loirooriol opened this issue Aug 15, 2022 · 3 comments
Open

[css-sizing] Last remembered size for non-atomic inlines? #7606

Loirooriol opened this issue Aug 15, 2022 · 3 comments

Comments

@Loirooriol
Copy link
Contributor

https://drafts.csswg.org/css-sizing-4/#last-remembered

At the time that ResizeObserver events are determined and delivered, if an element has contain-intrinsic-size: auto, is capable of being a ResizeObserver target, but does not have size containment, record the current inner dimensions of its principal box as its last remembered size.

Does this record the size of a non-atomic inline element? If so, how is that size defined?

Is it like in https://drafts.csswg.org/resize-observer-1/#content-rect-h ?

non-replaced inline Elements will always have an empty content rect.

@Loirooriol Loirooriol changed the title [css-sizing] Last rememebred size for non-atomic inlines? [css-sizing] Last remembered size for non-atomic inlines? Aug 15, 2022
@vmpstr
Copy link
Member

vmpstr commented Sep 6, 2022

The size being empty makes sense. Size containment for non-atomic inlines doesn't have any effect, so I don't think the value here is observable

@Loirooriol
Copy link
Contributor Author

@vmpstr It's observable if you later turn it into a block, i.e.

<div id="test">
  <div style="width: 100px; height: 100px"></div>
</div>
<script>
function nextRendering() {
  return new Promise(resolve => {
    requestAnimationFrame(() => requestAnimationFrame(() => resolve()));
  });
}
(async () => {
  // No last rememebered size yet
  test.style.cssText = "width: max-content; height: max-content; contain-intrinsic-size: auto 1px";
  await nextRendering();

  // Now the last remembered size is 100x100
  test.style.display = "inline";
  await nextRendering();

  // Does the last remembered size become 0x0 or preserve the old 100x100?
  test.style.display = "block";
  test.style.contentVisibility = "hidden";
  console.log(test.clientWidth, test.clientHeight); // ???
})();
</script>

IMO there are two reasonable possibilities:

  1. Treat inlines as being 0x0, and record that size as usual
  2. Do not record the size of an inline, like in the display: none case

Chromium and Firefox are currently doing 1.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-sizing] Last remembered size for non-atomic inlines?, and agreed to the following:

  • RESOLVED: display:inline doesn't record a size
The full IRC log of that discussion <fantasai> Topic: [css-sizing] Last remembered size for non-atomic inlines?
<fantasai> github: [css-sizing] Last remembered size for non-atomic inlines?
<astearns> github: https://github.com//issues/7606
<fantasai> oriol: Spec doesn't clarify the details of what size we are recording as the last remembered size
<fantasai> oriol: for non-atomic inline elements, it's hard to determine a size
<fantasai> oriol: ? has a size of 0x0
<fantasai> oriol: when recording a size, we have two resonable ways
<fantasai> oriol: one is to store 0x0 as usual
<fantasai> oriol: this is what implementations are currently doing
<fantasai> oriol: might be a bit surprising since not the real size, just an arbitrary decision
<fantasai> oriol: another possibility would be doing the same that we do for display:none or when not generating a box
<fantasai> oriol: we are not storing the last remembered size
<fantasai> oriol: and we allow the element to keep a previously-set last remembered size
<fantasai> oriol: I don't have a strong opinion
<fantasai> oriol: bit of an edge case, since inline elements do not support size containment
<fantasai> oriol: so this will only matter if you are dynamically changing the display from 'inline' to other things
<fantasai> oriol: but would like to clarify expected behavior
<fantasai> astearns: when you say Chrome and FF are treating inlines as 0x0
<fantasai> astearns: WebKit result is different? or don't know?
<fantasai> oriol: I think WK has not implemented this feature
<fantasai> TabAtkins: I have no attachment to either solution
<fantasai> TabAtkins: in absence of a reason for a change, would stick with existing behavior
<fantasai> dholbert: Seems weird to have different behaviors for transiently display:none vs display:inline
<fantasai> dholbert: without a good reason for 0x0 it feels arbitrary to have those differ
<fantasai> dholbert: what happens if you 'display: contents' or other value?
<fantasai> dholbert: would be best to have a consistent answer to "no sensible size"
<fantasai> TabAtkins: that's fair
<fantasai> astearns: other opinions?
<fantasai> [silence]
<fantasai> astearns: Proposed resolution is to not accept current behavior in impls, but go with option 2 of not recording the size
<fantasai> astearns: any objections?
<fantasai> RESOLVED: display:inline doesn't record a size

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

No branches or pull requests

3 participants