Img decoding attribute

[vmpstr]

Hello TAG!

I'm requesting a TAG review of:

• Name: img decoding attribute
• Specification URL: spec pull request: Add <img> decoding="" attribute whatwg/html#3221
• Explainer, Requirements Doc, or Example code: disccussion on "decode" attribute on <img> whatwg/html#1920
• Tests: https://github.com/w3c/web-platform-tests/blob/master/html/dom/elements-embedded.js
• Primary contacts: @vmpstr

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

Thanks!

/cc: @chrishtr @domenic @smfr

[slightlyoff]

Looks like there's already an Intent-to-Ship for Chromium: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/MbXp16hQclY/bQjegyrbAgAJ

[cynthia]

As a curious question, it seems like there are two modes here being proposed - sync and async - since there is a mechanism that allows an explicit request to decode a certain HTMLImageElement, I'm curious if there should be a "no decode" mode (to save memory, and potentially VRAM in certain cases) for resources that the content developer only would like to have available given that the user triggers a specific view where this image needs to be shown? With decode() (which from what I see has had some debates on whether or not it is the best name, setting that discussion aside) it seems like this would allow placeholding image elements and only decoding them when deemed needed.

As for what has been proposed, I'll have to wait for @dbaron 's feedback on this since he is the assigned reviewer for this.

[triblondon]

Sangwhan agreed to write up the conclusions of our very extensive discussions at London F2F.

[cynthia]

This was brought up during the London F2F - we understand the underlying problem this is attempting to address, and believe we are in agreement on the importance giving better control on when and how images are decoded in a document.

That said, we have spent a reasonable time of this during the F2F at great length, and have some concerns on the approach taken here. The approach taken here seems to be intended to address the problem in limited scope for simplicity, where we could be trying to address this in a more extensible way - exposing the primitives surrounding loading, decoding, and eventually rasterizing images in a way that provides the building blocks for developers to define the behavior as they see fit.

The comments above cover the property discussed in this review, but also the decode() API which we have recently done a review on.

[dbaron]

The decode() review was #182.

Though I'd note the other tradeoff regarding primitives is that there are areas where we'd like to leave room for implementations to optimize, and defining some things to precisely in terms of primitives could constrain that.

[torgo]

@cynthia is going to try to draft a proposal by next week as feedback

[plinss]

@cynthia to file an issue on the spec