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
