- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Tue, 25 Jun 2019 23:22:18 +0000
- To: public-svg-issues@w3.org
I'm skeptical that this confusion is solvable at this point. Any change introduces compatibility issues. But I agree that `.svgz` files on the web are often more pain then they are worth. Even if you serve them correctly, none of the browsers I've tested will compress it again on saving, creating a mismatch with the file extension when you try to open the file. I would be happy to add a warning to the spec, that - Serving `.svgz` over HTTP requires correct configuration and some web servers do not support the necessary configuration options. - The recommended approach is for website authors to use uncompressed `.svg` files with the best server-enabled compression supported by the client, including the use of more recent compression methods (e.g., Brotli). - As an alternative (e.g., if the uncompressed `.svg` file is very large), it may be possible to configure the server to recognize a `.svg.gz` file extension as representing a pre-compressed SVG file. (E.g., for nginx this is supported with the [`gzip_static` directive](http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html)). The website author would need to rename the `.svgz` file to `.svg.gz` before uploading. I'd also hope that requests from web developers might convince servers to _add_ support, but I'm not sure if that will happen. I found a [`wontfix` nginx feature request to add support for `.svgz` to the `gzip_static` directive](https://trac.nginx.org/nginx/ticket/372). -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/svgwg/issues/701#issuecomment-505658002 using your GitHub account
Received on Tuesday, 25 June 2019 23:22:19 UTC