SVGに対する誤解を紐解く

憎きieがようやっと世代交代するにあたり，今年こそSVG元年となるべく，(個人的に)頑張らにゃいかん，そんな気がするんですが，そうは行っても世間的にはsvgはまだまだマイナーな存在であってwebを眺めると結構な思い込みとか偏見とかが見受けられます．まぁ別に構いやしないんですが，SVGのポテンシャルを引き出すにはより良いSVGへの理解は必須ですから，ひとつ私見ではありますがよくあるSVGに対する誤解に意見してみようかと．

つーかHIT数多すぎてびっくりしているんよ
ちょこちょこ追加していくよ
Thanx @rikuo .

注意・2014/01/16
この記事はある程度SVGについて調べた上で読むことをおすすめします．そうすることでSVGを”理解した後に生まれてくる”数々のモヤモヤが解消することでしょう．（筆者もかつてそうでした）
逆にSVGに不慣れな人が読んだ場合，却って理解を妨げる危険があります．

SVGは最近出来た仕様だ

いいえ．SVGの仕様については初版が既に2001年に定められており歴史のあるものです．それがここ最近話題に上がるようになったのはSVGがHTML5仕様に組み込まれたことで急速に実行環境が整ったことによります．

SVGはIEで動かないから使い途がない

いいえ．IE9から標準サポートされています．ですからIE8以前の環境（=windowsXP等）がサポート外となればHTML5標準であるSVGを使わない手はありません．

SVGを動作させるにはAdobe svg viewerが必要だ

かつてはそうでした．が，現在ではSVG仕様がHTML5に取り込まれたことでほとんどのWEBブラウザでSVGをプラグイン無しに直接表示することができます．
※しかし，SVGを古い仕様のまま扱っているWEBサイトにおいてはSVGが正しく動作しないこともあります．この場合，その旨をWEBサイトの管理者に伝えたほうが良いでしょう．

SVGは文句なく使える，何も問題なく使える

いいえ．SVGの普及は始まったばかりであり様々な面でノウハウが不足しています．特にブラウザ間の互換性の面で顕著です．だからこそSVGを積極的に利用し，テストケースを増やすことでSVGの問題点を明らかにする必要があります．

SVGはデザイナー向けの技術なのでエンジニアには関係ない

いいえ．むしろエンジニアにこそ知ってほしい技術です．単に画像を描画するだけでなく，不定形なリンクを定義したりUIの部品化が行えたりと既存のHTMLだけでは不可能だった自由な作りこみが可能になります．そのため少なくともSVGの仕組みや機能についてはざっと目を通しておく事をおすすめします．

SVGの仕様を読めば楽に開発できる

いいえ．w3cの仕様自体非常に難解である上，これまでに多くの仕様変更を伴っています．その中にはパージョン間の非互換を伴うものも含まれています．その結果古い仕様が多量にログとして残っているため，闇雲に調査しても無駄になる公算が高いです．
なおWEB上でSVGを利用するだけであれば現状ではSVG1.1仕様第二版(SVG1.1SE)と呼ばれるものを使えばほぼ間違いありません．但しこれについても現在SVG2という次世代仕様が控えており，既存の仕様が大幅に分割整理されることとなっています．HTML5と同様SVGについても生きた仕様であることを忘れてはなりません．

SVG2が出るのならそれまで待ったほうが良い

果たしてそうでしょうか?SVG1.1SEですらWEBブラウザ側のサポートが進んだのはここ数年です．しかもsvg2では多くの仕様改修が発生するため実際にブラウザ上で利用可能となるには長い開発期間が必要となるでしょう．つまりSVG2の実現を待っていてはいつまで経ってもSVGを使えない事になります．それよりも現在利用可能なSVG1.1SEを使い倒し，開発者にその実行結果をフィードバックしたほうが長い目で見れば実装者側・利用者側共に良い結果が得られるでしょう．

