W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Enable compression of a blob to .zip file

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 30 Nov 2011 10:42:42 -0800
Message-ID: <4ED67922.9070409@jumis.com>
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:


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:.

Received on Wednesday, 30 November 2011 18:43:14 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC