- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 30 Nov 2011 10:42:42 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
On 11/30/2011 8:04 AM, Julian Reschke wrote: > On 2011-11-30 16:50, Charles Pritchard wrote: >>> Nope. If you need gzipped SVG in data URIs, the right thing to do is >>> to either extend data URIs to support that, or to mint a separate >>> media type. >> >> Why? Seems like a lot of complexity for blob, data and file for >> something that could otherwise be handled by minimal code. > > It would mean that the semantics of a data URI depends on who's > processing it. It would probably also cause lots of confusion about > what types is applies to. It's already the case that data URIs depend on UA quirks. SVG support is highly implementation dependent. This issue would apply to one type, SVG. It's feature detectable through img src events. This would greatly improve the ability to use data:uris for SVG content. SVG can be highly compressible. There's been a 9 years of lingering bug reports area: https://bugzilla.mozilla.org/show_bug.cgi?id=157514 https://bugs.webkit.org/show_bug.cgi?id=5246 http://www.ietf.org/mail-archive/web/pkix/current/msg27507.html http://lists.w3.org/Archives/Public/www-svg/2011May/0128.html http://code.google.com/p/chromium/issues/detail?id=76968 There are all sorts of reasons to do it. It's a constant bummer that we need to include inflate code just to use inline svgz. This issue also comes up with Blob. It could have been fixed with the most minor of patches, years ago. I think that there are some theoretical purity issues here that have really things held-back. I don't need to revise the entire data: uri, I'm just looking to add a note for content-type sniffing of the first few bytes of a file, when SVG is loaded from a non-http resource, explicitly, file:, filesystem:, blob: and data:. -Charles
Received on Wednesday, 30 November 2011 18:43:14 UTC