Exempt SVGs from minifying

[Ryuno-Ki]

This is a breakout from #3645 (comment).

Do we have the need to keep an uncompressed source file for further editing?
What, if we start with SVG, should happen to GIMP files (XCF), Adobe Illustrator (AI) or Photoshop (PSD) that gets „exported to the web”? Shall those live in a special directory as well? You might want to edit them later.

Note, that this might blow up the repo size for everybody!

[Ryuno-Ki]

Related: mdn/content#4505 (comment)

[Ryuno-Ki]

I'm wondering, whether something like https://mermaid-js.github.io/mermaid/#/ could help in that case.
However, I understand Peter as in generating those charts from code. Since it is a Django project, I'd expect a Sphinx plugin for that …

[hamishwillee]

See #1678

We should have a recommended way to store any source docs we might use. The mechanism needs to be persistent and dead easy to associate with the rendered file. Historically I have used things like HTML comments with links to draw.io or lucidchart. The other option is to use something like SVG where there are open source editors that are pretty good - at least once the base image has been created.

[peterbe]

You're talking about #1678 which might be a better forum for discussing that "trail of master tape material".

[Ryuno-Ki]

Since that issue, we switched to a mode of using discussions first before we can create actionable issues to work on.

[peterbe]

I'm against this idea. I think all images should be as small as they can be in the content repo.
If an image is viewed 1,000,000 times by 1,000,000 different people, serving it as optimized as possible really does add up in greater net value. Faster pages. Less electricity use.

The other reason is that unoptimized SVGs add bytes to the git repo itself. Unnecessary bytes. If the SVGs files are larger than they need to, it makes every single git clone slower and uses up more disk space. Today, every single PR on the mdn/content repo runs a (shallow) git clone. So if that blob is bigger than it needs to be it really starts to add up.

I think it would be different if the circumstances were different. If the upload was done to a centralized server (e.g. an S3 bucket), then it doesn't need to be re-downloaded again and again. But that's now how Yari and the content works.

I still think it's important to store the source files (the project files that produce the .svg file) but that's what #1678 is for.

[hamishwillee]

@peterbe Let's close this as a duplicate of #1678

[Ryuno-Ki]

Agreed.

[Ryuno-Ki]

Transferred to Q&A category to be able to accept answers.
See https://docs.github.com/en/discussions/collaborating-with-your-community-using-discussions/participating-in-a-discussion#marking-a-comment-as-an-answer

You can mark a comment in the discussion as an answer to the discussion if a discussion is within a category that accepts answers.

and

You can't mark a threaded comment in response to a comment as the answer to a discussion. You also can't mark a minimized comment as the answer to a discussion.

[hamishwillee]

Never used this before. Cool.