w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.49k stars 662 forks source link

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

Open Loirooriol opened 2 years ago

Loirooriol commented 2 years ago

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.

vmpstr commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

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/w3c/csswg-drafts/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