はてなブックマーク

1. リダイレクトの意味と範囲 リダイレクト(redirection)は、あるいは漢字で「転送」とも呼ばれていたりしますが、言葉の問題として捉えるなら、なかなかに複雑な側面があります。ともすれば、redirectionと全く同じ挙動を、文脈によってrefreshやreloadと呼ぶことがあるからです。不毛な議論を避けるために、ここでは「コンテンツ側がURLを勝手に変更すること」としておきます。 余談ですが、例えば、英Wikipediaの記事「URL redirection」では、新しいリソースの場所をリンクで示す、いわゆる「手動リダイレクト」もリダイレクトに含めています。 例： ですから、(Here病については勘弁してもらうとして)上のような意味で使うときは、厳密に言えば「リダイレクト」ではなく「自動リダイレクト(自動転送)」とすべきだったのかもしれません。英単語の意味は「方向を変える、転

ウェブに限らず、コンピューター関連の機能は、日夜、新しいものが生み出されています。しかし、人間の扱いきれる量には限りがあるものですから、それは、生き残ることができないモノが沢山ある、ということでもあります。誰にも見向きもされずに、比較的早い段階で消えてくものもあれば、５年、10年、といった、この世界では由緒を誇れる年月を経たものでも、いつの間にか無くなっていたりします。裏を返せば、「化石のような時代遅れの機能だった」ということになるのでしょうか。まあ、消えていくのは、大抵の場合、ほとんどの人にとって不要なものですから、そういう意味での「惜しさ」というものはありませんが、一方で、妙に心惹かれるものがあります。 Firefoxに関して言うなら、今まさにMicrosummariesが消えようとしています。私自身は一度も使ったことがないので、その点には痛痒を感じませんが、対応ページの提供者・利用者

結論から言うと、HTMLのtitle要素は失敗で、最初から全てtitle属性にしておけば良かった、と私は思っています。ただ、title要素が要素であることにもきちんとメリットはありますし、互換性を考えると今さらどうしようもないことではありますが、まあ、こういう意見もある、ということでひとつ。 HTMLは既に1.0の時から、title要素とtilte属性の役割を区別していました。title要素は書かれている文書のタイトルで、title属性はリンク先の文書のタイトルです。現在のtitle属性はリンク先に限りませんから、少し用途が広くなっているものの、基本的な用途は概ね同じと言えるでしょう。後知恵ですが、これは、そもそも、分ける必要がなかったと思います。どちらも親ノードの表題ですから、何を指しているのか、少なくともパーサーにとっては自明です。 (SGMLの)属性は要素に比べて少し窮屈な機能です。

例えば、img要素にウェブ上の画像を読み込んで、完了後に何らかの処理を行う必要があったとします。その際、 var image = document.createElement("img"); image.src = "http://www.example.com/foo.png"; image.onload = function() {alert("Loading has finished!");}; var image = document.createElement("img"); image.onload = function() {alert("Loading has finished!");}; image.src = "http://www.example.com/foo.png"; の両者を比べて、どちらが正しいと思いますか？ 蛇足ですが、2行目と3行目が入れ替わっているだけ

数年前、「cite属性は(法的な意味も含めて)引用元の明示とみなせるのか」という論争がありました。当時、私は全く興味がなく、この件を知ったのは随分と後になりましたが、今読んでも面白いので、未読の人は検索してみることをお勧めします。ちなみに、私はどちらかというと肯定派、つまり「cite属性だけで十分だ」と思っています。 何分、古い話なので、議論の多くはネット上から散逸(というか湮滅というか)してしまっています。そんな中、野嵜健秀氏の『闇黒日記』にこんな記述がありました。 http://noz.hp.infoseek.co.jp/diary/20020505.html Netscape 6/Mozilla Browserでは、blockquoteのプロパティでcite屬性のURIを參照出來ますし、そこから出典の文書にジャンプする事も出來ます。 野嵜氏の結論は、ジャンプの可否に関わらず変わらない

