On 2011-12-03 19:43, Charles Pritchard wrote:
...
If there were a mime type that were more appropriate for
compressed/non-compressed use, would it simply be: image/svg ?
I think the obvious choice would be image/svgz, which should be really
short, as it can be defined as gipped-wrapped
On 12/4/11 12:33 AM, Julian Reschke wrote:
On 2011-12-03 19:43, Charles Pritchard wrote:
...
If there were a mime type that were more appropriate for
compressed/non-compressed use, would it simply be: image/svg ?
I think the obvious choice would be image/svgz, which should be
really short,
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.
On 12/3/11 1:16 AM, Julian Reschke wrote:
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
On Fri, Dec 2, 2011 at 6:06 PM, Charles Pritchard ch...@jumis.com wrote:
On 12/2/11 5:41 PM, Jonas Sicking wrote:
On Fri, Dec 2, 2011 at 5:05 PM, Charles Pritchardch...@jumis.com wrote:
On 12/2/11 4:52 PM, Jonas Sicking wrote:
On Fri, Dec 2, 2011 at 4:38 PM, Charles
On 12/3/11 5:51 PM, Jonas Sicking wrote:
On Fri, Dec 2, 2011 at 6:06 PM, Charles Pritchardch...@jumis.com wrote:
On 12/2/11 5:41 PM, Jonas Sicking wrote:
On Fri, Dec 2, 2011 at 5:05 PM, Charles Pritchardch...@jumis.comwrote:
There have been no steps to expand or otherwise support base64
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?
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,
On Fri, Dec 2, 2011 at 4:38 PM, Charles Pritchard ch...@jumis.com wrote:
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
On Fri, Dec 2, 2011 at 5:05 PM, Charles Pritchard ch...@jumis.com wrote:
On 12/2/11 4:52 PM, Jonas Sicking wrote:
On Fri, Dec 2, 2011 at 4:38 PM, Charles Pritchardch...@jumis.com wrote:
On 12/2/11 5:22 AM, Julian Reschke wrote:
On 2011-11-30 19:42, Charles Pritchard wrote:
On 11/30/2011
On 12/2/11 5:41 PM, Jonas Sicking wrote:
On Fri, Dec 2, 2011 at 5:05 PM, Charles Pritchardch...@jumis.com wrote:
On 12/2/11 4:52 PM, Jonas Sicking wrote:
On Fri, Dec 2, 2011 at 4:38 PM, Charles Pritchardch...@jumis.comwrote:
As far as I can tell, vendors are trying to move away from data
Fyi - it's been a long time request from Zynga to have a web packaging
format to serve and store assets in large chunks. A relevant ticket with a
discussion can be found here:
https://bugzilla.mozilla.org/show_bug.cgi?id=681967
I'm all for it, of course.
Am 31.10.11 12:20 schrieb Charles
It would be great to have a native binding to Zlib and Snappy exposed to
Javascript in the browser. Zlib covers the expensive disk use-cases, Snappy
covers the expensive CPU use-cases.
Also a native binding to basic crypto primitives, even if that means just SHA1
to start, and even if the
On 2011-10-31 18:42, Charles Pritchard wrote:
On 10/30/2011 5:56 PM, Cameron McCormack wrote:
On 30/10/11 4:25 PM, Bjoern Hoehrmann wrote:
Then he probably means file system files and not HTTP files, and support
there has indeed been spotty in the past.
Ah, yes. Regarding data: URIs, someone
On 2011-10-31 20:20, Charles Pritchard wrote:
On 10/31/11 11:34 AM, Boris Zbarsky wrote:
On 10/31/11 1:42 PM, Charles Pritchard wrote:
I'm almost certain that somewhere, it is specified that the browser
should sniff the first few bytes of the file to see
if it is compressed.
I don't believe
On Nov 30, 2011, at 7:05 AM, Julian Reschke julian.resc...@gmx.de wrote:
On 2011-10-31 20:20, Charles Pritchard wrote:
On 10/31/11 11:34 AM, Boris Zbarsky wrote:
On 10/31/11 1:42 PM, Charles Pritchard wrote:
I'm almost certain that somewhere, it is specified that the browser
should sniff
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
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
I think crypto is supposed to be in scope of another WG that was being
chartered nowish
On 11/30/11, Joran Greef jo...@ronomon.com wrote:
It would be great to have a native binding to Zlib and Snappy exposed to
Javascript in the browser. Zlib covers the expensive disk use-cases, Snappy
covers
On 10/30/2011 5:56 PM, Cameron McCormack wrote:
On 30/10/11 4:25 PM, Bjoern Hoehrmann wrote:
Then he probably means file system files and not HTTP files, and support
there has indeed been spotty in the past.
Ah, yes. Regarding data: URIs, someone should really just amend the
RFC to allow
On Oct 31, 2011, at 10:42 AM, Charles Pritchard wrote:
On 10/30/2011 5:56 PM, Cameron McCormack wrote:
On 30/10/11 4:25 PM, Bjoern Hoehrmann wrote:
Then he probably means file system files and not HTTP files, and support
there has indeed been spotty in the past.
Ah, yes. Regarding data:
On 31/10/11 10:50 AM, Mike Hanson wrote:
Work in progress:
http://mimesniff.spec.whatwg.org/
There's a section on Images in there which looks like it won't do
sniffing for automatic gunzipping. Although perhaps if the SVG document
were used as the top level document it would be, if it falls
On 10/31/11 1:42 PM, Charles Pritchard wrote:
I'm almost certain that somewhere, it is specified that the browser
should sniff the first few bytes of the file to see
if it is compressed.
I don't believe it is. In fact, doing that would contradict the specs
as they stand, to my knowledge.
I
On 10/31/11 11:34 AM, Boris Zbarsky wrote:
On 10/31/11 1:42 PM, Charles Pritchard wrote:
I'm almost certain that somewhere, it is specified that the browser
should sniff the first few bytes of the file to see
if it is compressed.
I don't believe it is. In fact, doing that would contradict
Hi all
I've tried to search the Webapps and WHATWG mailing lists for previous
discussions about this request, but I haven't been able to find anything.
My request can be explained easily: when uploading files to the server,
many times the upload time can be improved greatly if the file is
On 10/30/11 3:03 AM, Alfonso Martínez de Lizarrondo wrote:
Instead of a method on a Blob, it could be a separate object similar
to Mozilla nsIZipWriter
(https://developer.mozilla.org/en/nsIZipWriter), but with some
simplifications to avoid extra verbose code.
var zipWriter = new zipWriter(
On 30/10/11 10:54 AM, Charles Pritchard wrote:
One reason I've needed inflate is for svgz support. Browser vendors have
consistently left bugs and/or ignored the spec for handling svgz files.
SVG is really intended to be deflated.
All major browsers have support for gzipped SVG documents
On 10/30/11 4:11 PM, Cameron McCormack wrote:
On 30/10/11 10:54 AM, Charles Pritchard wrote:
One reason I've needed inflate is for svgz support. Browser vendors have
consistently left bugs and/or ignored the spec for handling svgz files.
SVG is really intended to be deflated.
All major
* Cameron McCormack wrote:
On 30/10/11 10:54 AM, Charles Pritchard wrote:
One reason I've needed inflate is for svgz support. Browser vendors have
consistently left bugs and/or ignored the spec for handling svgz files.
SVG is really intended to be deflated.
All major browsers have support for
On 30/10/11 4:25 PM, Bjoern Hoehrmann wrote:
Then he probably means file system files and not HTTP files, and support
there has indeed been spotty in the past.
Ah, yes. Regarding data: URIs, someone should really just amend the RFC
to allow specifying a content encoding.
30 matches
Mail list logo
