This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Given that fallback content inside of a <video> will never display in a browser that understands <video> (without Javascript-ery on the part of the author) [1][2], <video>-supporting browsers should not load <img>s (or any other external fallback resources) inside of <video>. Use case: Animated Gifs are inefficient. Twitter started allowing users to include Gifs in tweets this summer [3]. They convert the Gifs into MP4s on the backend and deliver <video>s. I am trying to do the same thing, but want to include the Gifs (as <img>s inside of <video>) as a fallback for browsers that don’t support <video>. Doing so now means that users load both the Gif *and* the MP4. [1] http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Jul/0789.html [2] http://christianheilmann.com/2013/04/21/showing-multimedia-fallback-content-when-no-supported-source-is-found/ [3] https://twitter.com/Support/status/479307198901026816
My initial reaction to this was "wontfix", due to compat risk and slippery slope. But on further investigation, the compat might be OK and the slope was short. It increases complexity but might make pages load slightly faster. Not loading invisible images *in general* is not Web-compatible. This would need to be "ancestor", not "parent". "or any other external fallback resources" -- which ones? <object> and <embed> in <video> already don't load, per spec. But anything else loads. img iframe input type=image video audio I don't think there's much to be gained by doing this for elements other than object/embed/img. If we do this we should probably also do it for <img> in <object> that doesn't show its fallback. This is mostly used for "get flash" links, looking at webdevdata. Loading those images is certainly a waste. I didn't see anything obvious that would break. This would also complicate https://html.spec.whatwg.org/multipage/embedded-content.html#relevant-mutations a bit. Check the ancestor chain for object/audio/video when the element or an ancestor is inserted/removed. This could affect all insertions/removals (check descendants to notify <img>s. then check ancestors to look for object/audio/video). I don't think that's acceptable. But maybe it's OK if an <img> doesn't load after you move it out of a <video>?
We would also need to run "update the image data" when an ancestor <object> starts showing its fallback content.
I see 212 img in object/audio/video in webdevdata of 102,000 pages (data from last year). Since this is only about fallback content, plugins are going away and browsers without <video> support is also going away, might not be worth worrying about. The given use case is covered by lazyload.