世界を動かす技術を、日本語で。
ワークアラウンド: https://simonsocolow.com/tech/uploading-svg-to-google-slides...
彼らは完全にサニタイズできるはずなのに、ガジェットプロキシの時と同じように、古いリクエストを修正することを選ばないんだ。私のシートにデータURLサポートを追加するためのチケットみたいに、毎年先送りにされてる。
最初に思ったのは、「実際の使用ケースの90%をカバーするかもしれない小さなサブセットの SVG をサポートする」ってこと。SVGには「塗りつぶしのあるパスの集まり」と「ちょっと危険な賢いもの」の2種類があると思うけど、ほとんどの実際のSVGは前者だよね。これについて120秒以上考えた人に否定されるのを期待してるよ。 :)
ちなみに、同じことを考えたよ。好きな部分をパース（検証はしない）して、入力を再構築または拒否するって感じ。
これがブラウザレベルで新しいフォーマットとして実装されるのが一番いいんじゃないかな。そうじゃないと、「ユーザースペース」で扱うのはすごく遅くて面倒になると思う。
アニメーション付きの SVG は、サニタイズ後にアニメーションが全部消えちゃうことが多い気がする。
あなたの言う通りだと思うけど、こういうことに対する業界標準がないのが致命的だね。人々は、自分が使っているツールから出力された SVG をブラウザに入れたいと思っている。それは不当なリクエストじゃないよね。でも、ツールが何かの obscure SVG 機能を使っている場合、それがフィルタリングされない保証はない。OpenGL と OpenGL ES のような合意された標準が SVG にもあればいいな。SVG-ES。静的でスクリプトなしの要素についてはみんな合意していると思う。
誰かがもう君のアイデアを実装したみたいだよ。 https://tinyvg.tech/
最初に思ったのは「おそらく90%の実際の使用ケースをカバーする小さなサブセットのSVGをサポートすること」だね。リンク先の投稿は、ホワイトリストの代わりにブラックリストを使っている人についてだったみたい。認識できないものを通すなら、サブセットがどんなに小さくても関係ないよ。ほとんどのSVGは安全だし、危険な部分はかなり明白だよ。スクリプトタグ、イメージタグ、feImageタグ、onで始まる属性、HTMLを埋め込むこと、DTDトリック、名前空間トリック、外部のものを読み込むCSS（プレゼンテーション属性も考慮してね。スタイル属性/タグだけじゃないから）。残りはかなり安全だよ。
BIMI/VMCのように、一部の実装で使われているSVG Tinyプロファイルがあるよ。
大人がいないとこうなるんだよね、プロジェクトの過剰拡張が起きる。SVGはスクリプティングをサポートするべきじゃなかった。SVGでスクリプティングが必要なら、別のファイルフォーマットにすればいい。ほとんどのユーザーがロゴをシャープに見せる方法を探していただけなのに、どれだけの時間が無駄になったか想像もつかないよ。
ちなみに、Google スライドが SVG サポートを持っていない理由は、15 年近く前からその機能をリクエストするチケットがあるのにね。