SVG2まだー？

残念ながら「SVG2」仕様として確定することが無理な情勢です．現状SVGとHTML+CSSとの間には多くの重複した機能が存在しており，W3Cにおいて内容の整理・統合を行っています．従って「SVG2」の意味合いが，「SVGとしての新機能」というよりも「SVG+HTMLの統合環境としての新機能」と言った色合いが濃く，SVGだけの文脈で解釈することが難しくなりつつあります．従ってHTMLがリビング・スタンダードであることからSVGも同様であると解釈したほうが良いと思われます．
実際，SVG2における「色合成」「transform3d」などについては部分的にですが動作する環境が現れています．
※もちろんブラウザ互換性の観点からは使い物にはなりませんが

SVGなんか知らなくても生きて行ける

残念ですが，そうも言ってられません．次期SVG2仕様はHTMLと完全に統合されます．従ってSVGを無視しているといつの間にかHTML仕様として膨大な機能が追加されてしまい，学習するきっかけを掴めないままとなってしまうでしょう．
従って今からでも遅くはありません．少しづつでも良いですからSVGのつまみ食いをしておきましょう．そうすることでいざSVGを使わざるを得ない場合においても，適切な利用・応用が叶うはずです．

SVGは難しい

いいえ，そんなことはありません．確かに仕様自体は洒落にならないほど巨大なものですが，頻繁に用いるものはごく限られています．むしろそれ以外の（理解するのが難しい）仕様は現状では用途及び利用可能な環境が限られてしまうため，それほど重要ではありません．

SVGはマークアップ言語なので習得は簡単だ

確かにSVGは難しくはありませんが，簡単というわけでもありませんよ．
SVGの要素は単体で利用するよりも複数の要素を組み合わせて利用することが多く，SVGに習熟するにはむしろそのバリエーションを憶える必要があり，この点でHTMLよりもはるかに面倒と言えます．
また，処理の内容によっては使う側のセンスや画像処理に関わる一連の知識が問われるケースもあり，一筋縄ではありません．
SVGは「入り口こそ広いが，究めるには相当の労力が必要」 なのです．
※先ほどの回答のように，よく使う要素は限られているのですが，その組み合わせによってはアッという仕組みを実現することが出来るというのがSVGの醍醐味と言えます．
※HTML5では更にインラインSVGとしてHTMLの要素（+CSS）×SVGの要素（+CSS）と言った組み合わせまで考えられますから，これだけでも一筋縄ではありません．

SVGはベクタ画像形式の一つである．

大方あっています．が，個人的にはむしろSVGは「XMLで定義された2次元画像描画フレームワーク」と言ったほうがしっくりします．技術的にはHTMLに最も近く，外部画像やメタデータを挿入することが出来るなどの”画像であり(XML)文書である”点が最も重要です．
確かにこの点において他に例を見ない特徴を持つため，SVGをイメージしにくいのは仕方ありません．ですが見方を変えるとHTML文書もSVG文書もWEBブラウザを通してスクリーン上に”画像として”表示されることに違いはなく，単にタグ文法が異なるだけとも言えます．極端な話，既存のHTMLで記述されているWEBページをそっくりSVGで作りなおすことも出来なくはありません．
※もちろんHTML固有の仕組みを除いています．

SVGとjpg画像とは相容れない関係にある

いいえ，そんなことはありません．よくSVGを説明する手段としてベクタ画像とラスタ画像の比較を挙げる場合がありますが，これはSVGの一面に過ぎません．SVGにはグラフィックを扱う上での包括的な仕組みが定められており，その中にはラスタ画像の扱い方も含まれています．つまり，SVGはラスタ画像と組み合わせて利用可能であり，この点で他のベクタ画像形式と一線を画しているのです．
※先ほど示した通り，SVG≒HTMLと考えてください．従ってSVG形式とjpg形式とは厳密には比較が出来ないもので，この思いがSVGの「Scalable（様々な場面で使える） Vector Graphics」の部分に込められています．単なるVector GraphicsであればScalableである必要はないのです．

