多層レイヤーでのDOMの構造

インディゴ松澤です。

第3回 SVG IG Japan ミーティングの議事録より:
> => 多層構造のDOMツリーやイベントの管理が不明瞭に思われる(松澤)
の点について、問題を整理したものを投稿いたします。


1.多層構造を持つ SVG の実装
a) ひとつのDOMツリーとして統合して扱う
b) 個々のSVGがそれぞれDOMツリーを持つ
c) 異なるアプローチ

異論はあるかと思いますが、
a については XInclude、 b については XFrames の考え方が近いと思います。
本稿では a,b について特徴と問題点を整理してみます。


a) ひとつの DOM ツリーとして扱う
外部から持ってきた DOM を、元からある DOM に移植するという方法です。
現在のハイパーレイヤリングを、たとえば Firefox 上の Ajax や
xml-stylesheet (xsl の document 関数利用) を使って実装すると
このケースとなります。

この方法ですと、技術的には移植の際に g/@transform を一枚はさむだけで
非常に簡便で、かつ、SVGTiny1.2 の枠の中で処理できるので
あまり考えることはありません。

ただ、移植元の SVG の中で xml:id / use/@xlink:href を使った
参照を行っている場合、個々の id と xlink:href の参照をどう扱うかが
課題となります。
移植元と移植先で同じ名前の xml:id を使っている場合など(ありがちです)、
名前の衝突については問題になると思います。


b) 個々のSVGがそれぞれDOMツリーを持つ
現在の Firefox の HTML / Object / iframe 等の実装に近い形態です。
それぞれが DOM ツリーを持つので、名前の衝突の問題はありません。
網羅的ではないのですが、SVGTiny1.2 の範囲で問題になりそうな点を
挙げます。

・viewBox と ref
http://www.w3.org/TR/SVGMobile12/coords.html
地図のアイコン表現では、 ref を使うシーンがかなり多いのですが、
ref の座標計算を行う際には
・rootmost svg
・ViewBox to viewport transformation
を決定しないと計算できません。これに加えて、
CRS による変換が ViewBox to viewport transformation の上位になるのか
下位になるのか、それとも置き換えになるのか、
といった定義づけがないと、実装に依存した挙動となってしまいます。

・interactivity
http://www.w3.org/TR/SVGMobile12/interact.html
利用者要望としてよくある、キーボードナビゲーションなのですが、
個々の SVG が独立した DOM ツリーを持っている場合、
「画面上となりにあるアンカーに、tab でフォーカス」
といった操作を nav-up 等の属性で制御するのは困難です。
# アイコン同士はとなりあっていても、DOMとしてはそれぞれ所属が違う、
  といったことがあるので




-- 
Yuzo Matsuzawa <yuzo@indigo.co.jp>

Received on Thursday, 9 April 2009 04:01:22 UTC