Every browser has 2 zones: website controlled, browser controlled. There are many reasons why don't want any dynamic, website controlled content outside of website zone, inside browser zone.
I'm supposing Safari's SVG implementation when moved to supporting favicons meant there were security holes, probably scripting exploits, but also potential XML exploits, so they removed until they could fix these, with a probable low priority.
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.
An SVG doesn't need to support scripting. When you load an SVG through an <img> tag for example, no <script>s run either (only if you use <iframe>, <object>, or inline in HTML5). When you serve the SVG (or the HTML it is inlined in) with a CSP that doesn't allow inline scripts, no scripts run. 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.
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.
You really want to support different file formats to maximize support. You can have additional favicons as fallback if SVG isn’t supported. This page has some info on that: https://atlasiko.com/blog/web-development/favicon-size/
Couldn't agree more. I'm using it for notifications, where icon colour changes depending on the type of notification (colours are also user editable) ... and the notifications can be disabled :)