SVGは軽い

一概にそうとも言えません．SVGには画像を描画する手順が記されており，SVGの（ファイルサイズ・描画時間等の）重さ・軽さはその手順の複雑さに依存します．よって理屈上は「10px平方の画像ファイルのサイズが100MB」といったケースも考えられます．
つまり，SVGを利用する場合はどうしたら（ファイルサイズ的にも動作パフォーマンス的にも）軽くなるかを常に意識する必要があるのです．
従って，巨大な領域に単純な図形を描画する「だけ」であればSVGは最良の選択となり得ますが，イラストレーター等のツールによる「豪華な」ベクタ画像をそのままwebで利用するのは余りに無謀と言わざるを得ません．

SVGは重くて使い物にならない

果たしてそうでしょうか？もしかしたらそのSVGファイルはまだ最適化の余地があるかもしれません．得てしてツールで出力したSVGコードには無駄な部分が多く，これらを整理するだけでも大幅に動作速度が改善する場合があります．この部分はWEB上でSVGを扱う上での必須事項ですから無視してはなりません．
※SVGの動作を軽快にするには，パスを統合する，要素数を減らす，重い処理を省く，精度を落とす等のテクニックが存在します．

SVG画像はいかなる変換を行っても劣化しない

いいえ．一般にベクタ画像といえど誤った変換（例えば座標を直接書き換えるなど）を行えば幾らでも画像は劣化しえます．但しその劣化具合は肉眼では確認出来ない程度のものですから，実用上は問題ないと言えます．ですが，画像の精度が重要視される環境では注意すべきです．

SVG画像はいかなる環境下においても同じ画像を定める

いいえ．HTMLと同様にSVGによる描画結果は必ずしも同じものにはなりません．一口にSVGをサポートすると言っても，どこまでサポートしているかについては環境毎に異なります．これはCSSのサポート状況がブラウザ毎に異なることと同じです．従ってどの機能までを利用するのかの選定が必須になります．

↑ってバグじゃないの？環境毎に出力結果が異なったら使えないじゃん

そもそもSVGは画像の表現の仕方を仕様化しただけで，それをどのように解釈するかは原則それを扱うアプリケーションの勝手です．確かに大枠についてはこう解釈しなさいと言った制約が課されていますが，それだけの話です．
従って，どの環境でも同一の出力結果が得られることが最優先事項なのであれば，おっしゃるとおりSVGは全く使い物になりません． そのため，HTMLと同等の動作検証が必要となるわけです．SVGファイルが作れたから作業終わり！とならない点でラスタ形式の画像と異なります．

SVGを使えば常に解像度に依らない美しい出力が得られる

いいえ．画像処理の内容によってはいかなsvgといえども画像がボケると言った品質の劣化が起こりえます．典型的にはfilter処理を行った場合，パターン敷き詰めを行った場合等が挙げられます．また印刷処理についても気をつける必要があります．いずれも図形のラスタライズのタイミングに起因するもので，回避する方法はありません．

SVGは他の画像形式と同じくセキュアだ

いいえ．SVGには任意のスクリプトを挿入可能であるなど，jpgやpngと言ったラスタ画像形式よりもHTML文書に近いものです．従って扱い方によってはHTMLで引き起こされる問題と全く同等の事象が起こりえます．またSVGに対する研究は始まったばかりであり，未知のセキュリティホールが存在する可能性すらあります．
※jpeg画像ですらexifヘッダの問題があることを鑑みると，より実行可能性の高いscript要素が含まれているケースを忘れてはなりません．よって，入手ルートの定かではないSVGファイルを不用意に開く，ないしはWEBサイトに配置（リスクの拡散）すると言った行為は慎みましょう．

画像投稿サイトがSVG形式をサポートしないのはけしからん

