Update SVGScriptElement and SVGImageElement to use src?

[dstorey]

Is there any reason why when deprecating xlink, we didn't allow src to be used for images and script? Currently this is confusing that href is used in SVG and src is used in HTML.

Assuming there are no issues, we could add src to these two interfaces, deprecated href, and do the same as xlink:href and href, where (to borrow a CSS term) src is more specific than href and href is more specific than xlink:href.

This gets around the SVGAnimatedString mess for these two interfaces, and will be especially important if we ever want to adopt srcset in the future (using href as a fallback for srcset would be weird).

[prlbr]

Just href seems to be cleaner and easier than having to remember where to use href and where to use src though. It may be a bit confusing that it is different from HTML, but I don’t think that HTML does a better job at this than SVG.

I think the analogy between SVG <image> and HTML <img> is weak. If it’s confusing to have different attribute names for referencing the external content, isn’t it confusing to have different element names then as well? Or do different element names justify different attribute names?

[AmeliaBR]

I think this was the last discussion thread, from waaay back in 2015, when discussions were on the mailing list.

For <image>, switching to src would break a commonly used fallback approach:

<svg><image src="icon.png" xlink:href="icon.svg" width="16" height="16"/></svg>

(An <image> outside of <svg>, or in a browser that doesn't support inline SVG, is treated as a synonym of <img> in HTML.)

I personally think that adding srcset is much more useful moving forward, (see #208).

It's possible that authors were using the same trick for <script> to load different scripts depending on whether SVG is supported or not, although I'm not familiar with any examples. But it also didn't make much sense to change <script> if we weren't going to change <image>.

[dstorey]

@prlbr it doesn`t really matter if HTML or SVG does a better job; a lot more developers know HTML than SVG and so would be the most expected behaviour. The DOM would be consistent is we went with src but indeed the tag name would be different. If it is possible to use src then perhaps we could look at aliasing img/image like HTML does.

@AmeliaBR that is unfortunate :( (another case of non-standard usage biting us). Do we have any data on if that technique is actually popular or if it is just a few early adopters? We can't use the normal detecting if SVGImageElement.src is in use cause that of course is not supported. ChromeStatus is broken for me right now (showing an empty list) and I don't recall if it shows Content attribute usage or just IDL attributes. Although it probably isn't measured anyway with it being non-standard usage.

I have fallen for the lack of src on SVGScriptElement myself recently (I assumed that was why the test case template uses html:script rather than SVG scripts until I looked at the spec and saw the href mixin. It would be kind of weird to fix script but not image though.

[boggydigital]

Not blocking updated 2.0 CR publication - assigning 2.0 Recommendation milestone to clean this up before 2.0 REC