Intent to Ship: Compute img/video aspect ratio from width and height HTML attributes

404 views
Skip to first unread message

Christian Biesinger

unread,
Oct 2, 2019, 6:18:51 PM10/2/19
to blink-dev
cbies...@chromium.org,chri...@chromium.org https://github.com/WICG/intrinsicsize-attribute/issues/16#issuecomment-500941775 https://github.com/WICG/intrinsicsize-attribute/issues/16 No TAG review -- this is a pretty simple addition to image loading, which is basically just a performance optimization. Computes the aspect ratio of an image using the HTML width and height attributes so that it can be used for sizing the image using CSS before the image loads. https://groups.google.com/a/chromium.org/d/topic/blink-dev/hbhKRuBzZ4o/discussion
Compatibility: The only case where content will render differently is if an author specifies width/height attributes that do not match the actual aspect ratio of the image *and* has CSS that specifies one of width/height and explicitly sets the other dimension to "auto". This seems extremely unlikely. Interoperability: This is just a performance optimization; should this not gain traction with enough other browsers, it is easy to unship this. There are also WPT tests for this already and Firefox is shipping this. This was also discussed in the CSSWG. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=1547231) Now turned on by default Edge: No public signals Safari: No public signals Web developers: No signals n/a Adding width/height attributes to an image is straightforward. n/a
n/a, just a performance optimization Yes Yes https://wpt.fyi/results/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/img-aspect-ratio.tentative.html?label=experimental&label=master&aligned (The Chrome version used by wpt is too old to show us passing) https://bugs.chromium.org/p/chromium/issues/detail?id=979891 https://chromestatus.com/feature/5695266130755584
This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Oct 3, 2019, 2:57:03 PM10/3/19
to Christian Biesinger, blink-dev
The solution we went with unfortunately ignored the art direction use-case.
I *think* this can be shipped incrementally, but seems like we need to make sure that this is the case.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XE5ce9O0cyLfbB1r6P6LAf3X7mNtWd1T-ht1HQBf%3Dg7QA%40mail.gmail.com.

Daniel Bratell

unread,
Oct 3, 2019, 2:57:11 PM10/3/19
to Christian Biesinger, blink-dev

LGTM1

/Daniel

Ojan Vafai

unread,
Oct 3, 2019, 5:51:25 PM10/3/19
to Daniel Bratell, Christian Biesinger, blink-dev
I'm supportive of changing this, but it'd be nice if we had a more clear description of what the behavior we are shipping is. That issue has a lot of different things in it, e.g. things involved the aspect-ratio CSS property. It seems like it would be hard to point web developers at that and have them have a clear understanding of what we shipped. Maybe we should do a final post o that issue with a more succinct description of what we're shipping? Or create a new issue?

Also, is image/video size rendering specified anywhere? We probably want a diff to a spec?

Firefox hasn't actually shipped this to stable yet, right? The bug makes it sound like there's more that needs doing first.

Lastly, this doesn't seem like a pure performance optimization to me. It changes behavior, no? This seems like it would be as hard as anything else to unship once sites start depending on it to me. I think it's still a pretty safe change to try, but the text in the interoperability section maybe should be tweaked.

Daniel Bratell wrote:
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9eab62f2-38c4-e963-2a42-e51659bcb3a8%40gmail.com.

Christian Biesinger

unread,
Oct 3, 2019, 6:30:44 PM10/3/19
to Ojan Vafai, Daniel Bratell, blink-dev
Well, it only changes behavior while the image is loading. Once loaded, the behavior is the same as the old one.

I apologize for not updating the spec link. See the last part of https://html.spec.whatwg.org/multipage/rendering.html#attributes-for-embedded-content-and-images (or the diff at https://github.com/whatwg/html/pull/4952/files). That's what we implement.

It is true that Firefox hasn't shipped a stable release with the change yet but they did turn it on by default for release: https://bugzilla.mozilla.org/show_bug.cgi?id=1585637

Yoav's comment is now filed at https://github.com/whatwg/html/issues/4968
Expanding to other tags is at https://github.com/whatwg/html/issues/4961

Christian

jaffat...@gmail.com

