svgを使う上でwebkitを嫌いになる理由

html5がsvgをサポートすることとなってから数年が経ちました．このような状況ですからさぞsvgが世の中に広まったのか…というと別にそんなこともなくて，むしろ解像度に依存しない特徴のみが強調され，ラスタ画像の置き換え程度にとどまっている印象があります．毎年svg元年と叫ばれている中，なぜこのような状況なのでしょうか？

その答えとして筆者はwebkit系ブラウザのsvgにおける機能の貧弱さが一因として挙げられると考えています．chromeやsafariは実に先進的なwebブラウザと言った印象があるのですが，svgに限って言えばむしろ他のブラウザに大きく劣っているなど，実は非常に偏った癖のある環境なのです．

本記事では筆者がこれまでsvgを調査してきた上で気になったwebkit（主にchrome）の問題点についてまとめてみます．将来的に改善されることを期待しつつも，現状svgをクロスブラウザで扱う上での注意点として一読しておくと便利かも知れません．

svgに厳しいwebkitの現状

昨日operaがレンダリングエンジンとしてこれまで開発してきたprestoエンジンを捨て，新たにwebkitを採用することが報道されました．時代の流れには逆らえないとは言え，svgを扱う者にとっては戦慄するものでした．webkitは先進的で動作が軽く，現在最も普及したレンダリングエンジンですから，それが更にシェアを伸ばすことに何が問題があるのかと思う方も多いかと思いますが，svgに限って言えば状況は全く逆です．というのも，prestoエンジンはsvgの描画において最も良好な結果が得られ，webkitは最も劣っているためです．webkitに移行することで優秀なsvgレンダリングエンジンが失われてしまう…これだけでも相当のインパクトが有ると判るでしょう．

それではどのような点でwebkitは劣っているのでしょうか？
筆者が記憶している範囲でリストアップしてみましょう．

• img要素やimage要素でsvg画像を表示すると強制的にラスタライズが働き，ベクタ画像としての滑らかさが失われる．
  transformで拡大・縮小した際に顕著．
• img要素やimage要素でsvg画像を表示した場合，preserveAspectRatio属性の解釈が正しくない．
  画像の配置に関わる属性が正しく動作しないので，レイアウトが狂う．
• image要素のSVGLoadイベントが発生しない．
  画像読み込みのタイミングでスクリプトを実行できない．
• ラスタ画像の拡大時にimageRendering=optimizeSpeedとしてもアンチエイリアスが切れない．
  仕様上これでも問題はないが，他のブラウザとは異なる動作となる．
• xml:base属性が正しく動作しない．
• display:noneを指定するとブラウザがクラッシュする要素がある．
• defs要素配下に置かないと機能しない要素がある(safari・clipPath)．
• smilアニメーションが機能不全．
  余りに中途半端な実装であるため，動きそうで動かないパターンが多数．ieのように端からサポートしないと明言したほうがどれだけ開発者を惑わせずに済んだことか．
  
  • animateTransformがgradientTransform,patternTransform属性に指定できない．
  • アニメーションイベント（begin,repeat,end）をサポートしないはずなのに一部動作する．
    …のだが，使うと不具合を起こす．場合によりブラウザがクラッシュする．
  • アニメーションの自動実行が出来ないケースがある．
  • 0s指定での自動実行が行えないケースがある．
  • fill属性等のurl指定はアニメーション化出来ない．
    グラデーションの参照先を変えられない． 
  • calcMode=discreteでkeyTimes属性が正しく動作しない．
    末尾の値が無視される．
  • a要素のxlink:href要素をアニメーションすることでリンク先を詐称できる．
  • インラインsvgにおいてxlink:href属性のアニメーションを行う場合にxlinkの名前空間の宣言が必要．
• getElementsByTagname,querySelector,querySelectorAllメソッドでインラインsvg要素内部のanimateTransform要素を検索できない場合がある．
  試してみてびっくり．ぶっちゃけ意味不明．
• use要素が参照する図形は1段まで．
  参照している図形が更に他の図形・グラデーション等を参照していた場合，内容が無視される．（おそらくデグレード）