そう短絡的に考えないでください．これまで見たようにSVG形式のファイルとjpg/png画像ファイルとは根本的に異なるものです．従って新たにSVG形式をサポートするには専用の仕組みを構築しなければならないという事情があるのです．SVGはカジュアルに使える反面，きっちり作りこまないと思わぬセキュリティーホールを開けてしまう危険性があり，現状でのSVGの普及具合を鑑みるに，未だリスクとリターンのバランスがよくありません．この状況はSVGに対するノウハウが蓄積していくうちに改善していくことでしょう．

スクリプトでSVGを扱う場合，全てをスクリプトで記述せねばならない

いいえ．HTML文書を全てスクリプトで構築する必要が無いように，SVGにおいても静的な部分と動的な部分とに文書を整理し，動的な部分のみをスクリプトで操作することができます．d3.jsやSnap.svgを利用する場合も同様です．ライブラリに精通することも大切ですが，SVGの仕様を理解することも重要です．

SVGが判らなくてもSnap.svgとかSVG.jsとかは使えるよね

いいえ，全くそんなことはありません．たとえ高機能なライブラリを用いたとしても，SVGとしての概念・機能・構造を理解しておかなければ全く使いこなせないでしょう．SVGはそれ自体がグラフィック描画フレームワークであり，その上で動作するライブラリは煩雑なSVGDOM操作に対するシンタックスシュガーを与えるものに過ぎません．（ここがcanvas要素と趣を異とする部分です）
従ってライブラリを導入することで（プログラム的な）SVGに対する習熟速度の向上（つまり学習コストの削減）をはかるのは大きな間違いです．ライブラリ固有の「方言」が加わることで，却って学習の妨げとなるでしょう．
ですから面倒でも簡単なSVGを手書きすることから始めましょう．動作する成果物（SVG構造）をイメージできれば，その結果を得るためにどのようなスクリプトを描く必要があるかは自ずと定まってくるからです．

既存のライブラリとSVGとを組み合わせて開発効率UPだ！ 

そう単純な話ではありません．いかなjQueryやSCSS等の手に馴染んだツールを用いたとしても，SVGそのものへの理解が不足していれば，いざ不具合が起きた際にどの部分に問題があるかを特定することに手間取ること必至です．（ツールを正しく使えていてもSVG仕様で躓いている場合など）
SVGの”名人”であるならともかく，慣れないうちにHTMLと同じ感覚でSVGを扱うことはこの上ない危険な行為です．特にSVGの出力をツールでしか行ったことがない方は要注意です．
※とは言え，はまりやすいポイントは自ずと限られてくるため，ノウハウが蓄積してくれば作業効率の大きな向上が見込めます．

SVGを手で記述するなんて変人の仕業だ

いいえ．SVGのパワフルさを引き出すのであればHTMLと同じくSVGを手で記述することは避けられません．確かにパス図形を定義するにはツールを使うべきですが，それだけがSVGであると勘違いしないでください．SVGには「画像を定義する仕組み」の他に「画像を制御する仕組み」が組み込まれており，後者をサポートしているツールは現状存在しません．なおSVG自体は手でも十分に編集可能であるように設計されています．
※このようなツイートを読んでちょっと凹んだのは秘密だ．SVGを手書き出来るようになるとスゲー便利なんですけどね…

アイコンフォントよりもSVGを使うべきだ

ケースバイケースです．SVGにもアイコンフォントにもそれぞれ異なった良さがあり，文脈によって使い分けるのが最良の選択です．ですから盲目的に片方を使うべきと言った態度はあまり感心しません．とは言え典型的な「誤ったアイコンフォントの利用」は避けたほうが良いでしょう．
※文字「1」 にアイコンを割り当ててしまうなど．

ツールで出力したSVGファイルを直接WEB上で利用してよい