unread,
Oct 7, 2019, 11:05:21 AM10/7/19
to blink-dev, oj...@chromium.org, brat...@gmail.com
Web developer signal here is "strong support". However, I agree it's confusing that the proposal was for a default UA style applying to the aspect-ratio property, and the spec seems to be something different.


On Thursday, 3 October 2019 23:30:44 UTC+1, Christian Biesinger wrote:
Well, it only changes behavior while the image is loading. Once loaded, the behavior is the same as the old one.

I apologize for not updating the spec link. See the last part of https://html.spec.whatwg.org/multipage/rendering.html#attributes-for-embedded-content-and-images (or the diff at https://github.com/whatwg/html/pull/4952/files). That's what we implement.

It is true that Firefox hasn't shipped a stable release with the change yet but they did turn it on by default for release: https://bugzilla.mozilla.org/show_bug.cgi?id=1585637

Yoav's comment is now filed at https://github.com/whatwg/html/issues/4968
Expanding to other tags is at https://github.com/whatwg/html/issues/4961

Christian

On Thu, Oct 3, 2019 at 4:51 PM Ojan Vafai <oj...@chromium.org> wrote:
I'm supportive of changing this, but it'd be nice if we had a more clear description of what the behavior we are shipping is. That issue has a lot of different things in it, e.g. things involved the aspect-ratio CSS property. It seems like it would be hard to point web developers at that and have them have a clear understanding of what we shipped. Maybe we should do a final post o that issue with a more succinct description of what we're shipping? Or create a new issue?

Also, is image/video size rendering specified anywhere? We probably want a diff to a spec?

Firefox hasn't actually shipped this to stable yet, right? The bug makes it sound like there's more that needs doing first.

Lastly, this doesn't seem like a pure performance optimization to me. It changes behavior, no? This seems like it would be as hard as anything else to unship once sites start depending on it to me. I think it's still a pretty safe change to try, but the text in the interoperability section maybe should be tweaked.

Daniel Bratell wrote:

LGTM1

/Daniel

On 2019-10-03 00:18, Christian Biesinger wrote:
cbies...@chromium.org,chrisht...@chromium.org https://github.com/WICG/intrinsicsize-attribute/issues/16#issuecomment-500941775 https://github.com/WICG/intrinsicsize-attribute/issues/16 No TAG review -- this is a pretty simple addition to image loading, which is basically just a performance optimization. Computes the aspect ratio of an image using the HTML width and height attributes so that it can be used for sizing the image using CSS before the image loads. https://groups.google.com/a/chromium.org/d/topic/blink-dev/hbhKRuBzZ4o/discussion
Compatibility: The only case where content will render differently is if an author specifies width/height attributes that do not match the actual aspect ratio of the image *and* has CSS that specifies one of width/height and explicitly sets the other dimension to "auto". This seems extremely unlikely. Interoperability: This is just a performance optimization; should this not gain traction with enough other browsers, it is easy to unship this. There are also WPT tests for this already and Firefox is shipping this. This was also discussed in the CSSWG. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=1547231) Now turned on by default Edge: No public signals Safari: No public signals Web developers: No signals n/a Adding width/height attributes to an image is straightforward. n/a
n/a, just a performance optimization Yes Yes https://wpt.fyi/results/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/img-aspect-ratio.tentative.html?label=experimental&label=master&aligned (The Chrome version used by wpt is too old to show us passing) https://bugs.chromium.org/p/chromium/issues/detail?id=979891 https://chromestatus.com/feature/5695266130755584
This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Alex Russell

unread,
Oct 10, 2019, 3:31:08 PM10/10/19
to blink-dev, oj...@chromium.org, brat...@gmail.com
LGTM2


On Monday, October 7, 2019 at 8:05:21 AM UTC-7, Jake Archibald wrote:
Web developer signal here is "strong support". However, I agree it's confusing that the proposal was for a default UA style applying to the aspect-ratio property, and the spec seems to be something different.

On Thursday, 3 October 2019 23:30:44 UTC+1, Christian Biesinger wrote:
Well, it only changes behavior while the image is loading. Once loaded, the behavior is the same as the old one.

I apologize for not updating the spec link. See the last part of https://html.spec.whatwg.org/multipage/rendering.html#attributes-for-embedded-content-and-images (or the diff at https://github.com/whatwg/html/pull/4952/files). That's what we implement.

