Spec synthesis of viewBox/preserveAspectRatio for viewBox-less SVGs in image contexts

[fsoder]

Consider this a "prod" for ISSUE-2258 [1], which seems to have been lingering for a bit now. This is a behavior that I believe most UAs (browsers) implement to some degree already, but I don't think it's formally stated anywhere. If the integration spec will live on I guess that's where it'd go.

To expand, this is about synthesizing a viewBox and set preserveAspectRatio to none for SVGs embedded through <img> (and background-image, etc.) that do not have a viewBox specified, but does have width and height. Based on [2] this appears to be something that authors expect. Blink intends to try and align with what Gecko (and I believe IE/Edge) has implemented, since currently we only synthesize a viewBox. IIUC, Gecko also allows for percentage width/height. See [3] for Gecko bug and discussions, and [4](from [3]) for some examples. I hope that's enough context.

[1] https://www.w3.org/Graphics/SVG/WG/track/issues/2258 [2] https://crbug.com/110195 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=614649 [4] https://jwatt.org/svg/tmp/embedded-sizing/embedded.html

[nikosandronikos]

I haven't read all the supporting links (I'm currently packing to go on holiday), but isn't this covered by the Coordinates chapter? See https://svgwg.org/svg2-draft/coords.html#ViewportSpace and 8.2. Computing the equivalent transform of an SVG viewport

Essentially, the viewBox is now described as an additional transformation on the initial viewport, which is defined by the positioning properties.

[fsoder]

I don't see that it is. I'd expect that the issue here would provide input to the algorithm in 8.2 though (together with the initial viewport per 8.3.)

[AmeliaBR]

Yes, there's one piece missing.

We currently say that width & height can be used to define the intrinsic dimensions and intrinsic aspect ratio, but we don't make it clear that when the image is rendered at a size different from its intrinsic dimensions, it should be scaled to match.

As @fsoder suggested, one way to define this may be in terms of an auto viewBox that is derived from the width and height. Another way is in terms of an implicit transform or change in resolution, which is effectively how it works for raster images.

The complexity is that we have different behaviors for different embedding methods. Images automatically scale, even without viewBox, but objects & other embedded documents don't.

[fsoder]

I see that the SVG Integration document draft defines a "animated image document" which ought to cover the embedding method. <html:img> and CSS <image> values essentially (says that in an annotation.) Maybe that will be enough to key the behavioral difference off of?

[AmeliaBR]

@fsoder I'm in the midst of tearing apart SVG Integration, and merging what's worth keeping into SVG 2. That particular definition wasn't going to make the cut.

But I think I can cover this in the section about CSS sizing & intrinsic dimensions.

[jakearchibald]

Is the intent that <image> should scale in the same way as <img>? Currently Firefox will clip <image> rather than scale.

[dholbert]

To provide more context/details: @jakearchibald is asking about a case with an SVG <image> that points to an SVG file, and with no viewBox attribute in that external SVG file's root <svg> node.

If no viewBox is present, I believe the spec requires <image> to just present a cropped "window" into the inner document's user-space -- I don't think any any auto-scaling-to-fit is supposed to be done (in part because there's no defined boundaries or region to be scaled).

We could synthesize a viewBox, as we do for HTML <img>, but the SVG spec would need to define that. Perhaps it should, if all browsers besides Firefox do this currently? (Opera/Presto, v 12.16, actually matches Firefox's behavior, but perhaps that's not relevant since modern Opera is on Blink now.)

[AmeliaBR]

@dholbert

There are two different cases:

• if the SVG root element in the embedded file has none of viewBox, width, or height, then it has no defined dimensions from which to scale it. It would be rendered at the scale determined by the embedding element's coordinate system, and any overflow would be cropped.
• if the SVG root element in the embedded file doesn't have a viewBox, but it does have clearly defined dimensions from width and height, then I would expect that width and height to be used to scale the image, just as the intrinsic width and height on a raster image would be scaled to fit. However, this isn't clearly spec'd.

Either way, I would expect the same behavior for the same SVG file embedded with an SVG <image> or with an HTML <img>, with the exception that the SVG <image> applies a preserveAspectRatio value. But again, we should spec this more explicitly somewhere.

[dholbert]

@AmeliaBR That makes sense on an intuitive level, but (as you note) it's not what the spec says right now. :)

I'm looking forward to seeing this clearly-defined somewhere!

[dirkschulze]

@AmeliaBR Consider this for SVG 2?