- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 03 Dec 2011 10:16:55 +0100
- 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