Should HTMLOrSVGImageElement be a mixin?

[vmpstr]

Current HTMLOrSVGImageElement is defined as a typedef:
https://html.spec.whatwg.org/#2dcontext

typedef (HTMLImageElement or
         SVGImageElement) HTMLOrSVGImageElement;

There is desire to have some shared functionality between HTML and SVG image elements, specifically the decode() function (see w3c/svgwg#373).

As proposed in the w3c/svgwg issue by @AmeliaBR I think it makes sense to convert the typedef into a mixin with decode() currently being the only common function.

There is also some discussion about things like intrinsicSize or some notion of an aspect ratio that could likely be a part of the shared interface as well.

Does anyone have any thoughts or objections?
/cc @chrishtr @annevk @domenic

[domenic]

This doesn't make a lot of sense to me. It seems like pattern-matching on the name, gone wrong.

HTMLOrSVGImageElement has a distinct usage in the spec, to provide a way of allowing canvas images to be drawn with either an HTML or SVG image element as the source.

Separately, folks may be interested in defining some functionality that applies to both HTML and SVG images, perhaps via a mixin. But that's not the purpose of HTMLOrSVGImageElement, and making HTMLOrSVGImageElement into a mixin would break its current usage sites.

So, I think perhaps people want to define a completely new ImageElementUtils mixin or something. But that's completely unrelated to the existing, separately-useful, HTMLOrSVGImageElement. (It also would be a decent amount of work, abstracting out the processing model for image elements to figure out which parts are common and could be shared, so that any methods defined on the mixin actually work.)

[vmpstr]

Hmm. Yeah it's pretty confusing since HTMLOrSVGElement (https://html.spec.whatwg.org/#htmlorsvgelement) is in fact functionality shared between HTML and SVG elements defined as a mixin. It seems that the names of the two constructs (HTMLOrSVGElement and HTMLOrSVGImageElement) are a bit too similar to serve such different use cases.

Do you think that this should remain this way? One possibility is to rename the typedef used in canvas context to something more specific, eg HTMLOrSVGImageSource, and still maintain the proposal that HTMLOrSVGImageElement would be a new mixin for shared functionality? Or do you still think that something along the lines of ImageElementUtils would be a better fit here?

[AmeliaBR]

I do think it would be helpful to have a mixin for shared functionality, because we want new features like decode or intrinsicsize to automatically be added to both elements where it makes sense, without requiring the SVG spec to always be playing catch-up to HTML.

But, if mixins can't be used like a typedef/abstract interface for defining argument types to functions (meaning: this function accepts any class that implements this mixin's members), then we would still need the typedef — and we have a name clash.

[domenic]

One possibility is to rename the typedef used in canvas context to something more specific, eg HTMLOrSVGImageSource, and still maintain the proposal that HTMLOrSVGImageElement would be a new mixin for shared functionality?

This seems reasonable. But again I stress that the hard part of defining the mixin is figuring out which parts of the massive https://html.spec.whatwg.org/multipage/images.html#images-processing-model can be shared by SVG and HTML, such that any methods or attributes defined on the mixin operate on that shared core.

[vmpstr]

That makes sense. I can see how decode() definition would be somewhat problematic without addressing this since it references updating the image data and the like, which relies (as an example) on attributes such as src or srcset, which are not in the SVGImageElement.

I think changing the processing model is a pretty large undertaking, but it seems that it's something that we want going forward.