> how this ties to the [Extensible Web Manifesto](https://extensiblewebmanifesto.org/), and whether it helps to explain `<img>` or whether it could be done differently in a way that does I think this API is somewhat orthogonal to the issue you hint at. If I am guessing right, you're thinking about how in a perfectly-layered system, we'd be able to explain `<img>` as a series of APIs: e.g., fetch() -> encoded bytes -> decoded bytes -> rasterize to new bytes -> paint rasterized bytes. And the encoded bytes -> decoded bytes API would indeed probably use the function name "decode()". What we're doing here is something a bit different, which is more of a hint to the browser to get ready, because we plan on needing rasterization/paint within the next frame. Indeed one of the original name suggestions was `ensureReady()`, but that was deemed too vague and confusing over the simplicitly of `decode()`. I think the web community should definitely work on a bytes -> bytes decoding API in the future. This API is meant for a different purpose, however, of ensuring the existing somewhat-opaque pipeline gets all the information it can to give good performance. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/182#issuecomment-313493800
Received on Thursday, 6 July 2017 19:22:18 UTC