I don't see where "source image dimension" are defined for this case, but looking at step 2 at https://html.spec.whatwg.org/multipage/scripting.html#drawing-images :

"If the sx, sy, sw, and sh arguments are omitted, they must default to 0, 0, the image's intrinsic width in image pixels, and the image's intrinsic height in image pixels, respectively. If the image has no intrinsic dimensions, the concrete object size must be used instead, as determined using the CSS "Concrete Object Size Resolution" algorithm, with the specified size having neither a definite width nor height, nor any additional constraints, the object's intrinsic properties being those of the image argument, and the default object size being the size of the output bitmap. [CSSIMAGES]"

Which would seem to imply that we would end up with a 'contain constraint' (per https://drafts.csswg.org/css-images/#default-sizing), which seems to match what Blink renders? (I've not observed any of the "rare" cases where it "draws correctly")

But the sx, sy, sw and sh parameters are provided. Unless the first sentence of this paragraph has no relationship to the second.

Yes, they are provided, but what are they relative too - i.e what is the "full size" of the source image? This also comes into play in: "When the source rectangle is outside the source image, the source rectangle must be clipped to the source image..."

In https://html.spec.whatwg.org/multipage/scripting.html#image-sources-for-2d-rendering-contexts it says:

 "When a CanvasImageSource object represents an HTMLOrSVGImageElement, the element's image must be used as the source image."

and

 "When a CanvasImageSource object represents an element that is being rendered and that element has been resized, the original image data of the source image must be used, not the image as it is rendered (e.g. width and height attributes on the source element have no effect on how the object is interpreted when rendering the image for CanvasRenderingContext2D APIs)."

Which I interpret as HTMLImageElement.width/height should not be considered here, and hence we use the "Concrete Object Size Resolution" algorithm, which, I believe would yield source image dimensions 200x200.

So with an SVG image as the source of an <img>, then the intrinsic size of an SVG image should be used at all times? That seems kind of odd to me since the use of SVG to draw into a canvas is appealing for authors because they can have the image scaled to fit any element size.

If I read the description correctly, it seems to be assumed that the viewBox should give an external coordinate system. It does not. It only defines the internal coordinate system and the aspect ratio of the SVG image, in case width and height information is missing.

As fs writes, the SVG in this case will be sized to the canvas size (200x200 as it has 1:1 aspect ratio) and the source coordinates will be relative to this resolved image size. The 100x100 size is not used (it's mapped to width&height attributes and does not contribute to the intrinsic size).

I agree this is not super intuitive, but as far I can tell it's working as expected according to the specs.

So if the canvas was sized to be 500x500, the SVG would be sized to match and be 500x500 as well, taking the size of the canvas as the size to render into?

Antoine

In particular case (no intrinsic dimensions), yes.

Great. But if the root <svg> element provided width/height attributes, then it would be a different story. I guess the rendering is perfectly valid then!

Well, "as specified" at least ;-)