Comments (7)
Hm. I'm not sure what the course of action would be here. The "compression" applies to the mime type, not the extensions. This module is just a database of mime types, and only contains data for types. What do you think should be changed? Just remove "compression" flag from "image/svg+xml"?
from mime-db.
Hm. I'm not sure what the course of action would be here.
Yes, I'm also not sure, reason why I've opened this discussion.
What do you think should be changed? Just remove "compression" flag from "image/svg+xml"?
Since SVGs are used quite a lot, and they compress very well, I personally don't think this project should not recommend SVGs to be compressed.
What do you think about changing compressible
to an array of extensions?
"image/svg+xml": {
"source": "iana",
"compressible": ["svg"],
"extensions": ["svg","svgz"]
}
from mime-db.
I really don't want to do that, because this is a database of mime type information, not extension data. For each mime type entry we have keys that tell aspects of the type. I would be really careful changing the format in any way at this point, due to it's use, especially outside of npm (using the db.json file directly). Probably worth creating a new project at the point where the format of the main json needs to be changed.
Remember that this library is just for looking up mime types; it does not provide any mechanism to lookup extensions. In this way, this library only provides information once you know the mime type, so it does not say that svgz is compressible, only that image/svg+xml is compressible and that there are two known extensions that mime type can have.
The proposal won't for example solve the following data:
"my/type1": { compressible: true, extensions: ["my"] }
"my/type2": { compressible: false, extensions: ["my"] }
I think that we need to be really careful and not allow non-mime data creep into this module unless there is a clear discussion on exactly what this module will become and such.
As it is, there isn't an issue here because the data refers to tge mime type, and as you admit the type is in fact compressible 👍
from mime-db.
If you are wondering on the label, it is in reference to the subject (which is seen in lists along side labels):
Do not mark
SVGZ
files as compressible
Because this module does not mark anything about extensions, only mime types. If there is something using this module to infer such a thing, unfortunately that is outside this module's control. There is an open issue about providing extension-based data which would then make it an issue if that declared svgz as compressible but that functionality does not yet exist.
from mime-db.
And thinking it over more, I think shouldn't svgz extension not even be under that mime at all? I guess it would depend on if the specification for the image/svg+xml type has some kind of built in deflating? Just thinking if I compressed html and saved as htmz would that still be text/html ?
from mime-db.
shouldn't svgz extension not even be under that mime at all?
https://www.w3.org/services/svg-server/
... states .svgz and .svg are valid for image/svg+xml
. Relatively a new doc.
from mime-db.
Additional followup notes after rereading the spec of gzip, similar questions around the web related to ~"is svgz compressible?", and some of my experience/understanding:
Summarizing
If a file is already compressed gzip will store it thus deactivating the compression and decompression algorithms and is a flat out "copy" (using 7z's terminology here) or "stored" as gzip typically refers to it.
So the accumulated answer in short is a .svgz may be additionally compressible.
Key points
- In regards to the compression level, if the HTTP RFC specifications ever add another (which they can at any point and have in my computing tenure... see here on MDN), say bzip or some other quantum level compression, to the mix one can dual compress and may achieve additional improved compression ratios. One is persistent storage compression (svgz) vs. dynamic transmission compression (the HTTP header with client/server).
- If the gzip container data (binary header, block descriptions, and trailer) is dynamically determined to not be compressible then the web gzip (HTTP transmission) will just store it.
- If one gets really bored and wants to store (the gzip term here again) the .svg data into a .svgz then there is no compression of the source... depending on how the server transmits the
Content-Encoding
it can optionally tell the client/server to compress/decompress using an alternate compression directly instead. - Some .svg and .svgz may contain non-compressible data such as the data URI ... so eventually perhaps some scrubbers may employ image data compression by decoding, optimizing, and reencoding (my current rant at it being absent). Some image creator software horribly adds extra blocks of repetitive useless and unused information, usually at the tail end, which would merit additional compression at the encoded level of base64.
From the standards, other answers over the years on the web, and my humble opinion/experience over the minuscule time I've been programming over the decades in relation to my mentors the issue of .svgz being compressible is negligible and should probably not be abstracted further here because not all use cases apply to current usage of a possible value of false
in the json.
Regarding the extension usage instead of boolean for that json property of compressible
in this project is again... not all use cases may apply.
from mime-db.
Related Issues (20)
- Newline-delimited JSON HOT 3
- Add extensions for audio/amr type
- Add jsm extension for application/javascript HOT 3
- Missing mime type image/avif-sequence HOT 3
- '.zip' file has a 'application/x-zip-compressed' in Windows. HOT 2
- What are the allowed characters for an extension? HOT 6
- .asc extension maps to application/pgp-signature instead of application/pgp-keys HOT 1
- TypeScript file extensions map to incorrect file types HOT 1
- Re-raising the now updated JS mime-type issue (from #194) HOT 7
- Add `.json` extension for `application/jf2feed+json` HOT 2
- `.mov` vs `.qt` HOT 9
- Add .yamlld extension HOT 1
- YAML is application/yaml HOT 3
- Add image/jpeg for .jfif file extension
- ts extension incorrectly mapped to video/mp2t ? HOT 4
- Update existing dcm format HOT 1
- Minify `db.json` file HOT 5
- Missing extensions list for model/step HOT 2
- YAML missing some types HOT 5
- text/calender
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mime-db.