Days on the Moon

jQuery のバグを見つけてから修正されるまで

Mon, 28 Jan 2013 02:17:10 +0900

1 月 24 日に開催された Kyoto.js meetup 4 で「jQuery のバグを見つけてから修正されるまで」と題した発表を行いました。

jQuery へのコミットに関して 2 行でまとめるとすれば次のようになるでしょうか。

jQuery のソースコードはショートコーディングの嵐なので心してかかる
Contributing to jQuery と jQuery Core Style Guidelines は必読

発表の筋書きは以下の通りです。

jQuery のバグを見つけてから修正されるまで

フォロー・ミー

nanto_vi (TOYAMA Nao)
株式会社はてなアプリケーションエンジニア
- クライアントサイド (JavaScript)
- サーバーサイド (Perl)
jQuery をバリバリ使っている
- Deferred
- イベント
- DOM 操作

バック・トゥ・ザ・フューチャー

どこを直せば自分のコードが動くのか

コードとにらめっこ

にらめっこ

……

問題なのはここ、でもここを変えると先の変更の意味が失われるから……

こことここか!

羊たちの沈黙

直すならテストを書かないと

テストを書くならテストを走らせないと

テストを走らせるなら jQuery のビルド環境を作らないと

grunt? Node.js なら入ってるし楽勝でしょ

……

うわあ、この Node.js バージョンが古い!

うわあ、この OS バージョンが古い!

