Re: Enable compression of a blob to .zip file

On 12/2/11 5:22 AM, Julian Reschke wrote:
> On 2011-11-30 19:42, Charles Pritchard wrote:
>> 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.
>
> There's no reason to add more quirks. Instead we should try to remove 
> the quirks.

This in no way changes the scheme of data URIs. Data uri quirks are 
mainly about string length.
As far as I can tell, vendors are trying to move away from data uris and 
toward blob uris.

IE has string length issues; recently, Chrome started limiting paste 
into address bar length, Firefox limited paste into address bar 
altogether. Webkit can not cope with data uris in any copy/paste text 
field (input type=text / textarea) if they are more than ~20k and have 
no spaces.

These issues have nothing to do with SVG in context.


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

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.

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

I don't think either way is "correct", but I hope that this issue is 
looked at. And I do think that  SVGZ is a very reasonable use case for 
exposing a deflate method to the scripting environment.

It would have been very simply to support SVGZ in non-HTTP contexts by 
simply looking at a few magic bytes and processing things from there. 
It's a shame that didn't happen. Afaik, there will not be progress on 
this issue any time soon.


-Charles

Received on Saturday, 3 December 2011 00:38:27 UTC