It is true that Firefox hasn't shipped a stable release with the change yet but they did turn it on by default for release: https://bugzilla.mozilla.org/show_bug.cgi?id=1585637

Yoav's comment is now filed at https://github.com/whatwg/html/issues/4968
Expanding to other tags is at https://github.com/whatwg/html/issues/4961

Christian

On Thu, Oct 3, 2019 at 4:51 PM Ojan Vafai <oj...@chromium.org> wrote:
I'm supportive of changing this, but it'd be nice if we had a more clear description of what the behavior we are shipping is. That issue has a lot of different things in it, e.g. things involved the aspect-ratio CSS property. It seems like it would be hard to point web developers at that and have them have a clear understanding of what we shipped. Maybe we should do a final post o that issue with a more succinct description of what we're shipping? Or create a new issue?

Also, is image/video size rendering specified anywhere? We probably want a diff to a spec?

Firefox hasn't actually shipped this to stable yet, right? The bug makes it sound like there's more that needs doing first.

Lastly, this doesn't seem like a pure performance optimization to me. It changes behavior, no? This seems like it would be as hard as anything else to unship once sites start depending on it to me. I think it's still a pretty safe change to try, but the text in the interoperability section maybe should be tweaked.

Daniel Bratell wrote:

LGTM1

/Daniel

On 2019-10-03 00:18, Christian Biesinger wrote:
cbies...@chromium.org,chrishtr@chromium.org https://github.com/WICG/intrinsicsize-attribute/issues/16#issuecomment-500941775 https://github.com/WICG/intrinsicsize-attribute/issues/16 No TAG review -- this is a pretty simple addition to image loading, which is basically just a performance optimization. Computes the aspect ratio of an image using the HTML width and height attributes so that it can be used for sizing the image using CSS before the image loads. https://groups.google.com/a/chromium.org/d/topic/blink-dev/hbhKRuBzZ4o/discussion
Compatibility: The only case where content will render differently is if an author specifies width/height attributes that do not match the actual aspect ratio of the image *and* has CSS that specifies one of width/height and explicitly sets the other dimension to "auto". This seems extremely unlikely. Interoperability: This is just a performance optimization; should this not gain traction with enough other browsers, it is easy to unship this. There are also WPT tests for this already and Firefox is shipping this. This was also discussed in the CSSWG. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=1547231) Now turned on by default Edge: No public signals Safari: No public signals Web developers: No signals n/a Adding width/height attributes to an image is straightforward. n/a
n/a, just a performance optimization Yes Yes https://wpt.fyi/results/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/img-aspect-ratio.tentative.html?label=experimental&label=master&aligned (The Chrome version used by wpt is too old to show us passing) https://bugs.chromium.org/p/chromium/issues/detail?id=979891 https://chromestatus.com/feature/5695266130755584
This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XE5ce9O0cyLfbB1r6P6LAf3X7mNtWd1T-ht1HQBf%3Dg7QA%40mail.gmail.com.

Yoav Weiss

unread,
Oct 10, 2019, 3:35:45 PM10/10/19
to Alex Russell, blink-dev, Ojan Vafai, Daniel Bratell
LGTM3

We'd definitely need to address the art-direction case, but it seems like we can do that separately from shipping this change.

On Thu, Oct 10, 2019 at 9:31 PM 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:
LGTM2

On Monday, October 7, 2019 at 8:05:21 AM UTC-7, Jake Archibald wrote:
Web developer signal here is "strong support". However, I agree it's confusing that the proposal was for a default UA style applying to the aspect-ratio property, and the spec seems to be something different.

On Thursday, 3 October 2019 23:30:44 UTC+1, Christian Biesinger wrote:
Well, it only changes behavior while the image is loading. Once loaded, the behavior is the same as the old one.

I apologize for not updating the spec link. See the last part of https://html.spec.whatwg.org/multipage/rendering.html#attributes-for-embedded-content-and-images (or the diff at https://github.com/whatwg/html/pull/4952/files). That's what we implement.

It is true that Firefox hasn't shipped a stable release with the change yet but they did turn it on by default for release: https://bugzilla.mozilla.org/show_bug.cgi?id=1585637

Yoav's comment is now filed at https://github.com/whatwg/html/issues/4968
Expanding to other tags is at https://github.com/whatwg/html/issues/4961

