{"action":"created","issue":{"url":"https://api.github.com/repos/whatwg/html/issues/1920","repository_url":"https://api.github.com/repos/whatwg/html","labels_url":"https://api.github.com/repos/whatwg/html/issues/1920/labels{/name}","comments_url":"https://api.github.com/repos/whatwg/html/issues/1920/comments","events_url":"https://api.github.com/repos/whatwg/html/issues/1920/events","html_url":"https://github.com/whatwg/html/issues/1920","id":183561772,"number":1920,"title":"\"async\" attribute on <img>, and corresponding \"ready\" event","user":{"login":"smfr","id":20968,"avatar_url":"https://avatars.githubusercontent.com/u/20968?v=3","gravatar_id":"","url":"https://api.github.com/users/smfr","html_url":"https://github.com/smfr","followers_url":"https://api.github.com/users/smfr/followers","following_url":"https://api.github.com/users/smfr/following{/other_user}","gists_url":"https://api.github.com/users/smfr/gists{/gist_id}","starred_url":"https://api.github.com/users/smfr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/smfr/subscriptions","organizations_url":"https://api.github.com/users/smfr/orgs","repos_url":"https://api.github.com/users/smfr/repos","events_url":"https://api.github.com/users/smfr/events{/privacy}","received_events_url":"https://api.github.com/users/smfr/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2016-10-18T00:29:07Z","updated_at":"2016-10-18T03:42:23Z","closed_at":null,"body":"Decoding of large images can block the main thread for hundreds of milliseconds or more, interrupting fluid animations and user interaction. Currently, there's no way for a web author to specify that they want an image to be decoded asynchronously, so there are scenarios where it is impossible to avoid UI stalls.\r\n\r\nTo solve this problem we propose an \"async\" attribute on image elements. This attribute is a hint to the UA that the author has requested asynchronous decoding. This implies that if the UA paints an image after the \"load\" event has fired, but before the image has been decoded, the UA is allowed to not paint the image (rather than block on decoding it).\r\n\r\nTo notify authors when a decoded image frame is available, we propose firing a new event, \"ready\", on the image element. This would allow authors who require a fully-decoded image, in content that is sensitive to UI stalls, to wait for the \"ready\" event before doing something that brings the image into view (such as a CSS transition).\r\n\r\nSome images repeatedly decode frames, for example, animated GIFs. In addition, the UA can throw away the decoded frame for a still image, requiring a re-decode. In these cases, we propose that the \"ready\" event only fires once, the first time a frame is available for display.\r\n\r\nISSUES:\r\n\"async\" is currently used to imply async loading, and it's possible that we'd want to use it in this sense for images too. Maybe call the new attribute \"asyncDecode\" or something else.\r\n\r\nThis only solves the problem for image elements, not CSS images. We could add a CSS property to allow async decoding for CSS images, and fire events on the element to which it applies."},"comment":{"url":"https://api.github.com/repos/whatwg/html/issues/comments/254398767","html_url":"https://github.com/whatwg/html/issues/1920#issuecomment-254398767","issue_url":"https://api.github.com/repos/whatwg/html/issues/1920","id":254398767,"user":{"login":"smfr","id":20968,"avatar_url":"https://avatars.githubusercontent.com/u/20968?v=3","gravatar_id":"","url":"https://api.github.com/users/smfr","html_url":"https://github.com/smfr","followers_url":"https://api.github.com/users/smfr/followers","following_url":"https://api.github.com/users/smfr/following{/other_user}","gists_url":"https://api.github.com/users/smfr/gists{/gist_id}","starred_url":"https://api.github.com/users/smfr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/smfr/subscriptions","organizations_url":"https://api.github.com/users/smfr/orgs","repos_url":"https://api.github.com/users/smfr/repos","events_url":"https://api.github.com/users/smfr/events{/privacy}","received_events_url":"https://api.github.com/users/smfr/received_events","type":"User","site_admin":false},"created_at":"2016-10-18T03:42:23Z","updated_at":"2016-10-18T03:42:23Z","body":"> Currently there seems no UA which (intentionally) blocks layout/paint on image download/decoding.\r\n\r\nFirst, we're not talking about downloading here. This proposal doesn't change anything about how image downloading works.\r\n\r\nSecond, Mac and iOS WebKit block painting on image decoding (I work on WebKit for Apple, BTW). That's the problem we're trying to address. If other UAs have solved this problem, I would be interested to hear how."}}
{"actor":{"display_login":"smfr"}}