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.
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)?
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.
...
Best regards, Julian
