- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Apr 2026 19:06:10 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing] Intrinsic min/max block sizes with aspect ratio?`, and agreed to the following: * `RESOLVED: for non replaced elements, while computing the initial block size, min-content, max-content etc. are considered indefinite` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> oriol: this is an inconsistency which can be observed in blink and webkit, not in gecko<br> <kbabbitt> ... blink and webkit have an inconsistent sizing behavior comparing replaced elements and non-replaced<br> <kbabbitt> ... I posted some examples in the issue<br> <kbabbitt> ... basically the idea is that since replaced elements dont actually need layout, when having intrinsic kewyord in block axis we can somewhat resolve those intrinsic keywords without having to do additional layout<br> <kbabbitt> ... process ends up being: first we want to resolve the final inline size<br> <kbabbitt> ... we may have intrinsic keywords in in line axis, may want tot rtransfer from block asix<br> <kbabbitt> ... block axis may also have intrinsic keywords<br> <kbabbitt> ... this is where we have the difference<br> <kbabbitt> ... non replaced elements ignore intrinsic keywords at this point<br> <kbabbitt> ... replaced elements resolve them by computing tentative inline size<br> <kbabbitt> ... first tentative inline size ignoring both sizing properties<br> <kbabbitt> ... compute tentqtive size in inline axis but not block axis<br> <kbabbitt> ... can compute final inline size then final block size<br> <kbabbitt> ... question is, are we fine with having this inconsistency between replaced and non-replaced?<br> <kbabbitt> ... if we want to align them to be the sasme, we should align replaced with non-replaced<br> <kbabbitt> ... we need the opposite with ???<br> <kbabbitt> ... ignore properties, then compute inline size, then compute final size<br> <iank_> q+<br> <kbabbitt> ... are we fine with this inconsistent behavior or do we want to align replaced with non-replaced?<br> <kbabbitt> ... blink and webkit have minor differences but don't align these<br> <Rossen> q?<br> <kbabbitt> ... gecko doesn't support intrinsic keywords on replaced<br> <kbabbitt> iank_: we shouldn't do the double layout for non-replaced<br> <kbabbitt> ... I'm fine with inconsistency<br> <kbabbitt> .... with replaced doing this additional behavior<br> <kbabbitt> ... think it makes more sense in almost all cases s we should just be inconsisitent<br> <kbabbitt> ... also how you compute replaced isn't particularly well defined that gets into the next issue<br> <sgill> q+<br> <Rossen> ack iank_<br> <kbabbitt> sgill: I think I agree<br> <Rossen> ack sgill<br> <kbabbitt> ... with the replaced case it makes sense what is happening<br> <kbabbitt> ... because we have natrual sizes to fall back on<br> <kbabbitt> ... in non-replaced you ask for max content size<br> <kbabbitt> ... and that thing has an apsect ratio<br> <kbabbitt> ... then it's not as obvous as natrual size case of replaced element<br> <kbabbitt> oriol: not always grabbing natural block size<br> <kbabbitt> ... there's an inconsistency between natural size and ?<br> <kbabbitt> sgill: barring that<br> <kbabbitt> iank_: webkit's got some interesting behavior here, generally you don't need to layout multiples, you have the information to calculate correctly<br> <kbabbitt> Rossen: which way are we resolving?><br> <kbabbitt> oriol: I guess iank_ was favoring the inconsisitency, I'm fine either way<br> <kbabbitt> oriol: While computing intrinsic inline sizes, resolve intrinsic keywords in block axis ....<br> <kbabbitt> ... iank_ can you summarize?<br> <kbabbitt> iank_: for non replaced elements, while computing the initial block size, min-content, max-content etc. are considered indefinite<br> <kbabbitt> ... for replaced, maybe that's the nextissue for how that works<br> <kbabbitt> ... does that satisfy what you wanted to get out of this oriol?<br> <kbabbitt> oriol: yes<br> <kbabbitt> iank_: other way we could resolve this is work out spec text which reflects the intent of blink's behavior<br> <kbabbitt> oriol: not sure if I agree that's the next issue but fine with this overall<br> <kbabbitt> ... trying to follow Blink<br> <kbabbitt> Rossen: min-content and max-content are considered indefinite for non-replaced items?<br> <kbabbitt> iank_: ... while computing the initial block size<br> <kbabbitt> ... how it was minuted<br> <kbabbitt> RESOLVED: for non replaced elements, while computing the initial block size, min-content, max-content etc. are considered indefinite<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12333#issuecomment-4172359175 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 April 2026 19:06:11 UTC