ケースバイケースです．確かに変に手を入れない分確実に動作しそうですが，ツールで出力したSVGコードには本来必要のないデータが多量に含まれています．従ってこれをネットワーク帯域に制限のある環境で利用するのは好ましい行為とは言えません．事前にSVGの軽量化ツール等を用いてファイルサイズを縮小すべきでしょう．

svgz形式を用いれば暗号化されるのでデザインの盗難リスクが減る

いいえ．svgz形式はSVGファイルをgzip形式で圧縮しただけであり，一般のツールで元の形式に解凍することが出来ます．デザインの盗難に対処するのであればその旨をsvgファイルそのものにコピーライトとして記述するほうが建設的です．

canvas要素があるのにSVGを学ぶのは無駄だ

ある意味そうかも知れません．ですがSVGには強力なイベント処理機構やレイヤ機構が備わっており，canvas要素だけでは実現が困難な仕組みを簡単に実現出来る場合があります．従って実現したい仕組みに応じて適切に選択する，あるいは組み合わせて利用することが大切と言えます．
また将来的にはSVGとcanvas要素との距離がぐっと近づく見込みですから，先行投資としてSVGを学んだとしても決して無駄にはなりません．

SVGはflashの代替として利用できる

そのように短絡的に考えないほうが良いでしょう．SVGにはSVG独特の考え方があり，既存のflashアプリケーションをそのままSVGに移植出来るとは限りません．
※筆者はflashの内容を知りませんが，非常に難しいと言った話を聞いたことがあります．

SVGはテキストの配置に長けているのでタテ書きも簡単だ

いいえ．意外なことにSVGにおけるテキスト描画処理の実装は非常に遅れています．簡単な中央揃え程度ならともかく，折り返しやタテ書き等の文章としてのテキスト処理はほぼ行えないと考えてよいでしょう．特にブラウザ毎に挙動がバラバラな部分であり将来的にも改善はあまり期待できません．
※私見ですが，これはSVGがテキストをグラフィックを構成する「文字画像」としてとらえていることに起因します．なお，1文字ずつ配置する等の力技で対処することはできます．

SVGはCSSをサポートしているのでHTMLでの知識を流用できる

それだけでは不正確です．SVGにおけるCSSは文法こそ同様であるものの，利用可能なプロパティ値はSVG特有のものです．そのため，HTMLと同じ感覚で使った場合に思わぬ不整合を引き起こす場合があります．例えば"transform"はsvgではcssによる記述が出来ません．
※但しSVG2では可能となるため，ブラウザによっては先行実装により動作してしまうものもあります．
またブラウザによってはHTMLに特有な記述を無理矢理SVGに適用することで（最悪ブラウザがクラッシュすると言った）思わぬ不具合を引き起こすケースがあります．

過去のSVG資産がモダンブラウザで正しく開けない．作りなおしか…

そうすぐに諦めないでください．まず当該SVGファイルをテキストエディタで開き，svg要素のxmlns属性に値「http://www.w3.org/2000/svg」が設定されているか確認しましょう．もし記述されていなければ追記してもう一度試してみてください．これで大方は正しく動作するようになります．古いadobe製品の中にはSVGの扱いが非常にルーズなものがあり，これらの環境で作られたSVGファイルにおいては上記の作業が必要となります．
なお，svg要素のversionが1.2とある場合は当該SVGファイルを一旦ドローソフトで開き直し，再度バージョン1.1で保存し直すことで上手く行くかも知れません．

このサイト，ベクタ画像がかっちょいい！きっとSVGを使ってる！

いいえ，いかに大きさや解像度に依らないグラフィックが使われているからと言って必ずしもSVGであるとは限りません．他の技術を使っても（単純な用途であれば）SVGと全く同等の目的を果たすことは可能です．むしろSVGだけでは実現出来ないことのほうが多いくらいです．ですから，過剰にSVGに期待するのではなく，どのような仕組みで動作しているのかに着目しましょう．既存技術との組み合わせで思いも依らない効果を出しているのかも知れません．以下にSVGと競合しそうな技術についてリストアップしてみます．

