- From: Oriol Brufau via GitHub <sysbot+gh@w3.org>
- Date: Mon, 26 Jul 2021 15:54:44 +0000
- To: public-css-archive@w3.org
> this currently isn't how these expressions resolve in implementations It seems implementations just compress the entire intrinsic contribution 0 instead of only resolving the percentage to 0. But that seems orthogonal to this issue, I guess whatever implementations are doing for compressible elements outside grid can also be done in when sizing the grid tracks. BTW, Firefox behaves like Chromium when using `aspect-ratio` in a non-replaced element. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/9515 ```html <div style="display: inline-grid; grid-template: 1fr / 1fr; width: 200px; height: 100px; border: thick solid;"> <div style="aspect-ratio: 1 / 1; background: cyan; width:100%; height: 100%; opacity: .9;"></div> </div> <div style="display: inline-grid; grid-template: minmax(min-content, 1fr) / minmax(min-content, 1fr); width: 200px; height: 100px; border: thick solid;"> <div style="aspect-ratio: 1 / 1; background: cyan; width:100%; height: 100%; min-width: 0; min-height: 0; opacity: .9;"></div> </div> ``` When using `calc(500px + 100%)` then both Firefox and Chrome produce a grid cell 200px wide and 700px tall, so seemingly `calc(500px + 100%)` just resolved to 0 for the intrinsic inline size, but then in the block size the percentage is resolved against the 200px width, this is added to the 500px, and the result is converted thru the aspect ratio. Strange. -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6278#issuecomment-886823315 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 26 July 2021 15:54:46 UTC