Most browsers scale the SVG image to the dimensions of the <img>/<image>, but use the dimensions of the <img>/<image> as the viewport for media query purposes.
Firefox differs. For <image> it renders the SVG at its intrinsic size then clips to the <image> width and height. It uses the dimensions of the <image> as the viewport for media query purposes. For <img> it scales the SVG image to the dimensions of the <img> as above, but it uses the device-pixel dimensions for media query purposes, meaning different media queries activate as devicePixelRatio changes.
I can't see where these rendering characteristics are defined, apologies if they are.
The text was updated successfully, but these errors were encountered:
This is related to #249, in that they both address undefined aspects of how SVG scales to fit when used as an image.
For media queries, I would expect that dimensions are always measured in CSS pixels, and device pixel ratio would only show up in resolution queries. Where it gets confusing is when you're drawing an image into a scaled coordinate system (e.g., another SVG with a viewBox, or a CSS img that has had a transform applied, or a canvas where the bitmap size doesn't match the rendered size in CSS px). The issue with canvas, of course, is that there is currently no way to set high dpr other than to double the bitmap size and scale down.
Yeah, definitely part of #249. Sorry, I didn't see that on a quick search of the issues.
My gut feeling is that transforms shouldn't change the viewport size of SVG as scaling an iframe doesn't.
With bitmap APIs like <canvas> and createImageBitmap, I think it's important that the developer can control the viewport and drawn pixels independently. This is why I'm rooting for Edge's behaviour in whatwg/html#1880, and proposing options for createImageBitmap in whatwg/html#1881.