- From: <bugzilla@jessica.w3.org>
- Date: Tue, 15 Jan 2013 20:40:28 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20677 --- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch> --- (In reply to comment #2) > > In the first case, the image could have been downloaded using <image > src="abc-123.png" srcset="2x abc-123.2x.png" /> if the browser was first > launched on a 'retina' screen. You have no control on whether the browser > will choose the first or the second one, but if later on you want to use the > exact same image on the same device on a canvas, you want to use whatever > version was already downloaded. How would that file get cached if it's not in the manifest? > In the second case, the dictionary may have been cached because the user > accepted to use an appcache for the synonymous webservice (which involves > caching the dict). However, you don't want to use the file if it was not > cached because it's probably way to huge to be used for just one lookup. Oh this is not for testing if the file is in the _current_ appcache but for testing if the resource is in _any_ appcache? Interesting. That would have some pretty serious freshness complications... (what if the cache we have the file in is a year old? Should we still think we have it for the purposes of this API? What if it's more up to date than the things in the current appcache?) > In the last case, I already explained why some files may be in cache: the > appcache is minimalist by default but may be growing at the user request to > include more components. Only if you use the fallback feature and visit the file directly, right? Or do you mean some other way? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 15 January 2013 20:40:29 UTC