- From: jjordanca via GitHub <sysbot+gh@w3.org>
- Date: Sun, 27 Sep 2020 12:26:52 +0000
- To: public-css-archive@w3.org
I believe in the example it's actually rendering as 100x0, not 0 x 0 (at least in my version of the browser): https://jsfiddle.net/fh6b17vp/ It could be that the UA is: 1. generating the containing box (principal box) from the IMG element (https://www.w3.org/TR/css-display-3/#atomic-inline), (300 x 100) 2. then giving it a width and height of 0 due to not having any contents (https://drafts.csswg.org/css-contain/#containment-size), (0x0) 3. then applying the aspect ratio as an "effective aspect ratio" to the box and replaced image (this terminology is not defined in the Editor's Draft), doing nothing ((https://drafts.csswg.org/css-sizing-4/#ratios),) (0x0) 4. then applying the specified width to the size-contained box (100x0) 5. then filling that box with an ill-defined image (100x?) But who knows what's really going on behind-the-scenes there for each implementation? I'm not sure that the order of operations is well-defined for how the Containment Module applies itself yet... Also, I noticed on my version of Chromium that this still leaves a 1px tall interior to the box whereas there should have probably been nothing, whereas Firefox collapses the borders completely. Chromium also seems to apply this padding around the image, not just the resized box. However, https://drafts.csswg.org/css-images-3/#concrete-size-resolution says "CSS does not define how objects render when the concrete object size is different from the object’s intrinsic dimensions." and the Containment Module explicitly states that the layout for "Replaced elements must be treated as having an intrinsic width and height of 0." as @aethanyc mentioned. If concrete object size for the image has already been calculated prior to the object's intrinsic dimensions being treated as zero, the rendering of the image could end up being undefined by CSS, which could explain why Chromium has a gap and Firefox does not. https://drafts.csswg.org/css-contain/#containment-size also says "When calculating the size of the containing box, including when computing its intrinsic size, it must be treated as having no contents." and then it says "Then, its contents must then be laid out into the containing box's resolved size." What exactly is the "resolved size" here? I feel like this should be better defined, possibly including more information on how to handle replaced elements who end up getting replaced into their own box. -- GitHub Notification of comment by jjordanca Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5550#issuecomment-699628897 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 27 September 2020 12:26:54 UTC