Dom カテゴリー

2005年 11月 06日

Event.which, Event.charCode, Event.keyCode

javascript script dom | 21:32 |

違いがわからんうえに、ちゃんとキーボードと対応してない。英語キーボードだとちゃんと対応してんのか？

e.which, e.charCode, e.keyCode, String.fromCharCode(e.which) の順で、前者が keydown、後者が keypress。環境は Firefox 1.0.7

;: 61 0 61 = / 59 59 0 ;
C-;: 61 0 61 = / 61 61 0 =
C-+ (Ctrl+Shidt+;) テンキー側の C-+ は問題なし: 61 0 61 = / 61 61 0 =
C-:: 59 0 59 ; / 59 59 0 ;
C-| (Ctrl+Shift+\): 220 0 220 ﾃ･ / 発生しない
C-a: 65 0 65 A / 97 97 0 a
C-F1: 112 0 112 p / 0 0 112

差が一定ってわけじゃないし、どうやってマッピングすればいいか見当がつかない。さらに IE だとイベントが発生するタイミングがまた全然違う。帰れ。

Gecko_DOM_Reference:Examples#Example_7:_Displaying_Event_Object_Constants

つまり、正確に処理するにはキーボード配置を自分で作らないとダメなわけか。入力された文字を取得したいのに、入力されたキーしか取得できない。Gecko の e.charCode って charCode じゃないだろ。

それにしてもなんでセミコロンの位置でDOM_VK_EQUALSなんだろう。わからん。

2005年 01月 21日

名前空間が null?

xml dom xslt | 21:23 |

IRC ネタ。

2005年1月の指向性メモに createElement()で作られたエレメントノードは名前空間がnullになるはずなのに、親要素のデフォルト名前空間を引き継いでしまっている。って書いてあるけど、何か違う気がする。

確かに DOM Core の createElement の項には localName, prefix, and namespaceURI set to null. とは書いてある (これを根拠にしているかは定かじゃない) けれど、これは名前空間っていう概念がないから、名前空間関連のプロパティにはとりあえず null という値を入れておけよってことで、名前空間URI を空値に設定するっていう意味じゃない気がする。code でマークアップされてるしね？

そもそも自分も書いたことあるんだけれど、名前空間がnullになるっていうのが何かおかしいかもしれないとも思う。Extensible Markup Language (XML) 1.0 にも Namespaces in XML にも null という単語が出てこない。名前空間が null っていう表現が出てくるのは XPath の仕様の日本語訳で、原文の null には code 要素がついていないので、ただたんに“空”といいたいだけなんじゃないかとか。でもそうだったら empty って書くかなぁ……仕様書だし紛らわしいふうには書かないから、あるいは俺の読解力が糞なおかげで違うかもしれない……

まー結局のところ createElement に名前空間の概念がそもそもないので単純に引数の nodeName を引数の名前にするよってことで、それ以上は実装依存なんじゃまいか。みたいな？　併用することは稀なので。。。

しかし自分の解釈があっているかどうかは永遠に謎だ。確かめようがないから困る。誰に聞けばいいのか。その人が言っていることが正しいのか、正しいとしても自分がそれを正しいまま受け取れているかは確かめようがない。あーアレだね。アレ。理解は誤解の総体 (だっけ？) ってヤツ。　わかりあえているように感じるにはできるだけ曖昧な表現をすればいい。アレとかソレとかを、明確にしない「ありえねー」とか。

2004年 12月 23日

XSLT と DOM との相違

xslt dom xml xpath | 00:02 |

XSLT では属性ノードとその親ノード (要素) との関係は片方向……属性ノード側からは @attr[. = ../../@attr] (省略しない場合: attribute::attr[self::node() = parent::node()/parent::node()/attribute::attr])) とかいう風に親がちゃんと親に見える (っておかしいな) けど、その親からは (attribute:: としているように) 軸が違う。ここで親から child::attr とアクセスできたら困るわけだけど、ややこしい。どうも俺は属性を子ノード的にイメージしていて attribute っていう軸がイメージしにくい。

DOM の場合は属性に親ノードはなく (parentNode は null) ownerElement に親要素が入ってる。軸が完全に分離してるっつうのかなぁ。DOM だとあんまり混乱しない。ただのプロパティでしかないからかなぁ。

XSLT の場合も DOM っぽい考え方をすればいい気がするのでちゃんと書いて、どこがどう違うかを考えてみてる。軸をプロパティと考えればいいの鴨。

// わけわかんコードだ（ｗ
contextNode = current();
with (contextNode) {
contextNode = child["*"];
with (contextNode) {
contextNode = attribute["attr"];
with (contextNode) {
text();
}
}
}