-
Notifications
You must be signed in to change notification settings - Fork 717
[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
Comments
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 |
@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:
Chromium and Firefox are currently doing 1. |
The CSS Working Group just discussed
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 |
https://drafts.csswg.org/css-sizing-4/#last-remembered
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 ?
The text was updated successfully, but these errors were encountered: