on edit: ok evidently that was a stupid assumption on my part, as it got a downvote - why is it stupid though? SVG inline needs to support scripting, SVG is XML - if Safari's SVG implementation meant that SVG favicons were open to either XML exploits or scripting exploits that were not adequately handled in the first release (because sitting in the browser chrome part of code instead of web site part of code) then they might have pulled it back quickly until they could fix that.
No shit? I bet that's what I meant when I said "SVG inline needs to support scripting" then?
>It's totally possible to render an SVG without scripts (most SVGs do not contain scripts) and various mechanisms for this are already implemented in browsers.
Yes it is totally possible to render an SVG without scripts, and it is also possible to render them with, hence when I say something like "if Safari's SVG implementation meant that SVG favicons were open to either XML exploits or scripting exploits" that IF is a real important indicator that hey, if they did it as an inline SVG but now it is sitting inside the browser chrome with heightened permissions it would be a problem, furthermore, the XML exploits available in the browser chrome might also be more deadly.
But why would they do this? Hey I don't know, I have noticed that sometimes people do dumb things, including browser developers, or they don't catch edge cases because they don't realize them.
I also noticed that one of the comments as to what had been implemented was support for SVG favicon as a data uri, if an SVG favicon was implemented in this way it might very well be the edge case that the data uri exists as an "inline" image. Seems unlikely because data uri should normally be in an img tag, but I have also experienced some unlikely or unexpected things with data uris before so I would think it a possible place for things to go wrong.
And here’s a helpful generator for converting SVG to all the other file formats: https://favicon-generator.s2n.tech/
move-on-by•8mo ago