Christian

On Thu, Oct 3, 2019 at 4:51 PM Ojan Vafai <oj...@chromium.org> wrote:
I'm supportive of changing this, but it'd be nice if we had a more clear description of what the behavior we are shipping is. That issue has a lot of different things in it, e.g. things involved the aspect-ratio CSS property. It seems like it would be hard to point web developers at that and have them have a clear understanding of what we shipped. Maybe we should do a final post o that issue with a more succinct description of what we're shipping? Or create a new issue?

Also, is image/video size rendering specified anywhere? We probably want a diff to a spec?

Firefox hasn't actually shipped this to stable yet, right? The bug makes it sound like there's more that needs doing first.

Lastly, this doesn't seem like a pure performance optimization to me. It changes behavior, no? This seems like it would be as hard as anything else to unship once sites start depending on it to me. I think it's still a pretty safe change to try, but the text in the interoperability section maybe should be tweaked.

Daniel Bratell wrote:

LGTM1

/Daniel

On 2019-10-03 00:18, Christian Biesinger wrote:
cbies...@chromium.org,chri...@chromium.org https://github.com/WICG/intrinsicsize-attribute/issues/16#issuecomment-500941775 https://github.com/WICG/intrinsicsize-attribute/issues/16 No TAG review -- this is a pretty simple addition to image loading, which is basically just a performance optimization. Computes the aspect ratio of an image using the HTML width and height attributes so that it can be used for sizing the image using CSS before the image loads. https://groups.google.com/a/chromium.org/d/topic/blink-dev/hbhKRuBzZ4o/discussion
Compatibility: The only case where content will render differently is if an author specifies width/height attributes that do not match the actual aspect ratio of the image *and* has CSS that specifies one of width/height and explicitly sets the other dimension to "auto". This seems extremely unlikely. Interoperability: This is just a performance optimization; should this not gain traction with enough other browsers, it is easy to unship this. There are also WPT tests for this already and Firefox is shipping this. This was also discussed in the CSSWG. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=1547231) Now turned on by default Edge: No public signals Safari: No public signals Web developers: No signals n/a Adding width/height attributes to an image is straightforward. n/a
n/a, just a performance optimization Yes Yes https://wpt.fyi/results/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/img-aspect-ratio.tentative.html?label=experimental&label=master&aligned (The Chrome version used by wpt is too old to show us passing) https://bugs.chromium.org/p/chromium/issues/detail?id=979891 https://chromestatus.com/feature/5695266130755584
This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XE5ce9O0cyLfbB1r6P6LAf3X7mNtWd1T-ht1HQBf%3Dg7QA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9eab62f2-38c4-e963-2a42-e51659bcb3a8%40gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/20e69444-b2bd-4b44-98bc-2ec892cd6d49%40chromium.org.

Christian Biesinger

unread,
Oct 17, 2019, 8:50:11 AM10/17/19
to Yoav Weiss, Alex Russell, blink-dev, Ojan Vafai, Daniel Bratell
Thanks; this is now enabled by default on trunk.

Christian

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiZCcyJapm0dYN2t7WY-_wqG6tUWLMK%2BBRdvgTPvR6wiw%40mail.gmail.com.

Christian Biesinger

unread,
Oct 17, 2019, 8:50:11 AM10/17/19
to Yoav Weiss, Alex Russell, blink-dev, Ojan Vafai, Daniel Bratell
Thanks all; this is now enabled by default on trunk

Christian

On Thu, Oct 10, 2019, 21:35 Yoav Weiss <yo...@yoav.ws> wrote:
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiZCcyJapm0dYN2t7WY-_wqG6tUWLMK%2BBRdvgTPvR6wiw%40mail.gmail.com.

ba...@tunetheweb.com

unread,
Jan 27, 2020, 12:18:10 PM1/27/20
to blink-dev, yo...@yoav.ws, sligh...@google.com, oj...@chromium.org, brat...@gmail.com
FYI, I think I've found a bug in that it doesn't work when using native lazy loading. Details here: https://bugs.chromium.org/p/chromium/issues/detail?id=1045745

Thomas Steiner

