IEでのテキストノード走査の高速化 - os0x.blog
に釣られて。 HatenaStar.js 1380 行目 テキストノード走査 一番のボトルネックはやはりここですね。IEなので、こんな感じでベタに計測。 makeTextNodes: function(c) { if (c.textNodes || c.textNodePositions || c.documentText) return; if (Ten.Highlight.highlighted) Ten.Highlight.highlighted.hide(); c.textNodes = []; c.textNodePositions = []; var isIE = navigator.userAgent.indexOf('MSIE') != -1; var texts = []; var pos = 0; var st = new Date*1; (function(node,
SCRAPBLOG : 待望の document.elementFromPoint が実装
待望の document.elementFromPoint が Firefox 3.0a8pre にて実装された。仕様は nsIDOMNSDocument.idl に詳しく書いてあるが、おおよそ以下の通りである。 HTML, XUL どちらの document に対しても使用可能 document の左上を (0, 0) とし、位置 (x, y) にある実際に見えている要素を取得する 同一の document 内に存在する要素のみ取得可能。例えばインナーフレーム内の document 内に存在する要素は取得できず、代わりに iframe 要素を返す。 位置 (x, y) が document の可視領域の外側にある場合、null を返す。 XUL document で使用する場合、例えば textbox 要素のスクロールバーのように XBL で生成された無名要素は取得できない。この場合、
ノードの集合を「ドキュメント順」に高速に並べ替える。その１ - IT戦記
ドキュメント順とは何か？ ドキュメント順とは、簡単に言えば「XML のソース上の前にある順」のこと。 詳しくはこのへんを見てね。 XPath ではこの「ドキュメント順」という概念がよく登場する。 たとえば、ノードを文字列化するときは子孫テキストノードを「ドキュメント順」に文字列として連結しなければならない。とかとか でも、このドキュメント順へのソート 考えただけでもめちゃめちゃ重そうだ・・・。 いろいろ考えてみた。 XPath 実行中はドキュメント順が変わることがないので、DOM アクセスはキャッシュできる。 ノードの集合は木構造で保存したほうが比較回数が少なくてすむ（アルゴリズム初心者なので、実際に早いか検証しないと＞＜） で、今回は DOM アクセスをキャッシュしながらノードを比較する関数を作る 汎用的に作ったので XPath 目的以外でも使えます。 var order = funct
作って納得! DOM 2 Events: Days on the Moon
ブラウザ上でのプログラミングで避けては通れないのがイベント処理。その仕組みは DOM Level 2 Events にて規定されています。しかし、とりあえず addEventListener メソッドを使ってはいるものの、それがどのような意味を持つか詳しくは知らないといったことはありませんか。そこでここでは、DOM 2 Events のイベントモデルを理解し、ブラウザが裏で何をしているのかを把握するために、実際にそのイベントモデルを実装してみることにします。具体的には、仕様書に定められたインターフェースを JavaScript で実装し、それらを組み合わせてイベントの発生をシミュレートしてみます。 Event インターフェース EventListener インターフェース EventTarget インターフェース DocumentEvent インターフェース DOMException イン
javascript - element.innerHTML はなぜ速く見えるか : 404 Blog Not Found
2006年10月22日00:55 カテゴリLightweight LanguagesWEB+DB PRESS javascript - element.innerHTML はなぜ速く見えるか 自分でこう書きながら、実は首を傾げていたのだけどやっとわかった。 404 Blog Not Found:WEB+DB PRESS vol.35 pp.57 まず速度ですが、innerHTMLは代入時にHTMLの構文解析が入るので、速度的にはDOM操作が有利です。 期待に反してそうでないのは、404 Blog Not Found:javascript - DOM vs innerHTML benchmark on MacBook Proでの指摘した通り。このあたりはamachangにちゃんと査読してもらった方がよかったのではないか？ InnerHTMLは速くない。速く見えるだけだ。 その証拠として、以下
IE の getAttribute / setAttribute: Days on the Moon
DOM の getAttribute / setAttribute メソッドは DOM Level 1 から定義されているメソッドで、MSDN Library によれば IE はバージョン 4 からサポートしています。しかし、IE での element.getAttribute(name) / element.setAttribute(name, value) というのは、基本的には JavaScript における element[name] / element[name] = value のシンタックスシュガーでしかありません。ですから、element.setAttribute("innerHTML", "foo") とすると、element の属性には何の変化もないが element の内容が書き換えられるという事態になります。 この (手抜き) 実装が原因で、getAttribute
DOM1仕様書
文書オブジェクトモデル(DOM)第1水準 仕様書 Version 1.0 この文書は、W3Cにより作成されW3C勧告として公開されている "Document Object Model (DOM) Level 1 Specification Version 1.0" (http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/) を、どら猫本舗が翻訳したものです。 最新版の仕様書は http://www.w3.org/TR/REC-DOM-Level-1/ にあります。 正式な仕様書はW3Cサイトにある英語版です。この日本語版は参考にすぎません。 この文書には翻訳上の誤りがあるかもしれません。どら猫本舗は翻訳の正確性を保証しません。あくまでご自身の責任でご利用ください。 お気付きの点がありましたらどら猫本舗までお知らせください。 REC-DOM-L
DOM Level 2 標準技術をMSIEで使う(イベント、基本操作) @ ぽかぽかWeb研究室
はじめに HTML/XML文書を動的に制馭するするためにはDOMが用いられることが多いわけですが、ことに X(HT)ML を取り扱う上では、どうしても DOM Level 1 の範囲だけでは力不足です。また、イベント制馭は Level 1では定義されていません。 MSIE では、基本的には DOM Level 1 までのサポートに留まっています。それ以外の振舞は独自規格で賄われているのが現状で、このことが、「処理系に依存しない記述」を妨げる原因にもなっています。 Mozilla/Netscape では、 (XHTML文書も含めて)XMLとして認識された文書では、名前空間が重要な役割を果たします。例えば、 XHTML の要素を正しく作成するためには createElementNSが必要になりますが、これは MSIE では認識されません。 具体的な方法 ここでは、 JavaScript(ECM
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hawk's W3 Laboratory : XML : DOMとXPathの連携