I would decline this request. The creator should always specify a size.

Neither MW nor any other user agent should compute the bounding box to use as the width and height. That is also a poor method of finding the width and height because it would trim margins.

All SVG files should have a viewBox attribute. For me, the width and height should only be specified if the image is intended to be rendered at a fixed size. For example, an eye test chart might specify its dimensions in millimeters. An image of a ruler might specify its dimensions in physical units (rather than abstract pixels) so the ruler gives accurate measurements.

When MW is given an SVG file that that does not specify its viewBox, then MW assumes it is "0 0 512 512". That is not a bad assumption. Many systems have been confronted with this problem and chosen an arbitrary size. A common assumed size is "0 0 300 150".

The SVG Working Group has confronted this issue and chosen 300 by 150. See https://svgwg.org/specs/integration/#svg-css-sizing which states,

• If any of the sizing attributes are missing, resolve the missing ‘svg’ element width to '300px' and missing height to '150px' (using CSS 2.1 replaced elements size calculation).

MW could make that the assumed size, or MW could continue to use 512 by 512px. However, an assumed size of 300 by 150px would not work with the given test image (which probably wants 480x360 (4:3 ratio)).

@Glrx I agree in general it would be poor method to not define dimensions, however it is valid example from the W3C-Test-suite, therefore MediaWiki should take the dimensions of librsvg. And it is imho not the creators fault, that is done on purpose in the official test-suite. If it is not supported it is a bug!
I know it is a hardly supported feature, however it is more a general problem.
For example if librsvg renders an image in 512x383, but due to rounding-errors MediaWiki assumes 512x384, it should not get distorted, it will make the image blurry.
The image should imho be embedded without height="..." or with object-fit="none", or anything else that does not change the aspect ratio,

Assuming anything such as viewBox="0 0 512 512" or viewBox="0 0 300 150", is ok as long as the image don't get distorted, so librsvg and MediaWiki need to have the same dimensions or use object-fit="none", I don't care what the values are, but the two must agree!
@Peachey88 : It is imho no SVG-rendering-issue, the SVG is rendered correct it only wrong embedded in MediaWiki. Or do you want to force librsvg to render with the viewBox assumed by MediaWiki?

In T279241#6970866, @JoKalliauer wrote:

@Glrx I agree in general it would be poor method to not define dimensions, however it is valid example from the W3C-Test-suite, therefore MediaWiki should take the dimensions of librsvg. And it is imho not the creators fault, that is done on purpose in the official test-suite. If it is not supported it is a bug!

The W3C test suite is testing a corner case where the creator did not specify a viewBox and has default values of 100% for width and height. The purpose of the test is to see that x and y attributes are ignored. Here are some details from the SVG file:

• This test validates the operation of the svg element when there is no viewbox.
• The document has x/y attributes set to (1000, 1000). Because x/y are ignored on the root svg element, the x/y origin should have no effect on the drawing.
• The document contains squares and circles between the (100,100) and (200, 200) coordinates.

In other words, this test is designed to test just x and y. If the attributes are not ignored, then the resulting image will have the squares and circles pushed to the left and down (and possibly off the imaging area). MW and librsvg clearly pass the intended test.

Nothing in the test suggests that it is testing the user agent's ability to compute an intended width and height of the image.

I know it is a hardly supported feature, however it is more a general problem.
For example if librsvg renders an image in 512x383, but due to rounding-errors MediaWiki assumes 512x384, it should not get distorted, it will make the image blurry.
The image should imho be embedded without height="..." or with object-fit="none", or anything else that does not change the aspect ratio,

Sensible rendering of a scalable image can only happen if the creator specifies the original's size. MW looked at the file, did not see any dimensions, so MW assumed 512x512. MW builds the image transclusion assuming that is the correct dimension: MW expects the scaled image to be 120x120 pixels. MW builds a URL specifying a 120-pixel width:

• https://upload.wikimedia.org/wikipedia/commons/thumb/4/42/W3C_SVG_11_TestSuite_struct-frag-04-t.svg/120px-W3C_SVG_11_TestSuite_struct-frag-04-t.svg.png

When that URL is sent to the image server, librsvg is called to make an image 120 pixels wide.

Now I'm guessing. librsvg does not find the image dimensions in the SVG, so librsvg makes its own image size assumptions. That assumption has a 4:3 aspect ratio (possibly from the bounding box dimensions created by the 478x358 1-pixel stroked rect). Consequently, librsvg builds a PNG that is not 120x120 pixels but rather 120x90 pixels.

The browser then scales that 120x90 PNG to fit into the img element's 120x120 size. Consequently, the squares and circles become rectangles and ellipses.

The creator did not specify the original size, so the image got distorted.

MW probably made a conscious decision to specify the img element height. That decision allows the browser to compute the page layout before it has read the PNG file. That can give the user a better experience.

I do not know enough to take a position on object-fit: none;. Turning off scaling would fix the distortion in the case above, but it could have other consequences.

The problem only arises if the creator did not specify a size, and those cases should be rare. If the creator does not specify a size, then scaling the image (what SVG is all about) is indeterminant.