• canvas要素
• アイコンフォント
• css（filter,transform,shapes…）

これからはindex.svg…だ!

筆者はindex.svgが何を指しているのか判りませんが，index.htmの代替にSVGを用いるものと仮定すると，現状「止めておけ」です．
確かにHTMLではCSSレイアウト上，意味のないブロック要素が多数生成されてしまう傾向があり，この対比としてSVGが語られる事がよくあります．しかしレイアウトのためだけにSVG文書を用いるというのは全くの誤りです．HTMLでは使えるが，SVGで上手く機能しない動作が多々あるからです．例えば次の機能はSVG単体では実現することが出来ません．

• ファビコンの設定
• フォームの配置
• スクロール機能
• iframe/frameによる外部文書の読み込み
• マルチメディア（サウンド・ビデオ）の再生

いずれもHTMLでは使えて当たり前の機能ですが，SVGを採用することで実現について頭を悩ませることになります．また，SVGファイルは単体としてのグラフィックを表すのが筋で，この原則を破ってHTMLとSVGとを同一視してしまうのは考えものです．

現時点での最善の策は「ベースとしてHTMLを用い，body要素の直下に大きなsvg要素を配置する」です．これであればHTMLの機能をフル活用しつつSVGの恩恵を受けることが可能です．HTMLかSVGかという二元論で考えないで下さい．
※なおSVG2になるとこれらの制約がぐっと少なくなりますから，SVG2の動作環境が広く普及した暁にもう一度検討すべき題材ではあります．

fill="none"とfill="rgba(0,0,0,0)"（fill-opacity="0", fill="transparent"等）は等価だ

いいえ，全く違います．SVGにおいてfill="none"は「塗り潰し領域が存在しない」事を表し，fill="rgba(0,0,0,0)"は「透明な色で塗りつぶす」という明確な役割の違いが存在します．確かに見た目的には全く同じものが得られますが，a要素によるリンクの生成やカーソルイベントの発生有無において顕著な差異が発生します．前者は要素上にカーソルがあたっても一切のイベントを発生しませんが，後者は見えないだけでイベントを発生します．SVGを見た目だけで判断してはならないという典型です．
※因みにtransparent値はSVG仕様に存在しないため，ブラウザによっては未知の色（＝黒色）で塗りつぶされてしまう場合があります．

まとめ

• SVGを利用する環境は整った
  積極的に利用することでノウハウを集めるフェーズに入ったとも言える．
  よってSVGにおける向き不向きを見極める目が大切となる．
• SVGは画像であり文書である
  そのため使いこなすには発想の転換が必要となる．
• SVGは非常にポテンシャルの高い技術である
  100%の力を引き出すにはどうしても人の手を借りる必要がある．
  一方で誤った理解の基ではかえって害となるケースも考えられる．
• そうは行ってもSVGにも限界はある
  その限界がどこにあるかはこれから明らかになるはず．

補足

だからといってSVGをフル活用しましょうと言ってるわけじゃなくて，SVGは余りに風呂敷を広げ過ぎた仕様の塊なんで，使う際に注意しましょうって言いたかったんですよ．現状落とし穴が多すぎてSVGを使ったらバラ色の人生が！と思って技術選定したら実は茨の道だったってのはまだ良くて，根本的にダメでしたってリスクが存在するんです．（特にセキュリティ関連はよーく注意してね）
なので，そこんところを良くわきまえて，どうとでもなる（＝リスクの少ない）ところからすこしずつみんなでSVGのノウハウの蓄積をしていきましょーってのが言いたかったんですね．

最後に

とは言え，SVGはあくまで手段です．SVGを使うことが目的とならないように気をつけて下さい．
（時には別の手段が残されていることをお忘れなく ）