For completeness, Firefox behavior looks like to take the width of the last containing block that has a definite width (or the viewport). Looks like Edge and Chrome cap the object default width at that, but do not go higher. Might need more tests.

https://jsfiddle.net/2y31ru8u/1/

I don't remember all the details, but I looked into similar questions of that when defining box-sizing and writing tests for it. If you're planing on writing tests on this topic, it could be worth looking at these for inspiration.

It seems like Firefox's behavior is the most author-friendly. If @dbaron can explain how it works and convince everyone to follow, Tab and I think that would be the best course of action.

The Firefox behavior is fundamentally broken and shouldn't be copied.

But it's possible that using an infinite max-content width will do what you want. But also see #1046.

Infinite max-content width seems a bit problematic to render if someone explicitly requests it. :) But how about using the nearest scrollport width? That will nearly always be larger than the containing block width when you're doing shrink-to-fit, so will behave the same as infinity, but if you request it explicitly it'll still be a reasonable size. (This is also consistent with how we handle orthogonal flows when we need a size but don't have one.)

Intrinsic size computation can cross scrollports, so I don't think that works. The size of the scrollport might be a function of the intrinsic size of one of its ancestors, which was influenced by content inside the scrollport.

Good point. We need to resolve on something definite for #1391 regardless, though, so once we figure that out we could use the same solution here.

Possible solutions that have been suggested

• Use the ICB size (problem is with nested scroll containers, this isn't helpful)
• From nearest fixed size container, subtract out margin/border/padding of intervening elements (dbaron's stretch-fit algo). Problem is this might give us way too little space in a deeply nested context that reaches out to the viewport.
• Use the nearest container with a fixed size (problem is that this isn't particularly related to how much content can be seen, might be significantly more or less)
• Use the nearest scroll container with a fixed size (nice because nearest scrollport determines how much content can be seen, so good for UX)

I'm thinking nearest fixed-size scrollport is the best option (for this and the WM issue linked above).

After the call today, I started building test cases to see what browsers are currently doing. The good news is that it's one big hot mess, so there is no clear cow-path to pave & we can decide on something sensible instead.

Test cases with the results of testing on latest stable browsers

Coming back to this & summing up my thoughts (some of which are also in the conclusions section of the linked test pen):

The issue with percentage sizing in a shrink-wrapped container isn't really SVG or aspect-ratio specific: I've tested it with other types of elements (e.g., <button>, <div>), and still get cross-browser inconsistencies. So maybe that can be a separate issue and we can focus here on the "simpler" case of auto-sizing and aspect ratio.

Similarly, I think the issues of how borders and padding interact with sizing should be separate (and can probably be just called browser bugs. A nasty infestation of large quantities of browser bugs).

So, on the subject of this issue:

There are three auto-size behaviors seen in the tests:

• Scalable contents in a shrink-wrapped container shrink away to nothing. I'm going to strongly argue that this is not a good default behavior, ever. It could maybe make sense for min-content-size, I guess. But it shouldn't be auto behavior. It is especially nonsensical in that Chrome and Safari only apply this behavior to elements with an intrinsic aspect ratio; elements with no dimensions at all are saved by the default object size. Images with 100% inline-size (like @FremyCompany's initial fiddle) also get the default size in the inline direction in those browsers.

• When there are scalable contents in a shrink-wrapped container, the container switches to extrinsic sizing, taking up its full block width (stretch fit), and then the contents fit to their container. This is sub-optimal, but better; I would be OK with this approach. This is somewhat like the Firefox behavior, but minus the Firefox bugs. Presumably you would do this recursively until you hit a container that did have a definite size (and/or, the viewport). So there could be performance impacts, especially because you might trigger a scroll bar that then changes the stretch-fit width and forces a recalc.

• Scalable contents in a shrink-wrapped container are given the default object size. If they have an intrinsic aspect ratio, they get the default size in the inline direction and then have the block direction determined by aspect ratio. Not ideal, but I think the best of the lot. This is mostly the MS Edge behavior (minus the bugs related to borders and such). Yes, it's arbitrary, but it's consistent. It provides a reasonable size for floated and inline-block elements, and it provides consistent basis sizes for flexbox, grid, and tables. You get to see something on screen, from which you can realize "oh, I should probably specify a size on that element".

The CSS Working Group just discussed Intrinsic Sizing of No Intrinsic Size Images, and agreed to the following resolutions:

• RESOLVED: Replaced elements with only an intrinsic aspect ratio has a min-content size of 0 and a max-content size of 300px wide and 300*aspect-ratio height.
• RESOLVED: In vertical WM, replaced elements with only an intrinsic aspect ratio use a 150px height and 150*aspect ratio width, instead.