[css-sizing] Intrinsic size of <img> / <video> with aspect ratio but no definite size

[emilio]

Consider this test-case from Mozilla bug 1905511.

In it, you can see how, while loading an image, Firefox treats it as having no intrinsic size (like the SVG). This is consistent with how we want to treat videos (for the use-case in https://github.com/w3c/csswg-drafts/issues/7524 to work, which works now in Firefox and WebKit).

However that's not what Blink does, and people get a bit confused (because the image might grow too much). It seems WebKit does something weird where it doesn't stretch images with no intrinsic size but a ratio (like the SVG in the test-case).

Blink seems to just give the image a 0x0 size while loading, which is slightly unfortunate, but maybe fine. I could live with that inconsistency between <img> and <video> I guess. The issue with <video> is really the default object size.

Questions:

• What of the two <img> behaviors do we want? Both seem acceptable to me, but let's be interoperable? :)
  • <img> has 0x0 intrinsic size (doesn't respect aspect-ratio if no dimension is definite, Blink's behavior)
  • <img> has no intrinsic size (might grow too much, Firefox's behavior).
• Is there some interest in Blink for fixing the <video> situation in #7524? (test here). Chromium filed it so I was hoping they'd get to it sooner rather than later.
• (Bonus) What is WebKit doing?

Want to run it through the group before going with Blink's behavior, in case people have strong opinions...

cc: @fantasai @jensimmons @bfgeek @chrishtr

[jensimmons]

I don't understand the question from this level of explanation. Can you provide more context?

[emilio]

So, consider a <video>. If you just set <video width=100 height=100> that maps to width: 100px; height: 100px; aspect-ratio: auto 100 / 100;, so far so good. But if you override the width / height with CSS (setting them to e.g. auto, because let's say you're using it in a flex container or something else), that'd fall back to 300x150 (rather than what you'd expect which is stretching or what not). So in #7524 I made <video> not report an intrinsic size if it had an aspect-ratio, effectively.

For <img>, you have the same issue, it's just that the fallback size is 0x0. Firefox treats it the same way as <video>, but Blink doesn't, and WebKit is doing something very weird too, which means that we get bug reports :)

Falling back to 0x0 is not so terrible as 300x150, so I think I'd be ok with such thing (even if a bit unfortunate / inconsistent). The main question is whether we go with the 0x0 (and I change Firefox and add a test), or with the no size behavior (and I close the bug as invalid and add a test).

cc @jakearchibald too (since he filed #7524), and @Loirooriol since he was involved on some of those discussions.

[bfgeek]

I think I could get behind a 0x0 while loading in both cases. No intrinsic size (SVG-like) is dangerous as can be quite large in the degenerate case (similar argument against the default 300x150).

[emilio]

@bfgeek 0x0 probably doesn't quite work for <video> tho, because of the common case described in the original issue of having an un-loaded video that you load on interaction or so.