- From: Simon Pieters <simonp@opera.com>
- Date: Mon, 18 Jun 2012 09:00:21 +0200
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: WHATWG <whatwg@whatwg.org>
On Fri, 15 Jun 2012 18:01:09 +0200, Ian Hickson <ian@hixie.ch> wrote: >> When preload=none, step 2 of >> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-media-load-resource >> should not be optional. >> >> The effective (internal) preload state should be defined. >> >> It should also be defined that with preload=metadata, readyState should >> never go beyond HAVE_CURRENT_DATA, even for a data: URL or otherwise >> fully cached resource. Please specify the above. > Making it non-conforming for a user agent to aggressively cache > resources, > especially if the user has asked for it, is a non-starter. Aggressively caching does not necessarily need to be exposed to scripts. > There are going > to be cases where that's what the user wants, and I don't see why we > would > have to make this non-conforming. > > >> > As far as I can tell, the spec is as detailed as it can be here given >> > the range of possible implementation strategies that we need to allow. >> > >> > Could you give a concrete example of what you are concerned about? >> >> <video src=x preload=none onsuspend="makeSiteWork()"></video> > > Then we should stop firing "suspend" in the preload=none case, No. > or fire it > in every case if preload=non, even if the UA immediately unsuspends. Maybe. > But I'm not convinced anyone is going to hook into onsuspend in this way. > There'd be no point as far as I can tell, and it's more complicated than > the alternative (just run the code straight away without waiting). You're not convinced that people on the Web do things in ways more complicated and fragile than necessary, just because it's possible? -- Simon Pieters Opera Software
Received on Monday, 18 June 2012 06:59:36 UTC