We're trying to converge <hgml:img> and <svg:image> as much as we can, as I understand.

This bug was cloned to create bug 18220 as part of operation convergence.

Is there a spec I can point to that defines the <svg:image> processing model? The stuff like "available", interaction with the network, CORS, event loop, etc?

No, but if you can tell me the list of things that I need to define (and what terms to link to from the HTML spec) I'll do the SVG spec changes needed.

I don't know exactly what it needs, but here's the equivalent section for the <img> element in HTML:

   http://www.whatwg.org/specs/web-apps/current-work/#the-img-element

The stuff I need for drawImage() specifically is the same stuff as what I need for ImageBitmap, which may be easier to isolate — see the section that says "If image is an img element" here:

   http://www.whatwg.org/specs/web-apps/current-work/#images

...specifically, the equivalents of:

   "completely available"
   "origin"
   "media data"

(In reply to comment #5)
> I don't know exactly what it needs, but here's the equivalent section for
> the <img> element in HTML:
> 
>    http://www.whatwg.org/specs/web-apps/current-work/#the-img-element
> 
> The stuff I need for drawImage() specifically is the same stuff as what I
> need for ImageBitmap, which may be easier to isolate — see the section that
> says "If image is an img element" here:
> 
>    http://www.whatwg.org/specs/web-apps/current-work/#images
> 
> ...specifically, the equivalents of:
> 
>    "completely available"
>    "origin"
>    "media data"

I'm not sure that this is needed. The svgsvgelement [1] is like the HTML canvas. The element and all of its descendant are part of the document and available.

1: http://www.w3.org/TR/SVG/struct.html#InterfaceSVGSVGElement

We're not talking about <svg:svg>, we're talking about <svg:image>.

(In reply to comment #7)
> We're not talking about <svg:svg>, we're talking about <svg:image>.

I didn't catch that. I don't think there's a big demand for such a feature.

bz, it seems this didn't get the interest we need to add this to HTML. Let me know if you want me to reconsider.

+junov just in case Chrome is interested in this.

My understanding is that the SVG working group is actively trying to converge its "duplicated" elements with the corresponding HTML ones.  Given that, it seems like we should treat them identically; pretty much anything else is rather author-hostile.

In particular, it seems to me that <svg:image> should use the same processing model as <html:img> and hence this should all be quite straightforward to spec.  And probably implement; in Gecko all the logic is shared and hence the work to support <svg:image> here is tiny; I would be surprised if it's very different in other browsers.

Okay, happy to reconsider. I guess we could check all the places that accept HTMLImageElement and make them accept SVGImageElement too.

I don't think we necessarily need to wait on SVG to sort out their standard if we all know it's supposed to work identically (though we should maybe point that out with a note until things are sorted).

Justin, what do you think?

Yes, I think this makes sense. To match use cases of HTMLImageElement, I think we should add SVGImageElement to the CanvasImageSource and ImageBitmapSource typedefs, which implies supporting it as an argument to drawImage, createPattern and createImageBitmap.

Created a pull request: https://github.com/whatwg/html/pull/900.