知らなかった。一応仕様書は読んでたつもりだけどスルー力を発揮しまくってたんだな、きっと。
以下、mozrepl で覗いてみた結果。
repl.search( /element/i, content.document )
getElementById
createElement
getElementsByTagName
documentElement
createElementNS
getElementsByTagNameNS
ELEMENT_NODE
getElementsByName
getAnonymousElementByAttribute
repl.search( /element/i, html )
事前に var html = content.document.getElementsByTagName( 'html' )[0] を実行済み。
ELEMENT_NODE
getElementsByTagName
getElementsByTagNameNS
へー。
getElementsByName を node 内で使えたらコスト低いかなーとか期待したんだけど、そういうことはできないのでした。なるほどね。
今回は
の合わせ技。
表示するページの文字コードと form の送信先の期待する文字コードが異なる場合、IE 以外のブラウザなら accept-charset 属性に従って送信してくれる。
つまり IE でだけゴニョゴニョしなきゃいけないわけだけど1、
- 送信先で期待している文字コードが UTF-8
- GET リクエストが有効
の二つが AND でクリアできている場合、form の submit を横取りして JavaScript の encodeURIComponent() を使って URI を生成して、そこに飛べばよい。
が、これだけだと履歴を戻ることができなくなってしまう。例の、Ajax と同じ問題だ。そこで location.hash を適当に書き直してやることで送信先の URI に飛んで行く前の URI を履歴に保存してやろうとするんだけど、これがまた IE でだけ動かないorz
もう IE なんて死滅しろ。
ちなみに、Win2k + IE の場合は location.hash なんて書き換えなくても履歴に残ったりする。なんだこのいきなりの挙動の変わりっぷり。IE のバージョンとか JScript のバージョンとかじゃなくて OS のバージョンが影響するところがよく分からん2。