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

[Christian Biesinger]

Contact emails cbies...@chromium.org,chri...@chromium.org Explainer https://github.com/WICG/intrinsicsize-attribute/issues/16#issuecomment-500941775 Design docs/spec Specification: https://github.com/WICG/intrinsicsize-attribute/issues/16 TAG review No TAG review -- this is a pretty simple addition to image loading, which is basically just a performance optimization. Summary 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. Motivation In order to correctly compute the final dimensions of an image (before it is fully loaded), this feature computes the aspect ratio from the HTML width and height attributes, so that it can be used to compute the final size when e.g. "width: 100%; height: auto;" is used in CSS. This avoids unnecessary relayouts when the image loads (compared to <img src="foo.jpg" style="width: 100%">) Risks

Interoperability and Compatibility 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 (by Mozilla) and Firefox is shipping this. This was also discussed in the CSSWG. Firefox: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=1547231) Edge: No public signals Safari: No public signals Web developers: No signals Ergonomics n/a Activation Adding width/height attributes to an image is straightforward. Security n/a

Debuggability n/a, just a performance optimization Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes WPT tests were added: https://github.com/WICG/intrinsicsize-attribute/issues/16#issuecomment-521588326 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5695266130755584

This intent message was generated by Chrome Platform Status.

[Craig Francis]

As a web developer, I’m *really* looking forward to this.

[Boris Zbarsky]

On 9/5/19 6:27 PM, Christian Biesinger wrote:
> 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.

Note that when Firefox initially added this feature, we got several bug
reports:

https://bugzilla.mozilla.org/show_bug.cgi?id=1565607 -- real site broken

https://bugzilla.mozilla.org/show_bug.cgi?id=1565598 -- another real
site broken

https://bugzilla.mozilla.org/show_bug.cgi?id=1564069 -- this one
_explicitly_ talks about the situation which was described above as
"extremely unlikely".

> /Firefox/: Shipped (https://bugzilla.mozilla.org/show_bug.cgi?id=1547231)

To be clear, the new behavior is enabled in nightly and early betas in
Firefox. It is not yet enabled in final betas or release.

-Boris

[Philip Jägenstedt]

This is exciting, I hope we can successfully match Firefox here and work through the broken sites. Christian, is it possible to measure the "extremely unlikely" condition, and is that in fact the condition that caused the Firefox regressions? Having some idea of the risk before eventually shipping would be great.

WPT shows Firefox Nightly passing:

https://wpt.fyi/results/html/rendering/replaced-elements/attributes-for-embedded-content-and-images/img-aspect-ratio.tentative.html?run_id=317860001&run_id=303040003&run_id=317870001&run_id=275540002

--
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/844d2bc4-bd20-8b79-65d7-2dab5a178072%40mit.edu.

[Simon Pieters]

I'm happy to see movement on this, and hope we can find a way to make this work in a web-compatible way.

I also note that there yet isn't a specification for this change, and the test is very basic (it is not "fully tested").

cheers

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

--

Simon Pieters

https://bocoup.com/

[Malte Ubl]

I want to second my excitement as a web developer!

I have a clarifying question:

Is this change meant to 

a: only change the reserved space during loading, but after the load the area is replaced with the actual intrinsic size of the image (which is hopefully the same) or

b: permanently derive aspect ratio info from the width and height attribute independent of intrinsic size.

It seems that (unless I'm missing something) #a would definitely be web compatible, but it would have the downside that in the cases where #b isn't web compatible #a would still lead to jank.

I'd love it if #b could be shipped, but just #a would be a huge win for UX!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHWN20WmAvkmRZ1y3SvKyKY8z2ZnNPtz6hgxeraWyRnE2rWdDg%40mail.gmail.com.

[Boris Zbarsky]

On 9/6/19 8:52 AM, 'Malte Ubl' via blink-dev wrote:
> a: only change the reserved space during loading, but after the load the
> area is replaced with the actual intrinsic size of the image (which is
> hopefully the same) or
> b: permanently derive aspect ratio info from the width and height
> attribute independent of intrinsic size.

On the Gecko side, I believe we initially tried (b), but that caused the
web compat regressions I already mentioned, so we switched to (a). See
https://bugzilla.mozilla.org/show_bug.cgi?id=1565690 for that change.

-Boris

[Florian Rivoal]

This also needs to circle back to the csswg: currently this is being implemented (if i understand correctly) as c++ code that mimics what a proposed CSS property (aspect-ratio) would be able to do if it were in the UA stylesheet.

The property can absolutely be designed to allow both (a) and (b), then we implement (a) by default for compat, and let authors opt into (b) on sites where they know it's not a problem. This has already been proposed by the editors of the spec (CCing Jen and fantasai to this thread).

—Florian

[Chris Harrelson]

This intent is about implementing (a). Once the image has loaded, it take priority over the aspect ratio inferred from width/height.

--
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/64B254A3-7BCA-4A6B-8486-EBB0671911AB%40rivoal.net.

[Zoom]

Hi All,

Here is the meeting summary from meeting: [blink-dev] Intent to Implement: Compute img/video aspect ratio from width and height HTML attributes

Topic: [blink-dev] Intent to Implement: Compute img/video aspect ratio from width and height HTML attributes
Meeting Number: 701378232
Date: Sep 06, 2019 09:16:07
Attendees: Dima Fom


Thank you for choosing Zoom.
-The Zoom Team

[Christian Biesinger]

Thanks for the feedback, everyone. This has now landed on Canary
behind the "experimental web features" flag, with option a) -- the
aspect ratio is only used before we know the actual size of the image.
Appreciate the notice that this is required for web compat (you'd
think I'd have learned by now not to assume anything). Since
everything will look correct once we get the image dimensions, this
shouldn't cause any actual breakage.

The test has also been improved as part of this work.

Note that I only implemented this for <img>, not <video>, so far
(matching Firefox).

Christian

[Boris Zbarsky]

On 9/25/19 1:05 AM, Christian Biesinger wrote:
> Note that I only implemented this for <img>, not <video>, so far
> (matching Firefox).

As far as I can tell, in Firefox the behavior is implemented for <img>,
<input type="image">, <object data="image-here">, and <embed
src="image-here">, not just <img>.

-Boris

[Christian Biesinger]

Ah thanks, I must have misunderstood Emilio. Will fix.

Christian

[Emilio Cobos Álvarez]

No, you hadn't, fwiw. This is my fault, and indeed I had a comment in
Gecko saying "this goes through a lot of elements and is not great".

I think this is on me, and I should fix Gecko before shipping it so it
only applies to <img>, at least until somebody has a more coherent proposal.

Otherwise, what Gecko implements is basically "anything that can get an
image frame (~LayoutImage) except for 'content: url()' and maps the
width and height attributes to style".

I don't think that's a particularly great thing to spec (even more so
since Blink's implementation is at layout time rather than at attribute
mapping time).

I propose to start with <img> and then whitelist other elements if
wanted / needed. Filed [1] for this.

-- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1583980

[Christian Biesinger]

OK, that makes sense. Re-reading
https://github.com/WICG/intrinsicsize-attribute/issues/16, it does
suggest to only apply this to <img> and <video>.

(we don't implement this as a mapped presentation attribute right now,
fwiw -- that struck me as too much complexity if we don't support the
general aspect-ratio property)

Christian