unread,
Jan 31, 2020, 7:36:33 AM1/31/20
to blink-dev, ba...@tunetheweb.com, yo...@yoav.ws, Alex Russell, Ojan Vafai, Daniel Bratell, Mathias Bynens
Did you consider to broaden this proposal to also be applied to iframe? This would allow for responsive iframe embeds without having to specify the (future) aspect-ratio CSS property specifically. Essentially, the example from the CSS Box Sizing Module Level 4 spec…

iframe {
    aspect-ratio: attr(width) / attr(height);
    max-width: 100%;
    height: auto;
}

…could be simplified to just… 

iframe {
    max-width: 100%;
    height: auto;
}

…which would be super useful for YouTube video embeds and an advancement over the current hacks people have to use.

Jake Archibald

unread,
Jan 31, 2020, 8:10:02 AM1/31/20
to Thomas Steiner, blink-dev, ba...@tunetheweb.com, yo...@yoav.ws, Alex Russell, Ojan Vafai, Daniel Bratell, Mathias Bynens
I don't think iframes have an intrinsic aspect ratio. For instance, when you set the width/height of an iframe via CSS, it doesn't stretch to fit those dimensions, it lays the page out at that size.

To achieve what you want, you'd need a system where the iframe got its layout width/height from its attributes, and its render width/height from CSS. Then, it could have an intrinsic aspect ratio from the attributes. However, I'm pretty sure that wouldn't be a backwards-compatible change.

Fwiw, I've been wondering if <portal> should work this way https://github.com/WICG/portals/issues/173.

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/GePU9T8UpEc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/89ef5263-fd63-46b7-bfb5-628aed7aa280%40chromium.org.

Thomas Steiner

unread,
Jan 31, 2020, 8:53:19 AM1/31/20
to Jake Archibald, blink-dev, ba...@tunetheweb.com, yo...@yoav.ws, Alex Russell, Ojan Vafai, Daniel Bratell, Mathias Bynens
I don't think iframes have an intrinsic aspect ratio. For instance, when you set the width/height of an iframe via CSS, it doesn't stretch to fit those dimensions, it lays the page out at that size.

Good catch. I missed it because YouTube runs some code to reflect the iframe width/height attributes on the video element, so shows the behavior we don't have in the general case.
 
To achieve what you want, you'd need a system where the iframe got its layout width/height from its attributes, and its render width/height from CSS. Then, it could have an intrinsic aspect ratio from the attributes. However, I'm pretty sure that wouldn't be a backwards-compatible change.

Yeah, definitely not backward-compatible. :-(
 
Fwiw, I've been wondering if <portal> should work this way https://github.com/WICG/portals/issues/173.

FWIW, I thumbed up the proposal.
Screen Shot 2020-01-31 at 14.49.39.png

Christian Biesinger

unread,
Feb 4, 2021, 12:29:03 PM2/4/21
to blink-dev
I would like to extend this also to <picture> by mapping a <source>
element's width/height to the style in the <img> as described in
https://github.com/whatwg/html/pull/5894. Do I need another
intent-to-ship thread for that?

I created a chromestatus entry at
https://chromestatus.com/feature/5737185317748736

Thanks,
Christian

On Thu, Oct 3, 2019 at 12:18 AM Christian Biesinger
<cbies...@chromium.org> wrote:
>

Manuel Rego Casasnovas

unread,
Feb 12, 2021, 4:06:42 PM2/12/21
to Christian Biesinger, blink-dev
Hi Christian,

On 04/02/2021 18:28, Christian Biesinger wrote:
> I would like to extend this also to <picture> by mapping a <source>
> element's width/height to the style in the <img> as described in
> https://github.com/whatwg/html/pull/5894. Do I need another
> intent-to-ship thread for that?
>
> I created a chromestatus entry at
> https://chromestatus.com/feature/5737185317748736

If this has a new Chromestatus entry I believe it's simpler to follow
the standard process and send an intent-to-ship. That would make
external people easier to follow the process.

We could use the intent thread as an opportunity to clarify the position
from other browsers, at least it's not totally clear the position in the
PR for HTML spec.

Regarding TAG review I think it's enough with the comment in the ongoing
review for aspect-ratio:
https://github.com/w3ctag/design-reviews/issues/559

Bye,
Rego
Reply all
Reply to author
Forward
0 new messages