Utilizing Aspect-Ratio with Art Direction (Multiple Sources with various Aspect Ratios known)

[AndresInSpace]

Problem:
Implementing aspect ratios during the first layout calculation for when various aspect ratios are utilized, such as with art direction.
Avoid any extra layout calculation's after initial layout. (avoiding page jumps!)
Avoid writing any CSS for the aspect ratio.
Avoid needing custom JS to do any of this.

Use Case:
Using multiple <source> 's within <picture> or <video>

Requirements:
Aspect-ratio MUST be known for each source.
(ideally it should match the intrinsic ratio of source asset, otherwise when the asset loads the intrinsic ratio changes and may cause layout recalc? which we want to avoid!)
New attributes(s) for <source>:width="1600" height="900" (16/9 ratio)
Both width and height of the source must be supplied for a ratio to be calculated.
e.g. <source srcset="https://via.placeholder.com/600x279" media="(max-width: 599px)" width="600" height="279">

My thoughts on implementation for <picture>
Either the <img> inside <picture> or the <picture> element itself will have the aspect ratio applied to it.

<picture>
  <source srcset="https://via.placeholder.com/600x279" media="(max-width: 599px)" width="600" height="279">
  <source srcset="https://via.placeholder.com/1500x300" media="(max-width: 991px)" width="1500" height="300">
  <img src="https://via.placeholder.com/1500x300" width="1500" height="300">
</picture>

[yoavweiss]

As I suggested on WICG/intrinsicsize-attribute#16 (comment), I think we can update the update the image data algorithm to pick the aspect ratio from the selected source.

For consistency, it seems like it would be better to add width and height attributes.

[AndresInSpace]

@yoavweiss
I agree on utilizing width="" height="" instead of ratio="" for consistency.
I will update my post to reflect this.

One question regarding changing the algorithm of update the image data:
Would this cause a re-calc of layout or would this pick the proper source before the first layout calc? I am unsure of the order of things here.

[jensimmons]

I agree that the best solution is to have Authors put width and height attributes on each source inside <picture> (and video and anyplace else source is used for visual media) — and have the browser act as if the width and height attributes are being swapped into the <img> element in exactly the same way the src attribute is swapped.

I would not apply this to the picture element. (Which reminds me @fantasai and @emilio of that conversation we had when we discovered all the CSS being applied to picture that should be removed... that picture should have display: contents applied instead — we should find & file that issue).

@AndresInSpace This should apply to the first layout calculation. In the moment when the browser decides which image to use, it should grab the width & height data, and use it in the first paint. Skipping over any other ideas of what layout should be. Once the height & width data is transferred to img, along with src — everything else should happen just as if the IMG only had one URL, one height, one width, and there were no other sources.

[zcorpan]

(and video and anyplace else source is used for visual media)

Nope, video doesn't do art direction. #4544

[AndresInSpace]

@jensimmons Perfect.
@zcorpan I think the arguments for it carries more weight than the argument against it. I've posted my thoughts over in #4544

[Crissov]

Does this also handle image formats like HEIF which, as far as I understand, can have multiple pictures inside that do not need to have all the same dimensions and ratios (though usually do)?

[patricknelson]

For reference, this is now documented at (via PR #5894):
https://html.spec.whatwg.org/multipage/embedded-content.html#the-source-element

Thank you for adding this to the spec! 🎉

[cbiesinger]

It will also ship in Chrome 90! I believe Firefox is also working on it, don't know about their schedule.

[hecktarzuli]

This is in Safari 15

[hecktarzuli]

For those looking for FF support, this seems to be the Firefox tracking for this: https://bugzilla.mozilla.org/show_bug.cgi?id=1694741

[y-commit69]

For those looking for FF support, this seems to be the Firefox tracking for this: https://bugzilla.mozilla.org/show_bug.cgi?id=1694741

This has landed on Firefox 108 Developer Edition