CodeReposに入れた 新しいタブを開く前にフォーカスをロケーションバーから外すようにしました
元は firefox userChrome.js greasemonkey スクリプトスレ (part1)の178さんのロケーションバーからURL入力してEnterを押すと新規タブで開くuserChrome.js用スクリプトですブックマークレットを開く時とabout:blankな時はその場で開くようにしました(名前は適当)
// open in New Tab from location bar
BrowserLoadURL = function(event,post){
gBrowser.userTypedValue = content.window.document.URL;
if((event && event.altKey) ||
gURLBar.value.match(/^javascript:/) ||
gBrowser.userTypedValue == 'about:blank'){
loadURI(gURLBar.value,null,post,true);
}else{
_content.focus();
gBrowser.loadOneTab(gURLBar.value,null,null,post,false,true);
}
}
AutoPagerizeやLDRize，LDR Full FeedなどのGreasemonkeyスクリプトはページごとの構造の違いを吸収するため，XPathなどのデータをSITEINFOとしてwikiから取得しています．ですが，SITEINFOにはLDRize専用のmicroformatsについてという記事に書いた問題点があります．同じ記事中で疲れて途中でやめてしまった解決方法の提示の続きを書きます．
また，実装したものをCodeReposにあげてます．インストールした後，このブログで動作の確認ができます．まだ語彙とXSLT(語彙のページと同じ場所にリンクがある)がこれで良いのか判断付かないのでフィードバックが欲しいです．よろしくお願いします．
で，結論から先に書くと，これらの問題の解決策は GRDDLで抽出したRDFをSITEINFOとして使う というものです．理由は以下のような点があります．(前回挙げたmicroformatsの問題点とSITEINFOの問題点が全て解決される上にプラスアルファ)
逆に，デメリットはユーザの手間がちょっと増えることです．ページの構造に合ったXSLTがなければ作ってHTMLに1行追加する必要があります．XSLTが存在すればHTMLに1行追加だけですが．
現実的に，全てのページがGRDDLに対応してくれるとは思えないので，wikiにURLの正規表現+XPathを書く今の方法も残す予定ではあります．(wikiにURLの正規表現+XSLTのURLを書く方法もやりたい．ページを作った人がページの構造を保証するGRDDLに対して，第三者が簡単に保証する方法として．)
LDRizeはhAtomとxFolkというmicroformatsに対応していますが，これらに対応できているのは，全てのページ (非対応のページを含む)で「このページはhAtomに対応しているか」「このページはxFolkに対応しているか」を探索(XPathにマッチするかチェック)しているためです．
今は2つのmicroformatsに対応していないため2回の探索だけで済む…わけではなく，tDiaryやWordPress，blogger，PukiWiki，RandomNoteなど，他にもいろいろな構造に対して全てのページで探索しているので，とても無駄が多いのが現状です．
これが，GRDDLに対応したページならば操作は1回で済みます(link要素の探索)し，それ以上増えることもなくなります．正確には，無駄にXSLTを処理しなくてもいいように簡単な探索(こっちで見つかれば終了)と全ての探索の2回ですが．
link: 'h2//a[contains(@class,"l")]',
これはLDRize用SITEINFOの一部です．現在，SITEINFOの値(右側の部分)にはどのようなXPathを書くべきか，また，それはどこに書かれているか，についての決まりはありません．SITEINFOのwikiにちょろっと書いてあったり，動作を知った上で，それっぽく書いているのが現状です．なぜこれが問題かというと，前回の記事でも書いた通り，「この値も入れて！」と言う人がでてきても，実際入れてしまうと「どういう値か分からないのに誰がメンテするのか」という問題があって入れられない という勿体ないことになってしまうからです．そのためには， linkはこういう構造に対するXPathを書く とあらかじめ明示する必要があるのです．GRDDLでRDFを抽出して，それをSITEINFOとして用いると，linkにはURIの接頭辞が付いて， http://purl.org/net/ldrize/ns#link のようになります．これはURIで色々なものを表すというRDFの特性上こうなるのです．
※ クライアントを 「microformatsで構造化されたページを処理するプログラム」の意味で用います．
前回もチラっと書いたmicroformatsの問題点について，もう一度．
原因はこんな感じです多分．
保証がないから厳密性がないわけですが．
「どのページにどの構造が使われているか」を保証されていて，それをクライアントが解釈できれば，上記問題点は解決できます．人間が「このページのrel="home"はrel-homeだよ．別のrel="home"じゃないよ．」と教えてくれればいいわけです．で，前回も書いたように，保証された構造のための方法に，RDFaとGRDDLというのがあってどちらかによって保証されれば良いのです．両方とも最終的にはRDFというものを抽出できるようになっていて，RDFではURIで名前を決めるので重複しないから厳密ってことなのです．
どっちでも良いのですが，エンドユーザの手間が少ないの方がみんなが(自分も)楽なので，楽な方を取ります．
というわけで，GRDDLによる解決方法を取ります．
XSLT内で条件分岐を行って以下のようにする．
RDFが抽出できた時だけクライアント(LDRizeなど)を実行させるようにすると，HTML構造を変更して，かつ，XSLTも正しいものに変更した時のみ動作し，それ以外の場合(HTML構造だけを変更したときなど)はクライアントが動作しないので，誤動作も起きない．
それぞれのページ側にメタデータ(SITEINFO)抽出のためのルール(XSLT)の指定を行うので，wikiが落ちたり消されたりいたずらされても，被害を受けずに済む可能性が高くなります．
関連して，ページから直接SITEINFOを生成できるので，wikiからデータを削除しても良くなって，LDRizeがローカルに保存するデータが少なくなります．現状は，1度も見ないようなページ用のSITEINFOのデータも全てのユーザが全部GM_setValueでprefs.jsに保存しています．wikiのデータを減らして，ページ側でメタデータを生成できるようになれば，自分が見たページ用のSITEINFOをその場で生成してキャッシュしておくことができるようになるため，1度も見たことがないページ用のSITEINFOをキャッシュしなくて良くなります．
RDFとは，URIかデータ(文字列とか)を使って表現した三つ組みのことです．だいたい．具体例をあげると，このブログから抽出できるRDF/XML(XML形式で3つ組みを表したRDF)の一部は下記のような感じです．
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ldrize="http://purl.org/net/ldrize/ns#">
<rdf:Description rdf:about="http://white.s151.xrea.com/blog/">
<ldrize:article>.//*[contains(concat(" ",normalize-space(@class)," "), " hentry ")]</ldrize:article>
</rdf:Description>
</rdf:RDF>
一応GRDDLで抽出できるこのブログの全てのRDFも見られます．これはウェブサービスとして提供されているものですが，XSLTの処理系があればRDF/XMLを出力することができます．とりあえず，GreasemonkeyからはXSLTを使ってRDF/XMLを出力できるので，そのXMLをXPathで処理しています(本当はちゃんとRDFパーサとか使うべき．Greasemonkeyからは扱えませんが拡張やuserChrome.jsからはRDFも扱えるらしい．http://developer.mozilla.org/ja/docs/RDF )．
ここで，上記のRDF例のインデントの一番深い部分を見ると，SITEINFOに良く似ています．wiki上の表現に倣って変換してみると下記のようになります．データが取得できれば，あとは今までのスクリプトと変わりはありません．
article: './/*[contains(concat(" ",normalize-space(@class)," "), " hentry ")]'
prefs.jsに保存されるキャッシュデータは↓のようになります．structuredUriRegExの正規表現にマッチするかどうかを確認して，マッチしなければGRDDL変換を行います．
[{section:\".//*[contains(concat(\\\" \\\",normalize-space(@class),\\\" \\\"), \\\" section \\\")]\",
article:\".//*[contains(concat(\\\" \\\",normalize-space(@class),\\\" \\\"), \\\" hentry \\\")]\",
view:\".//*[contains(concat(\\\" \\\",normalize-space(@class),\\\" \\\"), \\\" entry-title \\\")]//text()\",
link:\".//*[contains(concat(\\\" \\\",normalize-space(@rel),\\\" \\\"),\\\" bookmark \\\")]\",
structuredUriRegEx:\"^http://white.s151.xrea.com/blog/\",
expire:(new Date(1204137557921))
},
{...}]
まだコードや語彙やXSLTに問題や不安が残ってるので，それらが解決したらuserscripts.orgにあげて，テスト版でなくなると思います．
…あとから気づいたけれど，同じ構造(例えばhAtom)でもサイトが違えばその数だけXPathをキャッシュしようとするから，同じXPathが沢山prefs.jsに保存されることになってしまう．要検討．
Minibuffer，LDRizeと連携してTwitterの発言をTumblrにChatとして投稿出来るGreasemonkeyスクリプトです．デモはuserscripts.orgにあります．
ShareTwitterOnTumblr (403って言われる人は CodeReposからどうぞ)
// 現在開いているページを投稿(1つの発言しかないChatになります) location | share-twitter-on-tumblr // ピンを立てたもの(なければ現在の)を全て投稿 pinned-or-current-link | share-twitter-on-tumblr | clear-pin
microformatsとか使って構造を合わせてくれないと，こういうスクリプトを作りづらい．というか今のままでは素のHTMLから本文を取得するのは不可能．無理矢理やろうと思えばできるけど，スケーラブルでないしサステナブルでないのでやるべきでないと思う．仕方なくGM_XHRでtwitterにリクエスト発行して本文を取得してるから，10個の発言にpin立てて実行すると10回アクセスが発生する．それプラスTumblrのパラメータ取得に1回と投稿に1回．構造が統一されていれば，こんなことしなくても済む．twitterも一覧ページはhAtomのくせに個別のページは独自構造だし，かといって一覧ページの本文は末尾に...が入ってたりして良く分からない．今までみたいにSITEINFOを作ればとりあえずは解決するけど，あれは拡大しないし持続しない．拡大・持続しないと分かっているものに依存したスクリプトを何個も書きたくない．
話しが飛ぶけど2chコピペブログのHTMLは本当にひどい．構造も糞もあったもんじゃない．誰かhAtomとかで出力するコピペブログ作成専用のソフトウェアかブログサービスを作ってくれればいいのに．もし仮に構造化された2chコピペブログがあったら，ShareTwitterOnTumblrをTwitter専用じゃなくて，2chの書き込みにも適用できたりするんだわ．機械可読になるから，ShareTwitterOnTumblrだけでなくこれから誰かが作るであろう便利なスクリプトにも使えるようになるんだ．
で，2chに適用できるということは，はてブのコメントとかブログのコメントとかにも適用できたりするハズなんだけど，はてブははてブで独自のキーバインドをつけてるからLDRizeが動かないっていう問題がある．「非LDRizeユーザ」や「重くなるからGreasemonkeyを入れたくない」という人のことを考えたら，サイト独自のキーバインドをJavaScriptで設定するのは間違ってないかもしれない．作ってる人もユーザのためを思ってやってるんだと思う．でも，それサステナブル？そしてスケールラブル？
はてブだけじゃなくて，自分のブログにj/kスクロールを入れてる人もいるけど，Shift,Ctrl,Alt,Metaキーの判定もちゃんとやってる？j/kじゃなくてn/p使いたい人はどうすればいい？AutoPagerizeが継ぎ足したページに対応できてる？AutoPagerizeみたいなUIをどうにかするスクリプトがこれから出てきたときに，対応できる？仮に全部できたとしても，1つ1つのサイトが別々に実装してたら，これらの対応状況は全部違うんだよ？使い勝手は本当に良い？本当にユーザのためになる？
Minibufferと連携してキー1発でreblog出来るGreasemonkeyスクリプトに関する説明です．MinibufferBookmarkCommandのreblog版のような感じです．デモは userscripts.org にあります．
// 現在開いているページをreblog location | reblog // 現在開いているページを編集してreblog (http://www.tumblr.com/reblog/id のページを開く) location | reblog -m // ピンを立てたもの(なければ現在の)を全てreblog pinned-or-current-link | reblog | clear-pin
FastLadder(LivedoorReaderも?)でピンを立ててtを押してもunsafeWindowがどうこうと怒られてしまいます．原因が分かりません．分かったら直します．一応CodeReposにあげてるので誰か直してくれるとうれしいです．
特定のclass属性を持った任意の要素にマッチするXPath(hogeは指定したいclass属性名)
//*[contains(concat(" ",normalize-space(@class)," "), " hoge ")]
特定の要素にしたい場合は適当に
div[contains(concat(" ",normalize-space(@class)," "), " hoge ")]
などとする．
特定のclass属性を持った任意の要素にマッチするXPathというのはアドオンやUserJavaScript，スクレイピングの際にDOMノードを特定するために良く使いますが，XPathの書き方がマズイ人がたまにいます．普通に考えたらXPathはこうなります．
XPath1::
//*[@class="hoge"]
class属性は以下の引用部分に書かれているとおり，スタイルシート以外の目的で使っても良く，後述しますが複数の値を持つことも許されています．
The class attribute has several roles in HTML: * As a style sheet selector (when an author wishes to assign style information to a set of elements). * For general purpose processing by user agents.
しかし，XPath1では他のUserJavaScriptがclass属性を追加した時などに問題が起きます．(例えばcustomize googleというアドオンのWayBack Machineという機能も，今はどうかわかりませんが，2007-09-05時点ではLDRizeと一緒に使えないという問題がありました)
こうした問題が起きる原因は以下の2つです．
最終的には結論で示したXPathになるので大したことはありませんが，一応W3Cの原文の引用と一緒に説明します．
Multiple class names must be separated by white space characters.
なので，XPathは以下のようになるかと思います．
XPath2
//*[contains(concat(" ",@class," "), " hoge ")]
XPath2の動きを説明すると，
White space (spaces, newlines, tabs, and comments)
User agents should interpret attribute values as follows: * Replace character entities with characters, * Ignore line feeds, * Replace each carriage return or tab with a single space.
なので，XPathは以下のようになります．
XPath3
//*[contains(concat(" ",normalize-space(@class)," "), " hoge ")]
XPathの動きを説明する前にnormalize-spaceの調査．
The normalize-space function returns the argument string with whitespace normalized by stripping leading and trailing whitespace and replacing sequences of whitespace characters by a single space. Whitespace characters are the same as those allowed by the S production in XML.
日本語訳
normalize-space 関数は、引数に指定した文字列の空白文字を正規化して返す。つまり前後の空白文字を取り除き、連続する空白文字を１つの空白文字に置き換える。 空白文字は、XMLの S プロダクションで使用できるものと同じである。
S production in XMLってなんぞやってことでこれも調べる．
White Space [3] S ::= (#x20 | #x9 | #xD | #xA)+
確認(firebugで以下を実行)
// spaceとtabは普通に表示したら分からなかったのでキモい感じになってしまった
var chars = ["#x20","#x9","#xD","#xA"];
for(var i=0; chars.length>i; i++){
chars[i].match(/#x([0-9A-F]+)/);
var str = String.fromCharCode(parseInt(RegExp.$1,16));
switch(str){
case " ":
console.log("space")
break;
case "\t":
console.log("tab")
break;
default:
console.log([str])
}
}
// 実行結果
// space
// tab
// ["\r"]
// ["\n"]
なので，XPath3の動きは
class = cdata-list [CS]
CS:: The value is case-sensitive (i.e., user agents interpret "a" and "A" differently).
class属性の値はcase sensitive，つまり，大文字と小文字は別物なので，これの変換はいらない．
ちなみに，rel属性の値はcase insensitiveなので変換が必要(でもやり方が美しくない)で，しかも複数の値を持てる．(e.g. rel="friend met")
LDRize専用のオレオレフォーマット案には反対です．その理由を書きます．ついでに今後の展望について書くつもりでしたが，疲れたので途中まで．
- 内部向けのサイトなので，公にSITEINFOを書きたくない - 「v」「o」で開くようなリンクはなく，「j」「k」のスクロール操作だけを利用したい ちょっと特殊なケースですね．
実は，これは今まで見えにくかっただけで，LDRizeの一番の利点を生かしたケースじゃないかと思っています．ちょっとだけTumblrに書いたやつやちょっとだけTwitterに書いたやつ1ちょっとだけTwitterに書いたやつ2以外はまだオンラインにあげてないので，詳しくはまた今度書きますが(多分)，LDRizeの利点は以下の３つだと考えています．
じゃあ，今回のケースのようなサイトでLDRizeの「j」「k」スクロールだけを利用したいときにはどうすればいいでしょうか． オレオレフォーマットにはなりますが，SITEINFOに domain: 'microformats', paragraph: '//*[contains(concat(" ",@class," "), " ldrize-paragraph ")]' のような記述を追加し，サイト側のマークアップで対応するってのは現時点ではアリかなと思っています． 皆さん，どう思われますか．
と言われて，あとで書く！と思いながら随分時間が経ってしまいました．すいません．
AutoPagerizeのmicroformatsは，完全にAutoPagerize用です． 一方でLDRizeのカバーしている microformatsは，LDRizeのためのものではないので， LDRizeを動作させるためにマークアップすることが意味的に正しいとは限らないのですね．
引用部にもありますが，LDRizeが利用するmicroformatsはLDRize専用のものではありません．そもそもmicroformatsは，HTMLの構造をある程度統一することで，意味を持ったデータをプログラムから取得するものです．用途に対してmicroformatsを定義すると「１つの用途」にしか用いることができませんが，構造に対してmicroformatsを定義すると「複数の用途」に用いることができます．前者で複数の用途に用いてもいいのですが，もともと「１つの用途」のためのマークアップなので，変更があるかもしれません．変更された時に，そのmicroformatsを利用している別のプログラムもそのまま利用し続けていいと保証できるのでしょうか．
具体例を挙げます．
autopagerize_page_element は，AutoPagerize用のmicroformats(?)です．class="autopagerize_page_element"で指定された部分をclass="autopagerize_insert_before"で指定された部分の直前に挿入します．なので，autopagerize_page_elementは だいたいページのコンテンツの部分 となります．ですがautopagerize_page_elementという名称は 用途 を表しており，構造 を表しているわけではないので，ページのコンテンツの部分でない可能性もあります．
ここで，ページのコンテンツをスクレイピングしてページの要約を作るようなスクリプトが ページのコンテンツの部分 を欲しいとします．このスクリプトはautopagerize_page_elementを利用しても大丈夫でしょうか．もしHTMLが変更されてautopagerize_page_elementに広告が入り，メタデータ(時間,タグ,コメント etc)が入り，AutoPagerizeに利用するには問題ないがページのコンテンツの部分でない という状況になったら精度に問題が生じるのではないでしょうか．そう考えると，autopagerize_page_elementをAutoPagerize以外の用途に用いるのは避けたほうが良いでしょう．
では，このスクリプトはまた別に専用のmicroformatsを作るべきでしょうか？もし，autopagerize_page_elementのような用途に対するmicroforamtsではなく，ページのコンテンツの部分という構造に対するmicroformatsが定義されていればどうでしょうか？
話しは反れますが，CSSのお勉強系のサイトに，HTMLのクラス属性の設計で 構造 でなく 用途 を限定してしまい，とても恥ずかしいことになってる例の代表がよく載っていますよね． class="red" とか．
＃ wikipediaにも マイクロフォーマットには用途ごとに様々なものがある とか書いてあるのはどうにかしたほうが良いと思う．
ついでにmicroformatsの問題点について．
microformatsはお手軽な分，全然正確ではありません．もしautopagerize_page_elementがcontentsくらい短くなったら誤爆する可能性があります．その場しのぎの解決策としてはAutoPagerizeみたいに接頭辞をつけるか，hAtomみたいに親要素にhfeedをつける といった方法があります．kuさんの記事にもありますが，これはmicroformatsの限界なのでしょう．
microformats以外の方法がないかと探してみたところ，RDFaというものがありました．これはmicroformatsみたいに決まったクラスを指定したりしますが，XML名前空間を指定したりする必要があります．名前空間の指定があるので正確ですが，どこからどこまでがこの名前空間なのかという適用範囲を理解する必要があります．また，microformatsに比べてだいぶXHTMLが複雑になるので，美しくありません．microformatsでさえ面倒がってやってくれないのに，さらに数段階面倒なことはさせるのは非現実的です．
ついでにSITEINFOの問題点について．
少し前にAutoPagerizeのSITEINFOに「exampleUrlをつけるように」というお達しがでました．一度作成したSITEINFOがHTMLの変更によって無効化されることがあるため， 現在は有効なのか無効なのかの判断を機械的にできるようにするためです．それでも，その判断は別のスクリプトで行う必要があり，無効になっていた場合にwikiから外すのも人力で行う必要があります．
また，AutoPagerizeのデータを再利用する話しも出ています。
他のユーザースクリプトなりアドオンなりで前のページへのリンクの情報を使うような物もあるかもしれないし、 ということでSiteInfoには前のページへのリンクの検出ルール（prevLink）も含めてもらえると主に僕が嬉しいです。
仮に，prevLinkを追加したとしましょう.そうなると「この値も入れて！」って言う人がきっと他にも出てきます．となると， どんな名前がどんな意味を持っているのか をプログラム間で共通のものにする必要があるでしょう．ある人がmainContentという名前を追加して，他の人がsiteContentという名前を追加したけど意味は同じ，という状態になると，とてももったいないことになります．さらに前述したようなHTMLの変更が加わると，誰が変更するのか，全部変更しなければならないのか，何を表しているかも分からない値の変更はどうするのか，分かる範囲で修正した場合はどれが未変更の値なのかをどうやって区別するのか，といった問題も発生します．
ところで，GRDDLというものが少し前に勧告されています．これはmicroformatsを利用してRDFを抽出するために，head内にlink要素としてXSLT(XSLTじゃなくても良いけど普通はXSLTみたい)を指定するものです．RDFを抽出するXSLT側に，名前空間の指定などの面倒なことを隠蔽できるので，HTML側は普通にmicroformats的なマークアップをすれば良いのです．そして，headタグのprofile属性にちょろっと書き足してlink要素を書き足すだけです．microformats的な，と書いたのは，microformats.orgで決められたmicroformatsでなくても，XSLTさえ書けばRDFを抽出できるためです．
なのでGRDDLでRDFを抽出することは，microformatsの手軽さを保ったまま正確さを獲得できます．正確さといっても，HTMLを書いた人によって保証されるだけですが．
つかれたのでここまで．続きはまた今度．