search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.52k stars 673 forks source link

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

Open emilio opened 4 months ago

emilio commented 4 months ago

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:

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 commented 4 months ago

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

emilio commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

@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.

Loirooriol commented 2 weeks ago

So if I get it right, this is about

<!DOCTYPE html>
<style>video, img { width: auto; height: auto; aspect-ratio: 1; border: solid; background: cyan }</style>
<div style="width: 200px">
  <video width="100" height="100"></video>
  <img width="100" height=100 src="https://software.hixie.ch/utilities/cgi/test-tools/delayed-file?pause=60">
</div>

In Servo we currently match Blink: the video is 300x150, and the image is 0x0 (but unlike Blink, we pass the video test).

The difference is because we let image elements with no resource fall back to a 0x0 natural size. The video gets no natural size, so it uses a default object size of 300x150.