• text要素にdisplay:inline-blockを指定するとなぜか:after擬似要素が有効となる．
  svgにそんなものはないからバグだよ．
• shiftキーを押したままmousedownすると後続のmouseupイベントが発生しない！
  スタンドアロンのsvg環境で発生する．
• dataスキーム形式のsvgデータをiframe要素・object要素で読み込むと日本語が文字化けする．
  img要素・background-imageで読み込んだ場合は正常に動作する．なお，元のソースコードで日本語を数値文字参照（語）で書き換えておくと正しく動作する．

と相当数の問題点が挙げられます．まぁ，百歩譲って現状仕方がないとしましょう．しかし憂慮する点はこれらの問題が有ることじゃなく，問題が全く改善しないどころか，バージョンが上がる毎に新たな問題が発生している点です．つまり有るバージョンで動作したsvgが気が付くと動作しなくなっていることがあるのです！その為，svgにおいてはieの方が信頼できる動作環境となっているのです．
※もちろん，徐々に改善している面（svgフィルター）も有るのですが．

ではどうすれば？

それではクロスブラウザを念頭に置いた場合，安心してsvgを利用するにはどうすれば良いのでしょう？

• svgの動作検証の優先順位は
  safari→chrome→ie→firefox→opera
  とする．より不安定な環境で動作を確認する．
• smilによるアニメーションでちょっと躓いたら諦める．
  調べるだけ時間の無駄．苦労して動かしても次のバージョンで動作しない可能性も．
• svgを表示する場合はobject要素一択．
  それ以外では動作が不安定．
• とにかく1枚絵として利用する．
  その他のsvgとして便利な機能をすっぱり諦める．

結局の処，svgをretina対策として利用するしか価値がないわけです．

このような現状があるため、筆者はwebkitをどうしても好きになれないわけです．

追記）forefox,operaだって悪い処有るよについて

はい，そのとおりだと思います．

ブラウザ毎に得手不得手はあります．それはsvgが全ての仕様を満たすことを強制していないためです．ですから，動かない事自体は問題ないのです．動かないのであれば，それに対する対処ってものが出来るわけですから．

またこれらのブラウザでのsvg挙動不審な部分については納得できます．というのもw3c仕様の品質にばらつきがあり，内容によってはどのように解釈すべきか意見の別れる部分があるためです．ですから，プログラマー側でその意図を汲んで，憶測で実装してしまうのは致し方ない事と思います．
・このようにある程度実装してから仕様を見直すのはよく有ることです．
・ieの動作が良いのは，この部分を着実に潰しているからだと思われます


通常このような機能は仕様定義者側も内容を理解できていないものと思われますし，ましてや利用者側にはそれほど影響が無い部分だったりします．
・実際svg2のエディターズドラフトを見るに既存のsvg1.1仕様において相当量の問題が指摘されています．

しかしchromeの問題には明らかにバグと思われる点が多く，しかもそれらがずっと放置されているのです．しかもこちらによればchromeはほとんどの機能をサポートしていることになっているのですが，先ほどの通り，smilアニメーションについてはまともに使える状況にありません．実際には「動作しない」のに「動作する」と自己申告するのは如何なものか？せめて正直に「動作しない」と返して欲しかったところです．

加えて，firefox，operaの問題は大抵回避策が見つかります．屋台骨がしっかりしているため，仕様を迂回することで何とかなる場合が多いのです．ですがchromeでは挙動がそのものが不審であり，しかもバージョンごとに動作が異なるとなれば対処のしようがないのが現状です．
・実はfilterの挙動もバージョンごとに二転三転しています．（viewBox範囲外の図形要素の参照において）

即ち，「ブラウザの癖として許容できないレベル」の実装度に留まっている部分を好きになれないわけです．

※と，ずっとchromeやwebkitの悪口となってしまっていますが，良い所だって有るんです．基本機能だけを使って複雑なsvgグラフィックを描画するのであれば，chromeが最も動作が機敏なのです． ですから，先ほどの問題が解決すれば（少なくとも前進の兆しが見えてくれば）svgの分野でも覇を唱えることは十分に可能と思います．