スラッシュドットの「HTML5策定におけるOgg Vorbis/TheoraとDRMの扱いを巡る攻防」他について。 http://srad.jp/mac/article.pl?sid=07/12/11/1950248 これは、議論が変な方向に行っていて、 などと納得している人がいますが、削ったのはOgg系が候補から外れた事実を内外に示すためで、上のような曖昧な責任回避の結論で収まる気配はありません。現実的には、TheoraとH.264のいずれかしかあり得ないので、現在は、仕様内にH.264云々を盛り込む直前である、とも言えるでしょう。Nokiaの論文にしても、前後を知らなければ如何様にも解釈できるでしょうが、この文脈で言っているのは、「H.264以外は認めない」ということだけで、他意はないと見るべきです。どうにも混沌とした状況ではありますが、おおまかに次のような3つの勢力に図式を単純化する

このアンチフィッシング機能は、ちょっと問題アリだと思います。ただ、まあ、どう贔屓目に見ても、ないよりはあった方がいいですよね。ブラウザの差別化というマーケティングの効果も見逃せませんし。 私が言ってる問題とは、独占のことです。設定窓を見ると、あたかもGoogle以外の選択肢があるような作りですが、実はありません。いろんな人の話を総合すると、意図的に参入のハードルを高くしているようです。http://wiki.mozilla.org/Phishing_Protectionに、４ページに渡って仕様が書かれていますが、これを精読しても、サーバーの運営は不可能で、結局のところソースを読むしかありません。そして、そこまでしてサービス環境を構築してペイするのか、というのも疑問です。別にGoogleが悪いわけじゃないんですけど。 Googleはフィッシングサイト報告を人力で確認して、その後に、ブラックリ

mozIStorage***を使って、ベイズ判定を書き起こしてみました。 汎用ベイズ判定のソース（Gary Robinson 前期型） もちろん、データベースは学習データの記録に使っています。 あ、汎用というのはスパム/ハム選別以外にも使うことを想定しているからで、たとえば、「このサイトはアレゲ指数0.89だから、かなりアレゲだな」などという使い方ができます。あらかじめ、アレゲなサイトとそうでないサイトを学習させてやるのが大変かもしれませんけど。 使ってみた感想は、精度は予想よりかなりいいです。スパムフィルタリングのように真剣な用途だと、false-negativeを気にして片面95パーセントなど、カリカリのチューニングが要求されますが、遊びで使う分には、学習数がそれほどなくても、かなり直感と合う数字を返してくれています。後述のように、Thundebirdのよりもアルゴリズムでは劣っている

Japanizeの新バージョンがリリースされているので、今度は安全性について、つまり、旧版のセキュリティ上の問題点にスポットライトを当ててみたいと思います。 と、その前に、私は前回の日記のコメントに と書きましたが、この新バージョンでは、私が前回の日記で指摘したプライバシー上の問題点が早くも克服されています。これは、いろいろな意味で、非常に喜ばしいことだと思いますし、この点について高く評価すべきだと思います。 では、本題です。まず、Japanizeで使われている翻訳データがJavaScriptである、というところがポイントです。といっても、どういうものかピンと来ないと思うので、実際のデータを見て下さい。 例えば、www.google.comの場合だと、該当データは http://japanize.31tools.com/data/www.google.com/current.txt です。

SQLiteのfull-text indexing(全文索引)機能の導入に伴い、Firefoxも履歴やブックマークの全文検索をサポートするのはほぼ確実だと思います。 http://www.sqlite.org/cvstrac/wiki?p=FullTextIndex https://bugzilla.mozilla.org/show_bug.cgi?id=342915 そこまではいいんですが、問題は日本語対応です。単語が空白で区切られている欧文と違って、日本語（に限りませんけど）では、わりと正確に分かち書きしないと、検索精度ががくっと落ちます。今、出回っている全文検索アプリケーションは、大抵、形態素解析ツール（フリーでは、KAKASI、ChaSen、MeCabなど）を使って、単語や形態素まで分離してから、改めてインデックス化しています。 性能をとるなら、MeCabあたりをバンドルするのが一