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

Re: Enable compression of a blob to .zip file

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 03 Dec 2011 10:16:55 +0100
Message-ID: <4ED9E907.4030606@gmx.de>
To: Charles Pritchard <chuck@jumis.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
On 2011-12-03 01:38, Charles Pritchard wrote:
> ...
>> Yes. So is HTML. What's the benefit of compressing SVG first and then
>> BASE64-encoding it, over having it just URI-escaped, and gzip the
>> whole HTML page (something most servers will automatically do for you)?
> SVG is primarily an image format. It's more appropriate to compare SVG
> and SVGZ to BMP and PNG.
> SVG files may reasonably be compressed by 80%.

Yes. And they can, using Content-Encoding (and Transfer-Encoding).

> SVG files are useful for including inline, in both CSS and JS and HTML,
> to a lesser extent.
> My bringing this up is not about HTTP, the HTTP case is already working
> just fine.
> It's about all other cases, including Blob uris. Those are not working
> well at all, and the SVG spec requests that conforming implementations
> support deflated streams.

Where does it say that?

>>> 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
>> Indeed. It seems that except Opera all browsers do this right.
>> Again: it can be done, but it should be done correctly.
>> Defining a separate media type is the simplest thing to do here.
> Image formats have sniffing specified within the HTML5 specs. Even HTML
> has some sniffing. It seems completely reasonable that SVG be included
> in this.
> Adding a separate media type would work, but it's counter to what
> current specifications call for. It's also unnecessary for the HTTP
> protocol.

We had a very long discussion about the svg+xml registration, because it 
was a bit vague on compressed SVG. The IETF rightfully (IMHO) insisted 
on removing the vagueness, because the base spec for +xml (RFC 3023) 
doesn't allow compression.

If it turns out that svgz as a media format *is* needed, then we should 
define a type for it.

> ...

Best regards, Julian
Received on Saturday, 3 December 2011 09:17:34 UTC

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