Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
emilio opened this issue Jul 21, 2024 · 5 comments
Open

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

emilio opened this issue Jul 21, 2024 · 5 comments
Labels
Agenda+ css-sizing-3 Current Work

Comments

@emilio
Copy link
Collaborator

emilio commented Jul 21, 2024

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 #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 [css-sizing-4] aspect-ratio via width and height attributes doesn't work for <video> #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
Copy link
Contributor

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

@emilio
Copy link
Collaborator Author

emilio commented Jul 21, 2024

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
Copy link

bfgeek commented Jul 23, 2024

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
Copy link
Collaborator Author

emilio commented Jul 23, 2024

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

@astearns astearns moved this to TPAC/FTF agenda items in CSSWG Agenda TPAC 2024 Sep 13, 2024
@astearns astearns moved this from TPAC/FTF agenda items to Regular agenda items in CSSWG Agenda TPAC 2024 Sep 13, 2024
@Loirooriol Loirooriol mentioned this issue Oct 31, 2024
Merged
@Loirooriol
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Agenda+ css-sizing-3 Current Work
Projects
CSSWG Agenda TPAC 2024
Status: Regular agenda items
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jensimmons @bfgeek @emilio @Loirooriol