うわあ、この Python (ry

……

沈黙

そしてクリスマスが過ぎ、正月が過ぎた

風と共に去りぬ

やっぱり正月松の内は休まないとね

ってなになに……

げげー、1.9-stable ブランチ!

もはや一刻の猶予も許されない

禁じられた遊び

ビルド環境がないならテスト環境を作ればいいじゃない

俺にはこの SpiderMonkey JavaScript Shell がある!

秘技、テストのコピペ改変!

荒野の用心棒

#13160 (Deferred.then doesn't propagete custom context) -- jQuery Core - Bug Tracker

「これ直さへんとあかんちゃう?」

J 「プルリクエストにしてーな」

「プルレクったでー」

D 「ここ冗長やろ。もっと削れるやろ」

(そない言われても…… これ以上どう切り詰めろいうんや……)

(しゃあないな、この条件分岐をもっと前に持ってきて……)

(あれ、この変数、フラグに流用できるちゃうか……)

「どや!」

D 「まあええんちゃうか」

素晴らしき哉、人生!

D 「修正取り込んだで。おーきに」

J 「僕と契約して貢献者になってよ!」

jQuery 1.9 final, jQuery 2.0 beta, Migrate final released | Official jQuery Blog

めでたしめでたし

※ この物語は実話を基にしたフィクションです。

jQuery で HTTP 接続するときの書き方

Sun, 16 Dec 2012 19:41:58 +0900

12 月 13 日に Kyoto.js の第 3 回 meetup で、「jQuery で HTTP 接続するときの書き方」と題した 5 分間のライトニングトークを行いました。以下にその内容を一部再構成して収録します。

こんにちは、nanto_vi です。今日は jQuery で HTTP 接続をするときの書き方について話します。

皆さん jQuery を使うことも多いかと思います。jQuery で HTTP 接続をするとき、古いサンプルだと次のような書き方が載っています。

$.ajax({
    url: '/foo/bar',
    data: { baz: 'qux' },
    success: function (data) {
        console.log(data);
    },
});

接続完了時の処理をコールバック関数として $.ajax() に渡してやる形ですね。~~しかし、現在この書き方は非推奨となっており、替わりに~~次のようにも書きます。

$.ajax({
    url: '/foo/bar',
    data: { baz: 'qux' },
}).done(function (data) {
    console.log(data);
});

$.ajax() の返り値に対して、done メソッドで接続完了後の処理を登録する形です。この書き方の何がいいかといえば、返り値を使いまわしたり done メソッドを複数回呼び出したりして、完了後の処理を後から追加できるところです。昔の書き方では完了後の処理がコールバック関数として $.ajax() の内部に格納されていましたが、現在は「完了後の処理」だけを $.ajax() の外部に (「プロミス」として) 取り出すことが可能になったわけですね。

今「内部の処理を外部に取り出す」と言いましたが、この言葉はどこかで聞き覚えがありませんか。そう、内部イテレータと外部イテレータです。

内部イテレータは、オブジェクトが個々の要素に対する処理を受け取り、オブジェクト内部で自身の各要素に適用させる形、

// 内部イテレータの使用例
$('p').each(function () {
    doSomethingWith(this);
});

外部イテレータは、オブジェクトから「各要素を列挙する」という機能だけをオブジェクト外部に取り出す形です。

// 外部イテレータの実装例と使用例
$.fn.iterator = function () {
    var i = 0, n = this.length, self = this;
    return {
        hasNext: function () { return i < n; },
        next: function () { return self[i++]; }
    };
};

var iterator = $('p').iterator();
while (iterator.hasNext()) {
    var element = iterator.next();
    doSomethingWith(element);
}

JavaScript 1.7 以降ではジェネレータという機能により、内部イテレータのような書き方で外部イテレータを生成することができます。

さて、「処理を内部に持ってしまっている」というのは、イベントハンドラの登録も同じですね。

$(document).on('click', function (event) {
    ...
});

イベント発生時の処理をコールバック関数として jQuery オブジェクト内部に渡していますが、これを外部に持ち出すことはできないのでしょうか。

実はそれを可能にするものとして Reactive Extensions (Rx) があります。Rx 入門記事の図にもあるように、Rx を使うと空間にまたがる要素 (配列など) の列挙と時間にまたがる要素 (イベントなど) の列挙を統一的に扱うことができます。

Reactive Extensions は主に .NET Framework 上で利用されていますが、JavaScript での実装として RxJS が公開されています。

ObserverパターンとIteratorパターンは同じだったんだよ！なんだってー！

neue cc - .NET Reactive Framework メソッド探訪第一回:FromEvent

そう、ObserverパターンとIteratorパターンは同じなのだよ、ナンダッテー！

neue cc - Reactive Extensions for JavaScript

(このあたりで時間切れ)

はてなでコードを書くときに気をつけていること

Sun, 18 Dec 2011 14:37:15 +0900

こんにちは、はてなでアプリケーションエンジニアをしている nanto_vi です。この記事は Hatena::Staff Advent Calendar 2011 の一環として書いています。Advent Calendar の会場ははてなブログとなっていますが、主催の antipop さんに尋ねたところ何でもよいというような返答があったのでここで書きます。

はじめに謝っておきますが、この記事ははてなとほとんど関係がありません。タイトルに「はてな」と入っているのは Advent Calendar の要件を満たすための目くらましあり、内容はといえばはてなのノウハウでもなんでもない、私が最近個人的に心がけていることです。ごめんなさい。

できれば明示的に

業務で書くコードは複数人により読み書きされメンテナンスされるので、わかりやすさが重要になってきます。わかりやすさを保つためには暗黙的に行われる操作を減らし、明示的にコードに表した方がよいと感じます。たとえば、Perl では、

use Encode;

# encode_utf8 関数は Encode モジュールで定義されている
my $octets = encode_utf8 $string;

のようにモジュール読み込み時に自動的に関数をインポートすることができますが、それよりも、

use Encode qw/encode_utf8/;

my $octets = encode_utf8 $string;

のようにインポートする関数を明示的に指定したほうが、その関数がどこで定義されているのかわかりやすいでしょう。

個人的には、関数や変数の名前で grep をかけてその定義(外部で定義されている場合は宣言)を探し出せることが、「明示的」であるための最低線ではないかと思います。

入力には正規化を、出力には符号化を

アプリケーションを作るうえで入出力の扱いは避けて通れません。入力元はユーザーだったりバッチ処理スクリプトの引数だったり、出力先はユーザーだったりデータベースサーバーだったりしますが、いずれにおいても入力には正規化処理を、出力には符号化処理を、それぞれ施すことになります。

正規化は一般に不可逆です。空白文字類をすべてスペースに置換した後はもともとスペース以外の空白文字が含まれていたのかわかりませんし、数値「42」を生み出した入力は "42" でも "42.0" でも、はたまた "0x2A" でもありえます。

符号化は一般に可逆です。あるデータをユーザーのもとへ送り届けるのに、そのデータを HTML のテキストとして扱えるよう一部文字を文字参照の形に符号化し、その HTML ソース全体を文字符号化方式 UTF-8 をもって符号化し、さらには HTTP メッセージに、TCP のセッションに、IP のパケットにと符号化を重ねていきますが、それらすべては符号化規則を逆に適用することで元の形式へ復元できます。

たとえば HTML として解析され、その結果が JavaScript の文字列として、HTML として、URI としてと順に解析されるデータを Template-Toolkit で出力する場合、解析の逆順でそれぞの形式に応じた符号化を施す必要があります。

<script type="text/javascript">
document.write('<a href="/search?q=[% word | uri | html | js %]">検索<\/a>');
</script>

script 要素の内容は CDATA 型であり文字参照は解決されないので、最後に html フィルタをかけることはしません。また、そもそもこのような多重にフィルタをかける事態は避けたほうが賢明でしょう。

入出力いずれにおいても、データがどういう形式で扱われるのかを意識し、それに応じた正規化処理または符号化処理を施すことで、意図しない入力が致命的な挙動を引き起こすこともある程度は防げるのではないかと考えます。

次は hitode909 さんです。

IE 6/7 で文書間通信を実現するための一案

Thu, 08 Dec 2011 23:32:29 +0900

HTML5-WEST.jp 飲み会 UST というのがあるそうで、「参戦希望者募集」とお誘いを受けたのですが、「参戦」というからには何かしら戦の準備を整えねばなるまいと、以前から考えていたことを夜なべして実装しました。

いわゆる HTML5 の文書間通信、window.postMessage() を IE 6/7 でどう再現するかという話で、about:blank を指す隠しフレームを二つ用い、window.name を介することで双方向の通信を実現しています。

どうも IE での about:blank は、その空白ページを読み込ませた文書の生成元を継承するらしく、たとえば http://example.org/ から location.href = 'about:blank'; を実行すれば http://example.org を生成元とする about:blank になります (少なくともそのように見えます)。これを利用し、一つのフレームに二つの文書から交互に about:blank を読み込ませあうことで、そのフレームの window.name を両文書で共有できるという仕組みです。

about:blank を読み込ませるのに location.reload() を使えば履歴に余分な項目を残すこともありませんし、フラグメント識別子を使った場合と違ってデータ量にもだいぶ余裕が出ます。

Template::Plugin::JSON::Escape 公開

Wed, 15 Jun 2011 20:57:49 +0900

Template::Plugin::JSON::Escape という Perl モジュールを公開しました。

Template Toolkit を使って HTML を出力するとき、HTML 中に JSON を埋め込みたいことがあります。そのためのモジュールとして Template::Plugin::JSON が存在するのですが、これは小なり記号 (<) などの文字を素通しするため、JSON の内容によっては不正な HTML が出力されてしまいます。

Template::Plugin::JSON::Escape は一部記号を \uxxxx の形式にエスケープするので、JSON の内容にかかわらず出力する HTML を妥当に保てます (もちろん、JSON 出力部以外が妥当な HTML を出力するのであれば、です。なお、SGML のコメント内に JSON を埋め込む場合はこの限りではありません)。副次作用として、XSS の防止にも一定の効果を期待できます。

また、Template::Plugin::JSON 0.06 は Moose を使っていますが、私が普段 Perl を使っている環境には Moose が入っていません。そのためだけに Moose を導入するのは難しいので、Moose を使用しないモジュールが求められていたというのもあります。

Perl の URI モジュールにおける文字列とオクテット列の扱いに関して

Fri, 27 May 2011 17:28:04 +0900

Perl の URI モジュールには ASCII 外の文字の扱いに関して欠陥がある。ここでは Perl における URI の扱いについて述べ、URI モジュールの修正方針を提案する。

この記事で取り上げた問題に関して主たる部分は URI.pm 1.59 で (この提案とは違った形で) 修正済みであり、この提案は obsolete です。

用語の定義

URI: RFC 3986 (日本語訳) で定義される識別子。
URI.pm: Perl の URI モジュール。ここでは、ファイルとしての URI.pm だけでなく、URI パッケージ下に含まれるコード全般を指す。断りがない限りバージョン 1.58 に基づく。
文字列: UTF-8 文字列と Latin-1 文字列のいずれか。
UTF-8 文字列: Perl の文字列値で、UTF8 フラグが立っているもの。
Latin-1 文字列: Perl の文字列値で、UTF8 フラグが立っておらず、文字の並びとして扱われることを期待されているもの。
オクテット列: Perl の文字列値で、UTF8 フラグが立っておらず、バイトの並びとして扱われることを期待されているもの。Latin-1 文字列とオクテット列の機械的な判別は不可能。

発端となった問題

URI.pm のメソッドに UTF-8 文字列とオクテット列を同時に渡した場合、期待した出力が得られないことがある。特に Perl 5.10 以下では、use utf8 環境下で bareword に UTF8 フラグが立つため、この問題が発生しやすい。

#!/usr/bin/perl5.8.8
use strict;
use warnings;
use utf8;
use URI;
use Encode qw/encode_utf8/;

my $uri = URI->new('http://example.org/');
$uri->query_form( foo => encode_utf8('字') );
print $uri->query, "\n";
# actual:   "foo=%C3%A5%C2%AD%C2%97"
# expected: "foo=%E5%AD%97"

Perl において URI はどう扱われるべきか

URI は US-ASCII の範囲内の文字で構成されるが、特定の文字符号化方式を仮定しない。URI には任意の文字符号化方式で符号化されたオクテットの並びが (パーセントエンコードされて) 含まれうる。たとえば、二つの URI http://ja.wikipedia.org/wiki/%E3%81%AF%E3%81%A6%E3%81%AA と http://d.hatena.ne.jp/keyword/%A4%CF%A4%C6%A4%CA において、パーセントエンコードされた部分はいずれも「はてな」という文字の並びを表すが、前者は UTF-8、後者は EUC-JP で符号化され、パーセントエンコードされたものである。

それゆえ、Perl において URI はオクテット列として扱われるべきである。そのオクテット列がどの文字符号化方式を用いて解釈されるかは、URI とは別の層の問題である。

URI.pm をどう修正すべきか

現在、URI.pm では入力を文字列として扱うものとオクテット列として扱うものが混在している。たとえば、host メソッドの引数に渡した値は UTF-8 文字列または Latin-1 文字列として解釈され、query メソッドの引数に渡した値はオクテット列であるかのように扱われる。

ここでは、前節の主張に従い、URI.pm に関する入出力はすべてオクテット列として扱うことを提案する。IRI に関するものを除き、URI.pm の各メソッドに渡された引数はすべてオクテット列とみなされ、返り値はオクテット列となるべきである。

引数に UTF-8 文字列が渡された場合は、それを UTF-8 で符号化されたオクテット列として扱うのがよいと考える。HTTP::Message の content メソッドのように UTF-8 文字列を渡されたらエラーとするのもひとつの手ではあるが、現在の URI.pm との互換性を大きく損ねないためにはエラーにしないほうがよいと判断する。

国際化ドメイン名の扱い

URI.pm の入出力をオクテット列とみなすとき、問題となるのは国際化ドメイン名の扱いである。本来なら ASCII 外の文字を含めるのに URI::IRI のような専用のモジュールを使うべきだろうが、現在の URI.pm との互換性を損ねないためには、URI->new(...) や $uri->host(...) で ASCII 外の文字を指定できるのが好ましい。

あくまで入力はオクテット列とみなすという方針を貫きつつ国際化ドメイン名を受け付けるため、URI のホスト部に関してはオクテット列を UTF-8 で符号化されたものとみなし、UTF-8 でデコードした文字列を Punycode 符号化して出力のホスト部とする。

URI.pm の互換性の確保

ここで提案する修正により、URI.pm は後方互換性を失う。特にホスト部に関しては、これまで Latin-1 文字列として扱われてきたものが、UTF-8 で符号化されたオクテット列として扱われ、まったく違った出力を得ることになる。

そこで、過去の挙動に戻せるよう、$URI::COERCE_OCTETS 変数を設ける。この変数のデフォルト値は真であるが、値が偽なら以前と同様に入力をオクテット列とみなさず処理を行う。

修正の段取り

以上の提案を実装すべく、現在 github の nanto/uri レポジトリの coerce_octets ブランチで作業中である。さしあたってどのような出力を期待しているのか明らかにするため、ASCII 外の文字を含む入出力に関するテストを書いた。実装が一段落したら URI.pm に対するパッチとして提出するつもりである。

#43859: should be _utf8_off -ed raw data before URI encoding に修正の URL を添えて返信した。

chrome URL からファイル一覧を取得する

Wed, 12 Jan 2011 01:41:12 +0900

Firefox にて、ディレクトリを指す chrome URL から、そのディレクトリ以下の全ファイルの URL を返すサンプルコードを書きました。

ChromeFiles.get("chrome://browser/content/");
/* => [ "chrome://browser/content/NetworkPanel.xhtml",
 *      "chrome://browser/content/aboutDialog.css",
 *      ...,
 *      "chrome://browser/content/browser.css",
 *      "chrome://browser/content/browser.js",
 *      "chrome://browser/content/browser.xul",
 *      ... ]
 */

特徴として、実際のファイルが (.jar または .xpi に) パッケージ化されているかどうかに関わらず、ファイル一覧を取得できることが挙げられます。ソースコード全体は上記 Gist へのリンクを参照してもらうとして、以下は各関数の解説です。

var ChromeFiles = {
    get: function CF_get(spec) {
        const ios = Cc['@mozilla.org/network/io-service;1'].
                    getService(Ci.nsIIOService);
        let uri = ios.newURI(spec, null, null);
        return this.getByURI(uri);
    },

    ...
};

単に、文字列として受け取った URL を nsIURI のインスタンスにして、getByURI() へ処理を委譲しているだけです。

getByURI: function CF_getByURI(uri) {
    // 1. ディレクトリを指す URL にする
    let baseURI = uri.clone().QueryInterface(Ci.nsIURL);
    baseURI.path = baseURI.directory;

    // 2. chrome URL からローカルファイルシステムでの URL へ変換
    const registry = Cc['@mozilla.org/chrome/chrome-registry;1'].
                     getService(Ci.nsIChromeRegistry);
    let localURI = registry.convertChromeURL(baseURI);

    // 3. ディレクトリ中のファイル名を取得
    let leafNames = null;
    if (localURI instanceof Ci.nsIFileURL) {
        leafNames = this.getLeafNamesByDirectory(localURI.file);
    } else if (localURI instanceof Ci.nsIJARURI) {
        leafNames = this.getLeafNamesByJARURI(localURI);
    } else {
        throw new Error('Unknown URI: ' + localURI.spec);
    }

    // 4. ディレクトリのパスとファイル名を結合
    let baseSpec = baseURI.spec;
    return leafNames.sort().map(function (leafName) baseSpec + leafName);
},

chrome URL において、chrome://{package}/content/ と chrome://{package}/content/{package}.xul は同じリソースを表し、nsIIOService#newURI() の引数に前者を渡しても返ってくる URI オブジェクトの spec は後者になります。確実にディレクトリを指す URI オブジェクトを得るためには、自分で URI オブジェクトのプロパティを変更しなければなりません。

ところが、newURI() で作られたオブジェクトは可変でない (immutable な) ことがあり、このときプロパティに値を設定しようとすると例外が発生します。chrome URL の場合 clone() で生成した URI オブジェクトは可変になるので、まずは URI オブジェクトを複製します。

パスからディレクトリ部分だけを抜き出すのは、nsIURL インターフェースの directory プロパティを使うのが簡単です。nsIURL インターフェースを経由すれば、ディレクトリ以外にもファイル名や拡張子などをすぐに取得できます。
chrome URL からローカルファイルシステム上でのファイル位置をあらわす URL への変換は、nsIChromeRegistry#convertChromeURL() で一発です。これにより得られる URL は大抵の場合 file URL か jar URL かのいずれかです。
ディレクトリ中のファイル名一覧を配列として取得します。処理本体は file URL の場合と jar URL の場合で別になります。

なお、QueryInterface() を使わなくとも、instanceof 演算子で nsIFileURL インターフェースを実装していることを確認できたなら、それ以降は nsIFileURL の file プロパティから nsIFile オブジェクトを取得できます。
得られたファイル名一覧の順序はわからないので、辞書順で並べ替えます。その後にディレクトリ部分を表す chrome URL と結合すれば、ディレクトリ直下のファイルを指す chrome URL の一覧が得られます。

getLeafNamesByDirectory: function CF_getLeafNamesByDirectory(dir) {
    let files = dir.directoryEntries;
    let leafNames = [];
    while (files.hasMoreElements()) {
        let file = files.getNext().QueryInterface(Ci.nsIFile);
        if (file.isFile())
            leafNames.push(file.leafName);
    }
    return leafNames;
},

ディレクトリを表す nsIFile オブジェクトから、その子ファイルの名前一覧を取得します。単に子ファイルを列挙していき、それがディレクトリなどでないときにファイル名を取得するだけです。

getLeafNamesByJARURI: function CF_getLeafNamesByJARURI(jarURI) {
    // 1. ZipReader を作成
    let zip = this.openZipReader(jarURI.JARFile);

    try {
        // 2. ディレクトリ直下のファイルのパスを取得
        let baseEntry = jarURI.JAREntry;
        let pattern = baseEntry + '?*~' + baseEntry + '?*/*';
        let entries = zip.findEntries(pattern);

        // 3. ファイル名部分だけを抜き出し、返す
        let leafNames = [];
        while (entries.hasMore())
            leafNames.push(entries.getNext().substring(baseEntry.length));
        return leafNames;
    } finally {
        zip.close();
    }
},

jar URI は jar:file://path/to/file.jar!/path/to/entry/ のような形で表されます。nsIJARURI インターフェースは、file://path/to/file.jar の部分を示す JARFile プロパティ (返ってくるのは nsIURI オブジェクト) と、/path/to/entry/ の部分を指す JAREntry プロパティ (返ってくるのは文字列) を持っています。

JAR ファイル (または XPI ファイル) は ZIP 書庫なので、内部のファイル情報を読み取るためには nsIZipReader のインスタンスを作成し書庫を開く必要があります。
書庫内部のファイル名一覧を取得するには findEntries() を使います。ここで指定するファイル名のパターンにおいて、"?" は任意の1文字を、"*" は任意の文字列を、"pattern1~pattern2" は pattern1 にマッチするが pattern2 にはマッチしないものを表します。

"/path/to/entry/*" というパターンでは /path/to/entry/ 自信も含まれてしまうので、ディレクトリではないファイルだけを抽出するために "/path/to/entry/?*" と指定します。また、それだけだと子孫ディレクトリ中のファイルも含まれるので、"/path/to/entry/?*/*" を除外してやります。
findEntries() で得られた値にはディレクトリ部分も含まれるので、その部分は切り取ってファイル名だけにします。

openZipReader: function CF_openZipReader(uri) {
    let zip = Cc['@mozilla.org/libjar/zip-reader;1'].
              createInstance(Ci.nsIZipReader);
    if (uri instanceof Ci.nsIFileURL) {
        // 1. file URL なら単にそのファイルを開く
        zip.open(uri.file);
    } else if (uri instanceof Ci.nsIJARURI) {
        // 2. jar URL なら JAR ファイル内部のファイルを開く
        let innerZip = this.openZipReader(uri.JARFile);
        zip.openInner(innerZip, uri.JAREntry);
    } else {
        throw new Error('Unknown URI: ' + uri.spec);
    }
    return zip;
},

JAR ファイルがローカルファイルシステム上に直接存在するなら、単に open() メソッドにファイルオブジェクトを渡して開くだけです。
開こうとする JAR ファイルが別の書庫内に存在することもあります。その場合は openInner() に、JAR ファイルが含まれる書庫と、その書庫内での JAR ファイルのパスを指定してやります。

nsIZipReader#openInner() は Firfox 4 で追加されたものですが、Firefox 4 より前では jar URL がネストすることはないといっていいので、ここで使っても問題ないでしょう。

たとえば Firefox 4 Beta でツリー型タブを使うと、chrome://treestyletab/content/ の実体は jar:jar:file://{profile}/extensions/treestyletab@piro.sakura.ne.jp.xpi!/chrome/treestyletab.jar!/content/treestyletab/ といった URL になりますが、上記のようにすればその内部のファイル構成を知ることができます。

また、resource://gre/modules/XPCOMUtils.jsm といった resource URL に関しても、nsIResProtocolHandler#resolveURI() を使えばローカルファイルシステム上の URL へ変換でき、上と同様にファイル一覧の取得などが可能になります。

Firefox Developers Conference 2010

Tue, 28 Dec 2010 00:18:38 +0900

Firefox Developers Conference 2010 に行ってきた。全体のまとめとしては以下が詳しい。

はてなブックマークで fxdevcon タグがつけられたエントリーを見てまわるのもいい。Firefox 4 ベータ版機能概要では新しいタブインターフェース "Panorama" の紹介動画を見られる。

内容に関しては上述のページを参考にしてもらうとして、個人的に感じたことををいくつか挙げる。

Beyond Firefox 4 (Jay Sullivan)

Mozilla はユーザーの選択肢を広めることを重視する、逆に言えば単一のプラットフォームを目指すわけではないということのようだ。

John Resig feat. Shibuya.js

10+1 Things you should know about JavaScript testing (t_wada)

私の場合、Web ブラウザ向け JavaScript のテストを書いていないのはさくっとテストできる環境を知らないからというのが大きい。Firefox 拡張に関しては UxU という素晴しい環境があったから部分的とはいえテストを書けた。

カスタムイベントで処理をつなぐというのは結構やる。イベントモデルの実装も何回かやったけど、jQuery が使えるなら jQuery の実装 (bind、trigger) を使うのが楽だ。カスタムイベント名には Progress Events 仕様で提案されているものを流用したほうがいいかと思ったが、trigger 時に独自引数を渡すならかえって紛らわしいかもしれない。

// 独自のオブジェクトに jQuery のイベントモデル実装を組み込む例

function Loader() {
    this.$ = $({});
}
$.extend(Loader.prototype, {
    method: function () {
        this.$.trigger('load', args);
    }
});

var loader = new Loader();
loader.$.bind('load', function (args) {});

Node.js にまつわる 7 つの誤解 (meso)

現在、Node.js の開発は個人の手を離れ Joyent 社主導で行われているそうだ。会社によってはライブラリ/フレームワークの採用基準に、それが一定規模の団体によって保守されているかどうかが含まれるだろうから、Node.js の普及を促進する上ではよいことだと思う。

トークセッション: HTML5 時代の技術で Web プラットフォームはどう変わるのか (矢倉眞隆、村岡正和、浅井智也)

W3C CSS working group ではレイアウト関係が要注目とのこと。Flexible Box Layout Module は Mozilla の XUL ボックスモデルに由来するもので、(Mozilla から Apple へ移籍した Dave Hyatt の手により) 類似のモデルが WebKit でも実装されている。ただし、現在の草案は display プロパティの値に "box" ではなく "flex" を採用するなど、両実装と異なる点が多い。Grid Alignment Module は Microsoft が中心となって策定を進めている (編者の一人 Alex Mogilevsky は Flexible Box Layout Module の編者も兼任)。両モジュールともアプリケーション UI の整形を念頭に置いているが、手軽さでは Flexible Box、柔軟性では Grid Alignment が勝っているように感じる。

まとめとして、矢倉氏は描画には canvas だけでなく SVG、通信には WebSocket だけでなく Server-Sent Events など、あることを実現するのにさまざまな手段があるのを知ってほしいと、村岡氏は積極的に HTML5 を書き、関連 API を使って開発し、そして仕様策定者側にフィードバック (提案) しようと述べていた。

大ライトニングトーク

HTML 2.0 (TAKESAKO)

"2.0" というのはバズワード。HTML パーサのエラー処理方法の違いを利用してブラウザを判別する試みである。HTML5 では HTML 構文の解析方法がエラー処理も含めて規定されるので、今後ブラウザが HTML5 HTML 構文に対応していく中でこのような試みは困難になっていくと思われる。

placeholder 実装マニアックス

テキスト入力欄に何らかのメッセージを表示し、入力欄にフォーカスするとそれが消えるという UI は以前から見られた。HTML5 では placeholder 属性でこのメッセージを指定できるが、未対応ブラウザでこの挙動を再現しようとすればスクリプトを使う必要がある。

まず考えられるのは入力欄の value プロパティにメッセージの文面を設定し、フォーカス移動に際してこれを消去することである。しかしこの場合、フォーム送信時のメッセージ消去や、ブラウザがフォームコントロールの入力値を記憶することへの対処が必要となる。

別の方法として、CSS を使いメッセージと入力欄を重ね合わせることも可能だ。メッセージ部分を絶対配置の要素とし、文書木上では入力欄の直前に挿入する。left 及び top プロパティを指定しなければ絶対配置の要素は「その要素が絶対配置でなかったときの位置」に置かれる。この絶対配置要素の初期位置は意外と便利で、top、left、right、bottom プロパティのいずれかひとつのみ指定すれば、水平方向または垂直方向にだけずらすこともできる。

なお、placeholder に指定するのは入力欄に関する補助的な情報 (なくても問題ないもの) であり、入力欄に対するラベルではない。ラベルは label 要素で指定する。中には入力中に参照したい情報もあるだろうし、状況によっては placeholder の内容が提示されないこともあるようなので、そもそも placeholder を使うべき場面なのか検討したほうがいい。

懇親会

食事があっという間になくなってしまったのが残念だった。

ブラウザの進化速度は速い。できることはどんどん多くなるが、それらをどう組み立てていくかというパターンはまだ不安定に思える。その部分を探っていきたい。

リンクのようなボタンを作る

Wed, 15 Dec 2010 23:52:28 +0900

こんばんは、JavaScript Advent Calendar 2010、15 日目担当の nanto_vi (なんと) です。12 月 15 日が何の日か調べてみると東北本線が宮城県に到達した日とのこと。当時は上野から仙台まで 12 時間 20 分かかったそうです。それから 123 年を経た現在では同じ時間で鹿児島中央から新青森まで行けるようになり、鉄道の速度にも JavaScript の実行速度にも日進月歩を感じる今日この頃です。

さて、アプリケーションを作っていると、見た目はリンクのようだがリンクでない UI 部品を使いたくなるときがあります。ここで「リンクでない」とは、クリックしてもページ遷移が発生しないということです。このような UI 部品は、ページ遷移の代わりにメニューの表示といった何らかのアクションを引き起こす、すなわちボタンとして振舞います。

ユーザーインターフェース記述言語として HTML を使っているとき、この「リンクのようなボタン」をどのように実現すればいいのでしょうか。

input、button 要素

ボタンとして振舞うものはボタンとして記述すべきです。HTML では汎用的なボタンとして <input type="button"> 及び <button type="button"> が用意されています。スタイルシートを使えば見た目をリンクのようにもできるでしょうし、画像を使いたければ <input type="image"> もあります。

<input type="button" value="リンクのようなボタン" onclick="...">
<button type="button" onclick="...">リンクのようなボタン</button>

しかし、フォームコントロールに対してはスタイルシートが期待通り適用されないこともあり、ボタンをどうしてもインライン要素にしたいときにこの方法は取れません。

a 要素

リンクのように見えるならリンクにすればいいということで a 要素が使われることもあります。click イベントを処理するときにデフォルトアクションをキャンセルすれば、もともと指定してあったリンク先に飛ぶことはありません。あるいはリンク先に javascript:void(0); と指定することでページ遷移が発生しないようにします。

<a href="#" onclick="...; return false;">リンクのようなボタン</a>

しかし、a 要素はあくまでハイパーリンク、すなわち他のリソースへ移動するためのものです。外見がどうあろうとリンクでないものの記述に使うの好ましくありません。

span 要素

click イベントに対する処理はどんな要素にも付加できるので、a 要素にこだわる必要はありません。「リンクのような」の部分はスタイルシートで実現できます。

<style>
.trigger {
  color: #00f;
  text-decoration: underline;
  cursor: pointer;
}
</style>

<span class="trigger" onclick="...">リンクのようなボタン</span>

しかし、これではキーボードを用いてボタンにアクセスすることができません。多くのブラウザでは Tab キーでリンクやフォームコントロールへ移動できますが、span 要素はその対象から外れています。

span 要素 + tabindex 属性

tabindex 属性はフォーカス順を変更するものだと思っていたあなた、それはこの属性が持つパワーのほんの一部でしかありません。HTML5 において tabindex 属性は要素をフォーカス可能にする属性として生まれ変わったのです。この属性はどんな要素にもつけられ、値に 0 を指定すればその要素がキーボードアクセス可能になります。

<span class="trigger" tabindex="0" onclick="...">
  リンクのようなボタン
</span>

しかし、Tab キーでこのボタンにフォーカスし、Enter キーを押しても何もおきません。a要素によるリンクなら Enter キーを押すと click イベントが発生するのにも関わらずです。なお、Opera なら span 要素でも Enter キーにより click イベントが発生し、指定したアクションが実行されます。

span 要素 + tabindex 属性 + onkeypress 属性

click イベントが発生しないなら自分で click イベントに対する処理を呼び出せばいいのです。onclick 属性に指定したコードは onclick プロパティから関数として取得できます。Enter キーを表すキーコードは 13 なので、そのときのみ処理を実行します。

<span class="trigger" tabindex="0" onclick="..."
      onkeypress="if (event.keyCode === 13) this.onclick(event);">
  リンクのようなボタン
</span>

しかし、click イベントに対する処理が onclick 属性に書かれているとは限りません。addEventListener や attachEvent メソッドでイベントリスナが追加されていることもあれば、祖先要素、文書ノードで click イベントが処理されていることもあります。また、Opera ではこの場合 Enter キーを押すと onclick 属性の内容が2回実行されてしまいます。

span 要素 + tabindex 属性 + キーイベント処理

click イベントに対する処理を直接実行できなくとも、click イベントを発生させれば自然とそれらが実行されます。イベントを発生させるのに、DOM イベントモデルでは dispatchEvent、IE のイベントモデルでは fireEvent メソッドを用います。Opera 対策に keypress イベントのデフォルトアクションをキャンセルしておきましょう。

<script>
function activate(event) {
    event = event || window.event;
    if (event.keyCode !== 13) return;
    if (document.createEvent) {
        var e = document.createEvent('MouseEvent');
        e.initMouseEvent(
            'click', true, true, event.view, 1,
            event.screenX, event.screenY, event.clientX, event.clientY,
            event.ctrlKey, event.altKey, event.shiftKey, event.metaKey, 0, null
        );
        event.target.dispatchEvent(e);
        event.preventDefault();
    } else if (document.createEventObject) {
        var e = document.createEventObject(event);
        event.srcElement.fireEvent('onclick', e);
        event.returnValue = false;
    }
}
</script>

<span class="trigger" tabindex="0"
      onclick="..." onkeypress="activate(event);">
  リンクのようなボタン
</span>

しかし、視覚的なブラウザであれば見た目からこの要素が何らかのアクションを引き起こすことがわかりますが、環境によってもそもそもこれが「押せる」ということすら伝わらないかもしれません。

span 要素 + tabindex 属性 + キーイベント処理 + role 属性

視覚によらず、機械的に UI 部品を認識するための仕様として WAI-ARIA があります。要素がボタンの「役割」を果たすことを表すには、role 属性の値に "button" を指定します。これで人の目からだけでなく、機械から見たときもボタンとして認識・操作できるようになりました。

<span class="trigger" role="button" tabindex="0"
      onclick="..." onkeypress="activate(event);">
  リンクのようなボタン
</span>

サンプル

リンクのようなボタンのサンプルで実際の挙動を確認できます。

終わりに

以上はあくまで JavaScript の使える環境が前提です。スクリプトが動かなくとも最低限の機能は利用できるよう気をつけましょう。スクリプトが動く場合でも、本当にリンクのようなボタンでなければいけないのか、通常のボタン、またはハイパーリンクでは実現できないのかよく検討した上で使うようにしてください。

参考資料

Kanasan.JS JavaScript 第 5 版読書会 #10 XPath 発表資料

Mon, 27 Sep 2010 08:58:53 +0900

6 月のことになりますが、Kanasan.JS JavaScript 第 5 版読書会 #10 にて XPath に関する発表を行いました。内容は基本的な XPath の解説です。

本番では図の準備が間に合わずホワイトボードに描きながら発表したのですが、逐次挙がる質問に対してもすぐ描き直して対応できたので、かえって理解を深めるのに役立ったのではないかと思います。資料中の注釈は口頭で説明したことなどを書き起こしたものです。

タイトルに excellent と入っていますが何か特に素晴しいということはなく、単に頭韻を踏みたかっただけです。(しかし excellent と expression では ex の発音が違うので踏めてないという……)

日記始めました

Thu, 01 Apr 2010 09:39:46 +0900

このブログを始めた当初は趣味やら愚痴やら何でも書くつもりだったのですが、技術系のネタが多勢を占めるにつれ、それ以外のことが書きづらくなってきました。そうした、Web なりプログラミングなりと関係ないことについて、これからは別に日記を設け、そこに書きとめておくことにします。

そのための場所としてはてなを考えていたのですが、悲しむべきことに、いつの間にか日記ではなくブログサービスになっていました。しかし、はてなダイアリーを使わなければいけない理由もできてしまったので、そのあたりには目をつむることにします。

というわけで、今後非技術系の話は日記 Ways on the Moon でやっていきます。JavaScript や Mozilla に関しては引き続きここ、Days on the Moon に書くつもりなので、よろしくお願いいたします。

Mozilla 勉強会 @ 大阪

Wed, 03 Mar 2010 04:53:22 +0900

2 月 20 日に行われた Mozilla 勉強会 @ 大阪に行ってきました。「js-ctypes で音声読み上げ」という題でライトニングトークをしたので、そのスライドとサンプルコードを公開します。

js-ctypes で音声読み上げ
read-selection.uc.js (userChrome.js 用スクリプト)

js-ctypes は C/C++ 用のライブラリ関数を JavaScript から呼び出すための機能で、Firefox の次期バージョンに搭載される予定です。ここでは「AquesTalkとkakasiを組み合わせて再生。 - 世界はアルゴリズムでできている。」を参考に音声読み上げライブラリを呼び出してみました。

上記コードでは標準 C ライブラリ関数を使って無理やりポインタを扱っていますが、Overview of js-ctypes や MozillaWiki の js-ctypes のページを見るに、将来的には標準でポインタや構造体、コールバック関数を使えるようにするみたいです。

IME の実装の概要について (中野雅之さん)

現在 Mozilla で IME 周りのコードを書いているのは中野さんだけだそうです (レビュワは Windows と Linux に一人ずつ)。「TSF を使う (1) - Windows Input Method の歴史 - NyaRuRuの日記」によると Mozilla は IME 関係の描画を自前で行っているそうで、それを一人でやり続けているというのには頭が下がります。

研究プラットフォームとしての Firefox の可能性 (山本岳洋さん)

研究の一環として Rerank.jp を作っている方です。当初は C# でアプリケーションを作成していたが、いちいち起動するのが面倒で自分でさえも使わなくなってしまったとのこと。そういう点では、常に起動しているアプリケーション実行環境で、おまけにクロスプラットフォームというのはとっつきやすいのかもしれませんね。

ちなみに私が知る限りでは、ほかにも次のような研究が Firefox (Mozilla) を使っています。

Jetpack Reboot (あかつかだいすけさん)

今 Jetpack は基礎から作り直している最中だそうです。Jetpack のランタイムを各フィーチャーが含んで、個別の「拡張機能」として扱えるようになり、またそれに伴い addons.mozilla.org (AMO) での公開手順も整備中とのこと。ある程度広まって問題点も明らかになり、それでいて 1.0 も出ていないこの時期は、まさに「再起動」にぴったりだと思います。

modest と研究と勉強会

Mozilla/Firefox の開発情報を集約する場として、Mozilla Developer Street (modest) を積極的に使ってほしいという話がありました。Firefox を研究に使うのと同時に、modest を大学で使っていくのもありだそうです。

また、このような勉強会を今後も定期的に開いていくそうですが、大学での開催も可能とのことです。Firefox を研究に使いたいけれど開発方法がわからないという方は、modest で声を上げてみてはいかがでしょうか。

勝手に添削: Selection内のHTML Textをいい感じに取得する

Fri, 05 Feb 2010 09:15:00 +0900

というわけでやってまいりましたこのコーナー! 本日のお題は「Selection内のHTML Textをいい感じに取得する - 枕を欹てて聴く」でございます。選択範囲のHTMLソースを抜き出すというやつですね。では早速いってみましょう!

  if(src.focusNode){
    // selection

まずは HTML5 テキスト選択 API の Selection オブジェクトが登場! 以後これに対する操作が続きます。しかしこの Slection オブジェクト、getRangeAt メソッドを使うとなんと選択範囲に対応する DOM 2 Traversal and Range の Range オブジェクトが取れちゃうんです!

    // common parent node search
    (以下 21 行省略)

それ Range#commonAncestorContainer で取れるよ!

      // common配下のindexを見て, focus と anchorがどちらが前方かを調べる
      (以下 9 行省略)

それ Range#startContainer と Range#endContainer でわかるよ!

      // focusに沿って後方をremove
      (以下15行省略)
      // anchorに沿って前方をremove
      (以下11行省略)

それ Range#extractContents() か Range#cloneContents() でできるよ!

というわけで不要な要素を除去する部分は置いといて今までの経過をまとめてみると、

function convertToHTMLString(source, safe) {
  if (!source || (source.getRangeAt && source.isCollapsed)) return '';
  var range = source.getRangeAt ? source.getRangeAt(0) : null;
  var node = range ? range.cloneContents() : source.cloneNode(true);
  if (safe) { ... }
  return new XMLSerializer().serializeToString(node);
}

なんということでしょう! コメント空行抜きでも 86 行あった部分が実質たったの 2 行に!

これに残った部分を付け足していくわけですが、出来上がった品はこちらになります。(お試しはこちら!)

まとめ

Range かわいいよ Range。
選択範囲からリンクを抜き出すこともできちゃうし。
でも Opera 10 で文書木に属してないノードの Range を作ろうとするとエラーになっちゃう……、ぐすん。(10.50 は試してない。)
~~それ IE なら 1 行ででき~~

以上、もろもろの要因で~~無駄に~~ハイテンションの nanto_vi (なんと) がお届けしました!

Firefox 3.6 での XPath による要素取得

Sun, 24 Jan 2010 22:44:59 +0900

Firefox 3.6 にしたら、動的に生成した文書からの XPath による要素取得ができなくなったという報告が挙がっています。

この原因は、Firefox 3.6 で HTML 要素の名前空間の扱いが変わったことにあります。Firefox 3.6 (Gecko 1.9.2) では、HTML5 に従い、HTML 要素が (XML 文書中でなくても) XHTML の名前空間 (HTML5 でいうところの「HTML の名前空間」) http://www.w3.org/1999/xhtml に属するようになりました。

これに伴って、これまでは XML 文書中でも有効だった、XPath 式の評価における HTML 要素の特別扱い (要素名の大文字小文字を区別しない、非修飾名を HTML の名前空間に属するものとみなす) が、HTML 文書中でのみ有効となったようです。なお、この特別扱いは、XPath 1.0 に違反しますが、HTML5 で認められています。

document.implementation.createDocument(null, 'html', null) で作成されるのは XML 文書なので、接頭辞なしの XPath 式では HTML 要素を取得できなくなってしまいました。このことは、「HTMLDocument の動的な生成」でも、(こちらは Firefox 3.7a ですが) createDocument メソッドでの名前空間なし XPath の結果が×になっていることで確認可能です。

解決策としては、HTML 文書を作成するようにすればいい話です。これには XSLT の HTML 出力を使ってもいいのですが、なぜか今現在の Firefox nightly (3.7a1pre 20100123) ではこの方法がうまくいかないので、createDocument メソッドに文書型宣言と名前空間を指定するほうをおすすめします。

ちなみに AutoPagerize では document.cloneNode メソッドを使っていますが、これは読み込む文書が基本的に同じ Web サイト内のものであり、現在の文書が HTML 文書なら次も HTML 文書、XML 文書なら次も XML 文書と推定できるからです。XML 文書から HTML 文書を読み込む場合など、汎用性を考えるならやはり createDocument メソッドを使ったほうがいいでしょう。

Kanasan.JS Jetpack ワークショップ

Wed, 30 Dec 2009 18:08:47 +0900

Kanasan.JS Jetpack ワークショップに行ってきました。Jetpack は Firefox 用の簡易拡張プラットフォーム。私としては通常の拡張機能のほうが高い自由度を持てて好きなのですが、Firefox を広く一般に使ってもらうには、簡単なものを簡単に作れるようにするという点が重要なのでしょう。

最初に mollifier さんによる Jetpack 入門があった後、二人組になり各グループで Jetpack フィーチャーを作っていくという流れ。私は satyr さんとペアになったのですが、さすが satyr さん、ゴルファーだけあって見慣れぬ記法を次々と使ってきます。

var { href } = location;

上のコードは分割代入の省略形式で、

var { href: href } = location;

の略、さらには、

var href = location.href;

の略なのですが、JavaScript 1.8 以降 (Firefox 3 以降) での機能とあって、私自身も久しく頭から抜けていました。

そんなこんなで完成した (といっても実際のコーディングはほとんど satyr さんでしたが) のが、現在閲覧中のページの W3C Markup Validation Service での検証結果をステータスバーに表示する Jetpack フィーチャー、HTMLValidator for Jetpack です。

ちなみに開発中に引っかかったのが、特定の名前空間に属する要素の jQuery での扱い。http://validator.w3.org/check?uri=http%3A%2F%2Fnanto.asablo.jp%2Fblog%2F&output=soap12 のように output パラメータに値 soap12 を指定すると、検証結果が、

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<m:markupvalidationresponse env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://www.w3.org/2005/10/markup-validator">
    <m:uri>http://nanto.asablo.jp/blog/</m:uri>
    <m:checkedby>http://validator.w3.org/</m:checkedby>
    <m:doctype>-//W3C//DTD HTML 4.01 Transitional//EN</m:doctype>
    <m:charset>utf-8</m:charset>
    <m:validity>true</m:validity>
    ...
</m:markupvalidationresponse>
</env:Body>
</env:Envelope>

と XML 形式で返ってくるのですが、ここから jQuery で validity 要素を選択するには、res を返ってきた XML 文書ノードオブジェクトとして、

$(res).find("m\\:validity")

のように指定する必要があるのでした。

そもそも DOM の getElementsByTagName メソッドからして、引数に指定できるのは要素名 (非修飾名) のみと勘違いしていたのですが、実際は、名前空間に属する要素を選択するためには接頭辞も含めた修飾名を指定する必要があるとのこと。名前空間の指定に、語彙に対して常に一意な名前空間 URI ではなく、文書片ごとに変わる可能性のある名前空間接頭辞を用いるのは、大変気持ち悪いです。

Days on the Moon

jQuery のバグを見つけてから修正されるまで

jQuery で HTTP 接続するときの書き方

はてなでコードを書くときに気をつけていること

できれば明示的に

入力には正規化を、出力には符号化を

IE 6/7 で文書間通信を実現するための一案

Template::Plugin::JSON::Escape 公開

関連する話題

Perl の URI モジュールにおける文字列とオクテット列の扱いに関して

用語の定義

発端となった問題

Perl において URI はどう扱われるべきか

URI.pm をどう修正すべきか

国際化ドメイン名の扱い

URI.pm の互換性の確保

修正の段取り

chrome URL からファイル一覧を取得する

Firefox Developers Conference 2010

Beyond Firefox 4 (Jay Sullivan)

John Resig feat. Shibuya.js

トークセッション: HTML5 時代の技術で Web プラットフォームはどう変わるのか (矢倉眞隆、村岡正和、浅井智也)

大ライトニングトーク

懇親会

リンクのようなボタンを作る

input、button 要素

a 要素

span 要素

span 要素 + tabindex 属性

span 要素 + tabindex 属性 + onkeypress 属性

span 要素 + tabindex 属性 + キーイベント処理

span 要素 + tabindex 属性 + キーイベント処理 + role 属性

サンプル

終わりに

参考資料

Kanasan.JS JavaScript 第 5 版読書会 #10 XPath 発表資料

日記始めました

Mozilla 勉強会 @ 大阪

IME の実装の概要について (中野雅之さん)

研究プラットフォームとしての Firefox の可能性 (山本岳洋さん)

Jetpack Reboot (あかつかだいすけさん)

modest と研究と勉強会

勝手に添削: Selection内のHTML Textをいい感じに取得する

まとめ

Firefox 3.6 での XPath による要素取得

Kanasan.JS Jetpack ワークショップ