- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 02 Dec 2011 14:22:59 +0100
- To: Charles Pritchard <chuck@jumis.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
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
Received on Friday, 2 December 2011 13:24:21 UTC