Update Drupal's default file type icons

Hrm. The test fail seems unrelated.

Drupal\Tests\node\Functional\NodeRevisionsAll
The string "page=1" was not found anywhere in the HTML response of the current page.

Add the new high-resolution SVGs files alongside existing low-resolution PNGs in all themes shipped with Drupal core. Do not remove old PNG files from the codebase. Add cleanup task #3452493: [12.x] Remove images that have been replaced in core.

I'm having second thoughts about this in the context of the StarterKit theme. Certainly for Umami and Claro themes, we shouldnt remove the PNGs. However the StarterKit theme, when used as intended (if I understand correctly), is supposed to be a kind of "line in the sand" or fork of the codebase and a snapshot in time. This implies to me that we could easily remove the old PNG files and then any new themes created from the Starterkit would have a clean slate and no duplicitous files. Tech debt free!

I think this might get more attention if it were under theme system.

MR needs to be updated for 11.x please.

My apologies for starting from the wrong branch. I recreated the same existing MR branch name locally, cherry-picked the existing commits, and force-pushed to the existing MR. Back to NR.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I've rebased the MR on the latest 11.x in an attempt to clear unrelated CI failures...

Can we spend some time optimizing them before bringing them into Core?

https://www.svgviewer.dev/
https://optimize.svgomg.net/

For instance, 948 bytes:

<svg aria-hidden="true" focusable="false" width="16" height="16" viewBox="0 0 16 16" fill="none" xmlns="http://www.w3.org/2000/svg">
  <path d="M11 0L14 3V16H2V0H11Z" fill="#fff"/>
  <path d="M11 0L14 3V16H2V0H11ZM3 15H13V4H10V1H3V15ZM11 3H12.5L11 1.5V3Z" fill="#7f7f7f"/>
  <path d="M4 2H9V3H4V2Z" fill="#dadada"/>
  <path d="M4 3H9V4H4V3Z" fill="#e0e0e0"/>
  <path d="M4 4H9V5H4V4Z" fill="#ebebeb"/>
  <path d="M4 5H12V6H4V5Z" fill="#eee"/>
  <path d="M4 6H12V7H4V6Z" fill="#f5f5f5"/>
  <path d="M4 7H12V8H4V7Z" fill="#f8f8f8"/>
  <path d="M4 8H12V9H4V8Z" fill="#fcfcfc"/>
  <path d="M4 3H9V4H4V3Z" fill="#9e9e9e"/>
  <path d="M6 8H4V7H6V8ZM12 8H7V7H12V8Z" fill="#9e9e9e" fill-opacity="0.65"/>
  <path d="M8 6H4V5H8V6ZM12 6H9V5H12V6Z" fill="#9e9e9e" fill-opacity="0.8"/>
  <path d="M8 10H4V9H8V10ZM12 10H9V9H12V10Z" fill="#9e9e9e" fill-opacity="0.45"/>
  <path d="M6 12H4V11H6V12ZM10 12H7V11H10V12ZM12 12H11V11H12V12Z" fill="#9e9e9e" fill-opacity="0.3"/>
</svg>

Than 803 bytes:
<svg xmlns="http://www.w3.org/2000/svg" fill="none" aria-hidden="true" viewBox="0 0 16 16"><path fill="#fff" d="m11 0 3 3v13H2V0z"/><path fill="#7f7f7f" d="m11 0 3 3v13H2V0zM3 15h10V4h-3V1H3zm8-12h1.5L11 1.5z"/><path fill="#dadada" d="M4 2h5v1H4z"/><path fill="#e0e0e0" d="M4 3h5v1H4z"/><path fill="#ebebeb" d="M4 4h5v1H4z"/><path fill="#eee" d="M4 5h8v1H4z"/><path fill="#f5f5f5" d="M4 6h8v1H4z"/><path fill="#f8f8f8" d="M4 7h8v1H4z"/><path fill="#fcfcfc" d="M4 8h8v1H4z"/><path fill="#9e9e9e" d="M4 3h5v1H4z"/><path fill="#9e9e9e" fill-opacity=".7" d="M6 8H4V7h2zm6 0H7V7h5z"/><path fill="#9e9e9e" fill-opacity=".8" d="M8 6H4V5h4zm4 0H9V5h3z"/><path fill="#9e9e9e" fill-opacity=".5" d="M8 10H4V9h4zm4 0H9V9h3z"/><path fill="#9e9e9e" fill-opacity=".3" d="M6 12H4v-1h2zm4 0H7v-1h3zm2 0h-1v-1h1z"/></svg>

These are little, but they add up, with every page load.

It could get smaller still if we simplifed how it looks.

Isn't this kind of micro-optimization mostly obviated by gzip or brotli? I'm happy to be wrong, but these savings seem negligible in practice—especially considering that Drupal core’s own HTML output doesn’t aggressively strip whitespace, newlines, or indentation either.

Also worth noting: running SVGs through optimizers like SVGO can make them harder to review and maintain. For example,

path="M11 0L14 3V16H2V0H11ZM3 15H13V4H10V1H3V15ZM11 3H12.5L11 1.5V3Z"

becomes

path="m11 0 3 3v13H2V0zM3 15h10V4h-3V1H3zm8-12h1.5L11 1.5z",

which is more compact but much less readable for quick diffs or manual review.

t would be nice if there was an automated solution to always minify SVGs in core in the same way, because different tools optimize in different ways, using different default options, often stripping out important attributes. Applications that generate SVGs also generate their own different ways of structuring the SVG, so every time you pull an "optimized" file into an SVG editor, and save it again, it may make unrelated changes on the roundtrip back to optimized SVG. Therefore, the SVGs require manual edits after optimization to restore settings.

I think what is missing here is clear agreement to treat SVGs as implementation assets, not hand-curated visual code.