yep, DOM-less SVG _implementation_ would be nice

http://blog.vlad1.com/archives/2006/10/07/125/

SVGに常にDOMがついて回ると重すぎるから、DOMなくしちゃおーぜ、という話。…と書くと、たぶん本旨が見えなくなってしまうだろう。コメント欄も読んでおいたほうがいい。

SVGドキュメントって、たまに数メガバイトにもなる巨大なものがあったりする。GIS系のSVGなど、パスの書き方によっては、かなりクレイジーな大きさになってしまう。SVGそいつらを全部SVGDOMにして持っていると、かなり重くなってしまう。

SVG DOMが必要になるのは、スクリプティングで構造が動的に変更されるような場合だけなので、そういう特別な仕掛けのないSVGについては、描画してハイおしまい、にしておきたい…と思うのは、ごく自然なことだろう。

実のところ、高速な処理系（たとえばAdobe SVG Viewer）では、SVG DOMの保持なんてオプションになっているんじゃないかと思う。

もう何年も前のことになるけど、W3C SVG WGの代表Chris Lilleyが日本に来たときに、当時ちょこっとSVGにハマっていたので、日本のSVGコミュニチー(?)の集まりに参加してみたことがある。その時に、SVGはDOMをもっていないといけないから云々、と僕が口にしたら、他の参加者の人たちに「なんで? 別にいらないじゃん」と返されて、えっ何で?と思って聞いたら、必要なときだけ作ればいいじゃん、という話だった…と記憶している。

思えば、ウィンドウシステムみたいなのをSVGで作れるんじゃん?とか思っていろいろ遊んでいた当時に、もう少しその道を極めていたら、今頃web 2.0-ishな世界に入り込んでいたのかもしれない(笑　まだChris Lilleyが「ホームページのバナーとか、SVGで作るようにしたいよねえ」とか平和なことをのたまわれていた頃で、SVG RCCの考え方すら無かったのだけど。

閑話休題。

実際にスタンドアローンのSVGドキュメント全般についてDOM-lessにするという考え方はいただけなくて、image src=...などで参照されている場合だけに限定しておくのが、妥当なアプローチだろう、と僕も思う。動的な構造が無くても、SVGドキュメントの表示が上手く行っていないときには、ツリー構造の情報が絶対にほしくなるからだ。

ツリーの構築自体はオンザフライで出来なくもないだろう。そうすると、全体をDOM付きのツリーからのアウトプットで再描画することになる。

XHTML+SVG+MathML+XFormsみたいな複合文書の場合も、どこでツリー情報が必要とされるか分からないので、ツリーをもっておく必要性はある。たとえばNVDLやSchematronでXPath（モドキ）を用いたvalidationを行う場合には必要になる。

そんなわけで、DOM-lessでなくなる条件というのは少なからず考えられるのだけど、まあそれでも高速な実装が実質的にも有用であることは間違いないだろう、とは思う。