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.
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.
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
There are all sorts of reasons to do it. It's a constant bummer that we
need to include inflate code just to use inline svgz.
This issue also comes up with Blob.
It could have been fixed with the most minor of patches, years ago. I
think that there are some theoretical purity issues here that have
really things held-back.
I don't need to revise the entire data: uri, I'm just looking to add a
note for content-type sniffing of the first few bytes of a file, when
SVG is loaded
from a non-http resource, explicitly, file:, filesystem:, blob: and data:.
-Charles
