This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Sorry to bother you. I've never attempted to contribute to the html specification before, so I'm not sure I'm going about this the right way? I'm in the process of developing a html5 app and have run into a problem that I think seriously threatens the usefulness of html5 as a platform for building applications. Essentially, the lack of an api call along the lines of .add_to_cache(url, expires) seems like a glaring omission and means that I can't (for example) have some javascript dynamically generate links to images and have those images cached locally. Here is a link to a question from someone else having the same problem http://stackoverflow.com/questions/3476864/html5-iphone-dynamic-caching-of-images There seem to be many people with similar issues.
(In reply to comment #0) > Essentially, the lack of an api call along the lines of .add_to_cache(url, > expires) seems like a glaring omission and means that I can't (for example) > have some javascript dynamically generate links to images and have those images > cached locally. There are many ways to force a caching opportunity. For example, you could just create a bunch of images in javascript. You don't need to add them to the document, just create them and set their src. They'll be downloaded and cached as appropriate. You can do this with *any* GETable resource, not just images.
thanks for the response. yes, but then caching policy is controlled purely by the cache header sent by the server? If that's a server I don't control -in this specific case twitter.com- there doesn't seem to be anything I can do about the lack of caching. I wouldn't dream of a change to the html spec to solve my specific problem with a specific website :) but it just seems that javascript ought to have the ability to dynamically change what gets cached within it's domain?
(In reply to comment #2) > yes, but then caching policy is controlled purely by the cache header sent by > the server? > > If that's a server I don't control -in this specific case twitter.com- there > doesn't seem to be anything I can do about the lack of caching. That's probably a feature not a bug. > I wouldn't dream of a change to the html spec to solve my specific problem with > a specific website :) but it just seems that javascript ought to have the > ability to dynamically change what gets cached within it's domain? What do you mean by "it's domain", and why should it have that ability? Anyhow, if you really want to preserve image state without reference to the original resource, load it into a canvas bitmap and persist that.
What I meant by "in it's domain" is that javascript probably shouldn't be able to modify the cached entries of non-same-origin documents. Sorry to be vague about it, but I'm guessing you guys spend more time thinking about cross-domain scripting vulnerabilities than I do :) Although now that I do think about it, this could surely be done quite safely if the cache of the non-origin items were only viewable from the requesting domain (if that makes sense? > That's probably a feature not a bug. I've no doubt it's deliberate, but it seems logical to me that the client should be able to change it's mind and cache what it likes. >Anyhow, if you really want to preserve image state without reference to the >original resource, load it into a canvas bitmap and persist that. I've thought about suggestions like that (such as converting the image data to a base64 string) but I have 1000's of images that I'd like to cache. doing the conversion for 1000's of images is likely to be slow and I'd probably end up wanting a way to cache the base64 -> binary conversion :) My question ultimately becomes, why can't javascript dynamically update the manifest data? Or making localStorage able to store binary data might be a more flexible solution? It would also be nice to allow apps to request more than the 2-5Mb of localStorage that currently seems to be provided?
localStorage can store binary data per spec, it's just not implemented yet. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: none yet Rationale: We actually used to have an API to add things to the appcache, but we removed it in a simplification sweep a while back. I expect we'll add it back in a future version once browsers reliably implement what we have so far. We don't want to run away from the browsers adding too many features, though, or interoperability will suffer as they each pick their own bit to implement and ignore the rest.
mass-moved component to LC1
This bug was cloned to create HTML WG bug 19040.
*** This bug has been marked as a duplicate of bug 20084 ***