- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 04 Nov 2012 00:33:37 -0400
- To: Dirk Schulze <krit@webkit.org>
- CC: Erik Dahlstrom <ed@opera.com>, Dirk Schulze <dschulze@adobe.com>, "www-svg@w3.org" <www-svg@w3.org>
On 11/4/12 12:14 AM, Dirk Schulze wrote: > Actually that makes SVG stacks useful. If the browser needs to send requests for the same resource over and over again, this would kill the benefit of SVG stacks. Furthermore, some servers like the W3C server delay requests of the same resource, even if the fragment differs on every request. This leads to serious loading issues on Filter Effects[1] for WebKit, which doesn't have this optimization either. It's not just an optimization. It's a matter of caching semantics differences: at which points can (or must) things be cached, and how does the caching and invalidation work? Tiny 1.2 defines this fairly precisely for external resources for a given document; across different documents presumably HTTP semantics hold. HTML5 attempts to define this precisely for <html:img>, last I checked (and in particular, there are certain non-HTTP caching semantics there that are required for web compatibility). Other places that wish to trigger fetches (in webapps terminology) need to define their own non-HTTP caching semantics if they want them.... Most don't bother, of course. -Boris P.S. I believe Gecko actually applies identical caching behavior for all image loads, not just <html:img>. That includes various background images, etc. But it's not clear to me that this is actually allowed by the various specs involved. Which might be a bug in the specs!
Received on Sunday, 4 November 2012 04:34:03 UTC