we are given an option for the upload form to remove the unsafe CSS

...with the result that your SVG file may look horrible. How does that help anyone?

The thousands of available OWID SVG images are CC-BY, and are a great resource. OWID offers SVG and PNG versions of all its images.

Most OWID SVG files looked fine on Wikimedia before the import code was added. OWID was trying to solve a problem of the wrong fonts being substituted on Wikimedia and elsewhere. The font substitution on Wikimedia was usually only a problem when text approached an edge of the image.

The import solution probably worked fine elsewhere, because OWID can be trusted.
https://en.wikipedia.org/wiki/Our_World_in_Data

But Wikimedia requires that only free fonts be used on Wikimedia servers, and that they come from Wikimedia servers.

There are thousands of OWID files on the Commons:
https://commons.wikimedia.org/w/index.php?search=owid&title=Special%3ASearch&ns0=1&ns6=1&ns12=1&ns14=1&ns100=1&ns106=1
That search pulls up around 3800 images.

Those are just the images with OWID in the title. There are many more without OWID in the title. None of the SVG ones can be updated now, as far as I know. I think the import code is added to all OWID SVG files.

The SVG OWID files (at OWID today) I have looked at still have the font family list in the SVG. So removing the import code just puts us back where we were before it was added. Which is that most OWID files look fine on Wikimedia. Those that don't look fine can be deleted, and the OWID PNG file used instead.

At least until Wikimedia fixes the font substitution problems. It shouldn't be substituting longer fonts for shorter ones. The sentence length after substitution should not be longer. Otherwise text that is close to the edge will go off the image.

Having the option to remove the import code may help with other SVG files people want to upload to the Commons, too.

OWID was trying to solve a problem of the wrong fonts being substituted on Wikimedia and elsewhere. The font substitution on Wikimedia was usually only a problem when text approached an edge of the image.

That's the general problem with SVG files: The more uncommon or unfree a specific font is, the more problems will arise when SVG files define non-generic font families (or don't convert characters into paths first to avoid the entire rendering problem but that of course makes changing text in the SVG file harder).

I think the import code is added to all OWID SVG files.

That is the underlying problem to solve on the OWID side. OWID should not do this.

At least until Wikimedia fixes the font substitution problems.

If there are specific problems with specific common free fonts being used in SVG files and not rendered correctly, please file specific bug reports. Thanks!

Having the option to remove the import code may help with other SVG files people want to upload to the Commons, too.

Again: I don't think that being able to upload SVG files with badly rendered fonts (due to stripped CSS) helps anyone?

Again: I don't think that being able to upload SVG files with badly rendered fonts (due to stripped CSS) helps anyone?

I agree. I rewrote the task title and description. Feature request now is for a preview of all SVG files before uploading is allowed to finish. And an option for MediaWiki to remove the bad CSS before the preview.

Could be an option though I'm afraid that's unlikely to be implemented.
I'd say it still makes more sense to solve the root problem: Not creating SVG files which load data from external URLs.

I think OWID knows about this already. But I will contact them again to be sure.

I can view their SVG file (with the import code) in all the Windows 10 Pro desktop browsers I have installed: Firefox, Edge, Chrome, and Opera. They all look the same. No warning messages. I thought browsers warn about most security risks.

The file without the import code looks different. Fonts are different on every line of text.

The file without the import code after upload to the Commons looks different from all the above. And all the fonts are sans serif fonts. Unlike all the previously mentioned file views which use a serif font for the top line.

in all the Windows 10 Pro desktop browsers

Different operating systems offer different (free or non-free) fonts. For example, I don't have a Windows machine around. :)

Different operating systems offer different (free or non-free) fonts. For example, I don't have a Windows machine around. :)

My understanding is that is why a font family list is put in SVG files. To have fonts for Windows, Apple, Linux, etc.. devices.

But there is the MediaWiki bug that it only sees the first font in a font family list. Per: T64986 (librsvg does not support fallback font set (more than one font family). And: T344564 (Font substitution for SVG file to PNG thumbnail replaces serif with sans-serif font).

That is why a preview function for all SVG files would be useful. Let's also change the last-resort font used by Mediawiki to the narrow version of the font. Or offer the option. That would fix the problem of text extending under logos, or past the edge of the screen.

Mediawiki already removes URLs from SVG files. Or more accurately, by converting to PNG files the links don't show up in clickable form. The SVG download still has the clickable links that show up when the SVG file is opened outside Wikimedia.

I don't see why Mediawiki can't remove "@import url" altogether.

I notified OWID about this thread.