http://developer.animatelab.com/entry/2015/12/23/120000
Firefox 3.6 での XPath による要素取得: Days on the Moon
Firefox 3.6 にしたら、動的に生成した文書からの XPath による要素取得ができなくなったという報告が挙がっています。 Firefox3.6でdirect_bookmark.jsとdirect_hb.jsのはてブのタグを取得できていない問題(未解決→解決) - ヴィンペラートル・オクタウィアヌス - vimperatorグループ subscldr.jsが動かなくなったのを直してみた - mountain_dewの日記 この原因は、Firefox 3.6 で HTML 要素の名前空間の扱いが変わったことにあります。Firefox 3.6 (Gecko 1.9.2) では、HTML5 に従い、HTML 要素が (XML 文書中でなくても) XHTML の名前空間 (HTML5 でいうところの「HTML の名前空間」) http://www.w3.org/1999/xhtml に属す
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
文書中のXPathだとかセレクターを取得するGreasemonkey - ?D of K
必要に迫られてようやく作った。 // ==UserScript== // @name XPath Finder // @namespace userscript // @include * // ==/UserScript== function $X(exp, context, type) { if (context && !context.nodeType) { type = context; context = null; } if (!context) context = document; var exp = (context.ownerDocument || context).createExpression(exp, function (prefix) { return document.createNSResolver(context).lookupNamespaceURI(
XPath に文字列を埋め込むときの注意 - IT戦記
よく、以下のように XPath に文字列を埋め込む事があります document.evaluate('//*[@class="' + text + '"]', document, null, 7, null); まあ、僕もよくこんなコード書くんですけど。 でも、これって text が外部から来るものだったら、意図通りの動作をしないんですよね たとえば、以下のような例です。 var text = '"] | /hoge/fuga/piyo | .["'; document.evaluate('//*[@class="' + text + '"]', document, null, 7, null); というわけで 任意の文字列を XPath の式に変換する JavaScript を書いてみた 以下で試せます http://amachang.sakura.ne.jp/misc/xpath_es
XPathEvaluator - 素人がプログラミングを勉強していたブログ
var XPath = { cache: null, reset: function () { this.cache = {__proto__: null}; }, get: function (context, expr, type) { var cache = this.cache, evaluator; if (expr in cache) { evaluator = cache[expr]; } else { evaluator = cache[expr] = XPathEvaluator().createExpression(expr, null); } return evaluator.evaluate(context, type, null); }, has: function (context, expr) { return this.get(context, expr,
XPathで配列にしてしまったあとから特定要素を削除する。 - 枕を欹てて聴く
LDR は、アイテムを繰るのの基準としてH2要素を使っている。本来RSSしか読まないんだからそれで大丈夫なんだけど、LDR Full Feedとかで要素を付け足すと、H2があると、意味もないところでとまってしまう。 そこで今までは、HTMLDocumentにする前に、正規表現で、 // drryさんがGR Full Feedで作成なさったものです。ものすごくきれいな正規表現。 if (REMOVE_SCRIPT) text = text.replace(/<script(?:\s[^>]+?)?>[\S\s]*?<\/script\s*>/gi, ""); if (REMOVE_H2TAG) text = text.replace(/<h2(?:\s[^>]+?)?>[\S\s]*?<\/h2\s*>/gi, ""); ってやってたんです。 が、これによるREMOVEをtrueしていると
XPath - 枕を欹てて聴く
調べてみるとちょっと衝撃を受けたので書いておく。 以下XPathによるFirebug上からの抽出速度。抽出対象はLDR Full Feedで本文として指定しているもの。 速度計測法はid:os0xさんのjottit.comのLDRize用XPath - FFFF - 0xで使っているFirebug組み込み関数である$xによる抽出1000回の所要時間。 調査目的は、前から疑問に思っていた、抽出対象がclassなど特定条件で一発で抽出できる場合（//div[@class="entry_body"]など）の以下3つの疑問点 全体からclassなどで一発で抽出するのと、祖先ノードにidのある場合、それをid関数で抽出した後子要素を検索するのではどちらが速いのか。 //div[@id="ほにゃらら"]はマジで遅いのか。 //div[@class="ほにゃらら"]と//div[contains(con
XPath で "//" を使う時は気をつけようという話 � のっち大好きの会 分室
document.evaluate の第二引数に適切なノードを指定していても， XPath expression が "/" で始まるとルートノードから走査されるので， 意図通りの結果が得られない可能性が高い． ありがちなのは AutoPagerize で 2 ページ目以降を処理しようとして XPath に "//" を使ってしまい，結局ページ内の全ノードを舐めてしまうとか． 面倒でも "descendant::" もしくは "descendant-or-self::" を使用されたい． もしくは， getElementsByTagName で済む場合であればそちらを使えば意図通りの結果が得られるし， なにより速いはず． 一応，実験 (要 javascript/)．IE では動作しない．
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
