Days on the Moon

勝手に添削: 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 ではなく、文書片ごとに変わる可能性のある名前空間接頭辞を用いるのは、大変気持ち悪いです。

初めての JavaScript 第 2 版

Wed, 30 Dec 2009 17:07:24 +0900

O'Reilly Japan から書籍『初めての JavaScript 第 2 版』(Shelley Powers 著、武舎広幸・武舎るみ訳) (Amazon) が出版されています。出版にあたって、私が技術レビューを務めさせていただきました。販促効果があるのかわかりませんが、帯に推薦文も寄せています。

単なる JavaScript の書き方にとどまらず、デバッガの使い方など基礎になる事柄を幅広く取り扱っていますので、JavaScript を始めたいという方は一度手にとってみることをお勧めします。また、周囲にそのような方がいる場合もぜひ勧めてあげてください。

読み終えた方は、『JavaScript 第 5 版』(Amazon) や『JavaScript: The Good Parts』(Amazon) に進むのもいいですし、Prototype.js などのコードリーディングをしてみるのもいいと思います。なお、ここで Prototype.js の名前を挙げたのは、次の二つの理由によります。

ソースコードが比較的読みやすい。
既にコードリーディングを行った人が大勢いて、Web 上に多数のコード解説がある。

第 2 回 WCAG 勉強会 @ 関西

Wed, 30 Dec 2009 16:23:36 +0900

先日開かれた WCAG 勉強会 @ 関西 (Twitter) の第 2 回勉強会に参加しました。

WCAG 2.0 とは

Web アクセシビリティに関する指針です。W3C が発効しており、本文といくつかの関連文書からなります。これを基に JIS X 8341-3 (Web コンテンツ JIS) が改定される予定です。

Web Content Accessibility Guidelines (WCAG) 2.0 (日本語訳): ここでは「本文」と呼びます。4 つの原則と 12 の指針からなりますが、要点だけ書かれているのでやや読みづらいです。
Understanding WCAG 2.0 (日本語訳): 本文の各指針に対して、そのような指針を設けた意図や、補足の説明、個々の事例などが書かれています。「解説書」と呼ばれますが、こっちこそ本文という感じです。
Techniques for WCAG 2.0: HTML や JavaScript といった既存の技術を、どう使えば各指針に対応できるのか、また逆にどう使うと指針に対応していないとみなされてしまうのか、が記述されています。「技術書」と呼ばれます。
How to Meet WCAG 2.0: 「クイックリファレンス」とも呼ばれます。使用する技術や達成水準を指定することで、各指針に対応する本文、解説書、技術書の項目を探し出せます。

本文は時代の変化にも対応できるように書かれていますが、解説書や技術書は一般的な環境の移り変わりにつれて随時更新されるかもしれないそうです。

勉強会の流れ

今回の範囲は「原則 1: 知覚可能」の「ガイドライン 1.1: 代替テキスト」までで、事前に本文と解説書の該当箇所を読んでおくこととなっていました。当日は、各自が範囲内の事項に関する疑問点を、付箋紙に書き出してホワイトボードに貼り付け、それらをひとつずつ、あるいはいくつかまとめて全員で議論するという形でした。

Kanasan.JS でもそうですが、全員でひとつのことについて議論するというのは、一度にさまざまな視点が得られて面白いです。

メディアと代替テキスト

ガイドライン 1.1 代替テキスト：すべての非テキストコンテンツには代替テキストを提供して、拡大印刷、点字、音声、シンボル、平易な言葉などのような、ユーザが必要とする形式に変換できるようにする。

ここでいう「代替テキスト」とは、あるメディア (媒体) から別のメディアに変換するための、中間メディアのことです。画像から点字へ、音声から字幕へ、直に変換できれば苦労はないのですが、現状ではそれが困難なため、テキストというメディアを用意することで変換にかかる負担を軽減しようというのです。

この変換は、必ずしも自動で行われるわけではありません。一定の精度を確保するためには人力での変換が必要、ということもまだまだ多いようです。

シンボルメディア

メディアの例として「シンボル」とありますが、これはアイコンやピクトグラムの組み合わせなどで文意を表すことを指すようです。実際にアイコンを並べてニュースを伝えるニュースサイト (サンプルページ、PDF) もあるほか、漫画の新聞も一種のシンボル化ではないかと思います。

感覚的なコンテンツ

WCAG 2.0 では、特定の場合には中間メディアたる代替テキストを提供しなくてもいいとされています。そのひとつが感覚的なコンテンツで、たとえばコンサートの動画があったとき、最低限「そこに動画がある」「それはコンサートの動画である」といったことが識別できる代替テキストがあればよく、「そのコンサートを聞いてどう感じたか」などの主観的な情報は必ずしも含む必要はありません。

類似文字の使用に関する注意

技術書で失敗例として挙げられているのが、代替テキスト無しでの類似文字の使用です。これは、ある文字の代わりに見た目のよく似た文字を使うことで、ひらがなの「し」の代わりにギリシャ文字の小文字イオタ (ι) を使う、漢字「神」の代わりにカタカナと漢字を並べて「ネ申」と書く、といった例があります。このことは、文字を直接ソーステキストに埋め込んだ場合だけでなく、HTML の文字参照や JavaScript のエスケープシーケンスなどで間接的に埋め込んだ場合にも当てはまります。

ただし、何が何でもダメというわけではなく、適切な代替テキストが指定されていればいいようです。技術書には、代替テキストの指定方法として、abbr 要素とその title 属性を使った例が載っています。

<abbr title="化物語">イヒ牛勿言吾</abbr>

アクセシビリティ・サポーテッド

WCAG 2.0 での重要な概念が「アクセシビリティ・サポーテッド」(本文、解説書) です。これは、コンテンツが実在の支援技術 (拡大鏡、スクリーンリーダ、代替ポインティングデバイスなど) で利用可能でなければいけないということで、技術書の中にも特定のブラウザや支援技術に関する注意書きが見られます。

点字ディスプレイ

持ち運びできる円盤式点字ディスプレイがヒットしているそうです。あらかじめテキストを記憶しておいて電車の中で読むといったことが可能で、音声よりも速く読めるとか。

音訳マニュアル

代替テキストを点字や音声に変換する際の指針として、音訳マニュアルが役に立つそうです。点字では、単に読みをそのまま抜き出せばいいというわけではなく、「橋」「箸」「端」はそれぞれ区別がつくよう説明を加えるなど、さまざまなノウハウが必要とされるようでした。

ナビゲーションスキップ

サイトのヘッダやサイト全体にまたがるナビゲーションなど、ページの本文とは関係ない部分を読み飛ばせるような仕組みをブロックスキップといいます。ブロックスキップの実現手法の一つとして、ページの先頭に本文へのリンク (視覚メディアではしばしば非表示にされる) を付けるナビゲーションスキップ (スキップリンク) があります。

しかし、少なくとも勉強会参加者の周辺では、ナビゲーションスキップを使っている人はいないようでした。ナビゲーションスキップはサイトごとに異なるので使いづらい、Yahoo! や Google などよく見るページでは本文より前のリンクを飛ばす操作に慣れている、適切な見出しと支援技術の見出しジャンプ機構があれば十分、といった背景があるそうです。

雑感

実際に業務として Web アクセシビリティに携わっている方々の話を聞け、大変参考になりました。知らないこと、わかっていなかったことがほとんどで、まさしく聞くと見るとは大違いです。Web 製作に関わる方々はこの勉強会に参加して損はないと思います。

Web アクセシビリティと聞くと、ぽっと出の新しくてよくわからないものと思う方もいるかもしれませんが、障害者が情報に触れる手段に関しては古くからさまざまな試みがなされてきたこと、そしてそれらの積み重ねが Web にも応用できるという点は非常に重要なことだと思います。アクセシビリティを何か特別なものとみなすのではなく、ノウハウの蓄積された、すぐそこにある日常として受け入れることが大切です。

Firefox Developers Conference 2009

Thu, 12 Nov 2009 02:26:55 +0900

11 月 8 日に行われた Firefox Developers Conference 2009 にて、secondlife さんとともにはてなブックマーク Firefox 拡張に関する発表を行いました。発表資料は次の通りです。

Firefox Developers Conference 2009 発表資料 - 川o・-・）＜2nd life (secondlife さん発表分)
はてなブックマーク Firefox 拡張実装の舞台裏

資料中に約 3500 行の XML とありますが、この中には XBL 内に直接書かれた JavaScript コードの行数も含まれていると思います。XBL は、特定の機能を持つ要素が複数存在する場合に威力を発揮します。Mozilla のウィジェット (ボタンやメニューなど) のソースを読むためには XBL のあらましを知っておく必要があると思うのですが、意外と認知度は低いようでした。

他の発表では、「ビッツにおける拡張機能開発」のユーザーの反応やサポートに関する話題が興味深かったです。ソフトウェアを広く使ってもらうには、ユーザーの反応に対し、肯定的であれ否定的であれ、すばやく対応することが重要なんだと実感しました。(たとえば Piro さんは、ユーザーの要望に従わないことを、理由を挙げて丁寧に説明しています。)

また、Aza さん、amachang さん、Piro さんによるトークセッションでは、「グローバルにするためにはローカライズしなければならない」という Aza さんの言葉が心に残りました。以前、奥 (kazuho) さんからも同じ言葉を聞いたことがあり、世界に通用するソフトウェアを作る人間の意識を垣間見た気がします。

懇親会で Aza さんに、Jetpack の HTML を使った UI が、外観やアクセシビリティ API を通したアクセスの点で、OSネイティブのウィジェットや XUL を使った UI と異なってくることについてお聞きしたかったのですが、私自身質問の要旨をまとめきれず、ちぐはぐな応答になってしまいました。ただ、WAI-ARIA の話を出されていたので、そうした仕組みを通じて (あるいはそれを背後で行ってくれるライブラリを使って) OS からのアクセスも確保していこうということだと思います。

懇親会は料理のほうも素晴しく、私はもっぱらアボカドとえびのサラダと、Firefox 5 周年ケーキの切れ端をぱくついていました。はてなステッカー (前日人に尋ねられるまで配布されることを知らなかったのですが) が予想外の人気で、私もじゃんけん大会に参加したものの、あえなく 1 回戦敗退です。

普段 Web 上でお世話になっている方々や、Mozilla を陰日向から支えてきた方々と直接お会いすることができ、非常に楽しくまた有意義なイベントでした。拡張開発の機会を与えてくださったはてなの皆さん、発表の場を用意してくださった Mozilla Japan の皆さん、発表にお越しいただいた皆さん、そして Mozilla と Firefox に対して多大な貢献をされてきた皆さんに深く感謝します。

HTMLDocument の動的な作成

Thu, 29 Oct 2009 06:11:27 +0900

ブラウザ上で、JavaScript を使って HTML のソースから HTML 文書を生成するのに、どんな方法があるのか調べました。なお、以下のスクリプトは HTML 文書上で実行することが前提です。

表の見方
XSLT の HTML 出力
createHTMLDocument メソッド
createDocument メソッド
createDocument メソッドと名前空間の指定
createDocument メソッドと文書型宣言の指定
createDocument メソッドと文書型宣言及び名前空間の指定
cloneNode メソッド
iframe 要素
ActiveXObject
CID からの作成
まとめ

表の見方

以下の表において、各項目の意味は次の通りです。

doc: HTML 文書を作成できれば○、XML 文書を作成できれば△、それ以外なら×です。HTML 文書かどうかは、createElement メソッドが HTML 要素を作成するかどうかで判断しています。
doc.title: 文書ノードの title プロパティから title 要素の内容を取得できれば○、できなければ×です。
doc.body: 文書ノードの body プロパティから body 要素を取得できれば○、できなければ×です。
名前空間なし XPath: //p のような名前空間接頭辞の付かない XPath 式で HTML 要素を取得できれば○、できなければ×です。
名前空間付き XPath: //h:p のような名前空間接頭辞の付いた XPath 式で HTML 要素を取得できれば○、できなければ×です。ここで、接頭辞 h は名前空間 URI http://www.w3.org/1999/xhtml に関連付けられているものとします。
innerHTML: innerHTML プロパティに <p>hello world のような、整形式 XML ではなく、かつ HTML の実体参照を含んだ文字列を設定して、エラーが出なければ○、エラーになれば×です。
スクリプト: script 要素で指定されたスクリプトが実行されれば○、されなければ×です。

また、使用したブラウザは次の通りです。いずれも Windows 版です。

Firefox 3.0.11
Firefox 3.5.3
Minefield (Firefox の開発版) 3.7a1pre、HTML5 パーサ無効
Minefield 3.7a1pre、HTML5 パーサ有効 (html5.enable を true に設定)
Opera 9.64
Opera 10.00
Safari 3.2.3
Safari 4.0.3
Internet Explorer 6 SP3
Internet Explorer 7
Internet Explorer 8

調査には次のファイルを使いました。

XSLT の HTML 出力

function createHTMLDocument_XSLT(source) {
  var processor = new XSLTProcessor();
  var sheet = new DOMParser().parseFromString(
    '<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">' +
      '<xsl:output method="html"/>' +
      '<xsl:template match="/">' +
        '<html><head><title></title></head><body></body></html>' +
      '</xsl:template>' +
    '</xsl:stylesheet>',
    'application/xml'
  );
  processor.importStylesheet(sheet);
  var doc = processor.transformToDocument(sheet);
  var range = doc.createRange();
  range.selectNodeContents(doc.documentElement);
  range.deleteContents();
  doc.documentElement.appendChild(range.createContextualFragment(source));
  return doc;
}

	3	3.5	3.7a	3.7a HTML5	3.2	4	9.6	10
	Firefox				Safari		Opera
`doc`	○	○	○	○	○	○	○	○
`doc.title`	×	○	○	○	×	×	×	○
`doc.body`	×	×	×	○	×	×	○	○
名前空間なし XPath	○	○	○	○	○	○	○	○
名前空間付き XPath	×	×	○	○	○	○	×	×
`innerHTML`	○	○	○	○	○	○	○	○
スクリプト	×	×	×	×	×	×	×	×

比較的以前から使われている方法です。XSLT を使ってある文書を HTML 文書に変換し、後は innerHTML なり Range#createContextualFragment なりでソースを流し込みます。Firefox 2 (Gecko 1.8.1) 以前では、フラグメント識別子付きの URL 上でエラーが出るそうです。

XSLTProcessor、DOMParser、Range#createContextualFragment は Mozilla による独自拡張ですが、Safari (WebKit) と Opera もサポートしています。ブラウザによっては createContextualFragment を使ったパースで、head 要素や body 要素が消えてしまうことがあります。

`createHTMLDocument` メソッド

function createHTMLDocument_createHTMLDocument(source) {
  var doc = document.implementation.createHTMLDocument('');
  var range = doc.createRange();
  range.selectNodeContents(doc.documentElement);
  range.deleteContents();
  doc.documentElement.appendChild(range.createContextualFragment(source));
  return doc;
}

	3	3.5	3.7a	3.7a HTML5	3.2	4	9.6	10
	Firefox				Safari		Opera
`doc`	×	×	×	×	○	○	○	○
`doc.title`	―	―	―	―	×	×	×	○
`doc.body`	―	―	―	―	×	×	○	○
名前空間なし XPath	―	―	―	―	○	○	○	○
名前空間付き XPath	―	―	―	―	○	○	×	×
`innerHTML`	―	―	―	―	○	○	○	○
スクリプト	―	―	―	―	×	×	×	×

Safari と Opera は、HTML 文書を直接生成するその名も createHTMLDocument メソッドを実装しています。このメソッドは、DOM 2 HTML 2002 年 6 月 5 日付勧告候補までは存在したのですが、以降は削除され勧告には含まれていません。しかし、HTML5 草案で復活したので、将来的には他のブラウザでも実装されるかもしれません。

`createDocument` メソッド

function createHTMLDocument_createDocument(source) {
  var doc = document.implementation.createDocument(null, 'html', null);
  var range = document.createRange();
  range.selectNodeContents(document.documentElement);
  var content = doc.adoptNode(range.createContextualFragment(source));
  doc.documentElement.appendChild(content);
  return doc;
}

	3	3.5	3.7a	3.7a HTML5	3.2	4	9.6	10
	Firefox				Safari		Opera
`doc`	△	△	△	△	△	△	△	△
`doc.title`	×	○	○	○	×	×	×	×
`doc.body`	×	×	×	×	×	×	×	×
名前空間なし XPath	○	○	×	×	×	×	○	○
名前空間付き XPath	×	×	○	○	○	○	×	×
`innerHTML`	×	×	×	×	×	×	○	○
スクリプト	×	×	×	×	×	×	×	×

XML 文書を生成するための createDocument メソッドを使います。これにより生成される文書はあくまでも XML 文書なので、HTML ソースのパースには呼び出し元の HTML 文書を使っています。異なる文書で生成されたノードを文書ツリーに追加するため adoptNode を使っていますが、Firefox 2 以下では対応していないので代わりに importNode を使う必要があります。

`createDocument` メソッドと名前空間の指定

function createHTMLDocument_createDocument_NS(source) {
  var XHTML_NS = 'http://www.w3.org/1999/xhtml';
  var doc = document.implementation.createDocument(XHTML_NS, 'html', null);
  var range = document.createRange();
  range.selectNodeContents(document.documentElement);
  var content = doc.adoptNode(range.createContextualFragment(source));
  doc.documentElement.appendChild(content);
  return doc;
}

	3	3.5	3.7a	3.7a HTML5	3.2	4	9.6	10
	Firefox				Safari		Opera
`doc`	△	△	△	△	○	○	○	○
`doc.title`	×	○	○	○	×	×	×	○
`doc.body`	×	×	×	×	×	×	○	○
名前空間なし XPath	○	○	×	×	×	×	○	○
名前空間付き XPath	×	×	○	○	○	○	×	×
`innerHTML`	×	×	×	×	×	×	○	○
スクリプト	×	×	×	×	×	×	×	×

Safari と Opera では、createDocument で文書要素 (ルート要素) に XHTML の名前空間を指定すると、XHTML 文書が生成されます。このとき、Safari では innerHTML に整形式 XML の断片しか設定できません。

`createDocument` メソッドと文書型宣言の指定

function createHTMLDocument_createDocument_DTD(source) {
  var doctype = document.implementation.createDocumentType('html',
    '-//W3C//DTD HTML 4.01//EN', 'http://www.w3.org/TR/html4/strict.dtd');
  var doc = document.implementation.createDocument(null, 'html', doctype);
  var range = document.createRange();
  range.selectNodeContents(document.documentElement);
  var content = doc.adoptNode(range.createContextualFragment(source));
  doc.documentElement.appendChild(content);
  return doc;
}

	3	3.5	3.7a	3.7a HTML5	3.2	4	9.6	10
	Firefox				Safari		Opera
`doc`	△	○	○	○	△	△	△	△
`doc.title`	×	○	○	○	×	×	×	×
`doc.body`	×	×	×	×	×	×	×	×
名前空間なし XPath	○	○	○	○	×	×	○	○
名前空間付き XPath	×	×	○	○	○	○	×	×
`innerHTML`	×	○	○	○	×	×	○	○
スクリプト	×	×	×	×	×	×	×	×

DOM 3 Core では、createDocument で文書型宣言を指定すると、その文書型宣言に見合った文書を作成してもよい (may) ことになっています。Firefox 3.5 (Gecko 1.9.1) 以降ではこれに従って、HTML 4 の文書型宣言に対しては HTML 文書が、XHTML 1.0 の文書型宣言に対しては XHTML 文書が生成されます。

`createDocument` メソッドと文書型宣言及び名前空間の指定

function createHTMLDocument_createDocument_DTD_NS(source) {
  var XHTML_NS = 'http://www.w3.org/1999/xhtml';
  var doctype = document.implementation.createDocumentType('html',
    '-//W3C//DTD HTML 4.01//EN', 'http://www.w3.org/TR/html4/strict.dtd');
  var doc = document.implementation.createDocument(XHTML_NS, 'html', doctype);
  var range = document.createRange();
  range.selectNodeContents(document.documentElement);
  var content = doc.adoptNode(range.createContextualFragment(source));
  doc.documentElement.appendChild(content);
  return doc;
}

	3	3.5	3.7a	3.7a HTML5	3.2	4	9.6	10
	Firefox				Safari		Opera
`doc`	△	○	○	○	○	○	○	○
`doc.title`	×	○	○	○	×	×	×	○
`doc.body`	×	×	×	○	×	×	○	○
名前空間なし XPath	○	○	○	○	×	×	○	○
名前空間付き XPath	×	×	○	○	○	○	×	×
`innerHTML`	×	○	○	○	×	×	○	○
スクリプト	×	×	×	×	×	×	×	×

HTML 4 の文書型宣言と XHTML の名前空間を両方指定した場合です。

`cloneNode` メソッド

function createHTMLDocument_cloneNode(source) {
  var doc = document.cloneNode(false);
  doc.appendChild(doc.importNode(document.documentElement, false));
  var range = document.createRange();
  range.selectNodeContents(document.documentElement);
  var content = doc.adoptNode(range.createContextualFragment(source));
  doc.documentElement.appendChild(content);
  return doc;
}

	3	3.5	3.7a	3.7a HTML5	3.2	4	9.6	10
	Firefox				Safari		Opera
`doc`	×	○	○	○	×	×	×	×
`doc.title`	―	○	○	○	―	―	―	―
`doc.body`	―	×	×	○	―	―	―	―
名前空間なし XPath	―	○	○	○	―	―	―	―
名前空間付き XPath	―	×	○	○	―	―	―	―
`innerHTML`	―	○	○	○	―	―	―	―
スクリプト	―	×	×	×	―	―	―	―

DOM 3 Core では、文書ノードに対する cloneNode の動作は実装依存となっていますが、Firefox 3.5 以降では文書ノードを複製できます。なお、cloneNode は例外を投げないことになっていますが、Opera では文書ノードを複製しようとすると例外が発生します。

iframe 要素

function createHTMLDocument_iframe(source) {
  var iframe = document.createElement('iframe');
  document.body.appendChild(iframe);
  var doc = iframe.contentWindow.document;
  doc.open();
  doc.write(source);
  doc.close();
  document.body.removeChild(iframe);
  return doc;
}

	6	7	8	3	3.5	3.7a	3.7a HTML5	3.2	4	9.6	10
	Internet Explorer			Firefox				Safari		Opera
`doc`	○	○	○	○	○	○	○	○	○	○	×
`doc.title`	○	○	○	○	○	○	○	○	○	○	―
`doc.body`	○	○	○	○	○	○	○	○	○	○	―
名前空間なし XPath	―	―	―	○	○	○	○	○	○	○	―
名前空間付き XPath	―	―	―	×	×	○	○	○	○	×	―
`innerHTML`	○	○	○	○	○	○	○	○	○	○	―
スクリプト	○	○	○	○	○	○	○	○	○	△	―

iframe 要素を使って HTML 文書を生成します。IE でも動きます。iframe 要素を文書ツリーに追加しないと、doc が null になってしまうことがあります。Opera 9.6 では、スクリプトは実行されるものの、特定の操作 (document.write など) を行うと HTML 文書をうまく取得できなくなってしまうようです。また、Opera 10 では、iframe 要素の load イベントなどを見て非同期にアクセスしないと、うまく HTML 文書が取れないようです。

`ActiveXObject`

function createHTMLDocument_ActiveXObject(source) {
  var doc = new ActiveXObject('htmlfile');
  doc.open();
  doc.write(source);
  doc.close();
  return doc;
}

	6	7	8
	Internet Explorer
`doc`	○	○	○
`doc.title`	○	○	○
`doc.body`	○	○	○
`innerHTML`	○	○	○
スクリプト	○	○	○

IE でのみ使用可能です。フラグメント識別子付きの URL を参照する iframe 要素を含むソースを指定すると、挙動がおかしくなるそうです。

CID からの作成

const NS_HTMLDOCUMENT_CID = '{5d0fcdd0-4daa-11d2-b328-00805f8a3859}';
var doc = Components.classesByID[NS_HTMLDOCUMENT_CID].createInstance();

Firefox で、さらには拡張機能や userChrome.js スクリプトといった chrome 権限を持ったスクリプトでのみ可能な方法です。xpcshell のような document オブジェクトが存在しない環境でも HTML 文書を作成できます。この CID は、少なくとも Firefox 1.0 から 3.7a1pre まで変更されていません。これにより作られた文書は空なので、自分で要素を作って挿入する必要があります。

ちなみに、この方法を知ったのは、xpcshellでHTMLDocumentって無理なのかなぁ - The Other Road Ahead をきっかけに HTML 文書の作り方を調べていたときで、次のような経緯によります。

まとめ

createHTMLDocument が使えるなら、それを使うのが楽です。
Firefox では、作った HTML 文書をどう扱いたいのかによって、作成手段が異なってきます。XPath で要素を取りたいだけなら createDocument でもいいですし、Firefox 3 以下でも HTMLDocument 固有の機能を使いたいというのなら XSLT を使ったほうがいいかもしれません。
head 要素や body 要素がなくなるのが気になるなら、自分で作る必要があります。

Kanasan.JS JavaScript 第 5 版読書会 #8

Wed, 30 Sep 2009 03:41:56 +0900

Kanasan.JS JavaScript 第 5 版読書会 #8 に行ってきました。今回は初めての京都での開催、それも町家でという風情あふれる読書会。真夏真冬はちょっとつらいかもしれませんが、春秋はこういった場所での勉強会というのも乙なものですね。名古屋の DeLLa.JS では茶室での開催もあったそうでうらやましいことです。

ちなみに会場「お結び庵」の運営は home's vi ("h" を抜くと「おむすび」) という法人によるものだそうで。なんとなく名前に親近感を感じてしまうのは気のせいでしょうか。

読書範囲は「17.5 キーイベント」から「18章フォームとフォーム要素」まで。ブラウザごとに変な癖があるということが少なく (完全にばらばらか結構統一されているか)、さくさくと読めました。

キーボードショートカット

サイ本では、Web アプリケーションはキーボードショートカットをサポートすべきといっており、WCAG (ウェブコンテンツ・アクセシビリティ・ガイドライン) 2.0 (日本語訳) にもすべての機能をキーボードから利用できるようにするという指針があります。

しかし、製作者側でのショートカットキーの指定は、(特にアルファベットを含む場合) ブラウザやユーザー側で設定されたショートカットキーとの衝突や、サイト間での一貫性の欠如といった問題をはらんでいます。

個人的に、製作者側は、キーボードアクセス可能にするにあたって、

Tab: ウィジェット間の移動
矢印: ウィジェット内の項目の移動
Enter: 確定、実行
スペース: 状態の切り替え
Delete: 削除

といったある程度意味の定まったキーに対しては動作を指定すべきだが、アルファベットを含むショートカットキーは使用を避けるか、少なくとも無効にできるようにすべきだと思っています。

delete 演算子の使用

「17.6 onload イベント」のサンプルコードで、不要になったプロパティを delete 演算子で削除していますが、個人的には null を代入するほうが好みです。

最近の JavaScript エンジンでは、同じ構造を持つオブジェクト同士は同一の「クラス」に属するものとして扱います。あるオブジェクトのプロパティを delete 演算子を使って削除すると、そのオブジェクトの構造と属する「クラス」が変化することになり、速度的に不利になる場合があります。とはいってもスクリプト全体の実行時間からすれば気にするほどではなく、どちらを選ぶかは趣味の問題でしょう。

テキスト入力に対するイベント

テキスト入力欄 (input type="text"、textarea) の入力値の変化を通知するものとして change イベントがありますが、これは入力欄からフォーカスが外れるタイミングでしか発生しません。キー入力に逐次対応したいときは keydown、keypress イベントを、それ以外の手段による変更にも対応したいときはさらにタイマー (setTimeout、setInterval) を組み合わせるのが一般的なようです。

手段を問わず (少なくとも一定時間内の) 入力値の変化を監視するために、HTML5 では input イベントが定義されています。Firefox 1.0、Safari 3、Opera 9 以上が対応していますが、Opera では (10.00の時点でも) 切り取りやドラッグ & ドロップによる値の変更に反応しない (その場合フォーカスが外れた時点で input イベントが発生する)、WebKit (Safari、Chrome) では IME で未確定の入力にも反応するなど、実装にばらつきがあります。

ちなみに、切り取り、貼り付けに反応するものとして、IE の cut、paste イベントがあり、Firefox 3 以上、Safari もこれを実装しています (element.onpaste - MDC)。このイベントはバブルしますが、IE では文書要素 (html 要素) までしかバブルしないようです。

name 属性の名前空間

サイ本 18.3.1 節 (日本語版 p. 466) には

<form name="everything">

を

document.everything

で参照する例が出てきますが、この方法では document のプロパティ名とフォーム名が競合したときに困るので、name 属性ではなく id 属性を使い、document.getElementById などでアクセスしたほうがいいです。

勘違いされがちですが、form、img、a 要素の name 属性が要素を一意に識別するためのものなのに対し、input、textarea、select 要素の name 属性はサーバーに送信するコントロール名を指定するためのものと、同名の属性でも役割がまったく異なります。form 要素に限らず、前者に関しては id 属性を使ったほうが、他の要素との一貫性も取れて楽でしょう。

ただし、IE 7 以下では name 属性も id 属性と同じ名前空間に入ってくる (document.getElementById("foo") で name="foo" な要素が返ることがある) ので、フォームコントロールの name 属性と、ある要素の id 属性とが同じ値を取らないようにしたほうがいいかもしれません。

フォームコントロールの値中での改行

フォームコントロールの値が改行を含むとき、その改行コードはブラウザによってさばらばらです。IE の場合、value プロパティに \r や \n を含む文字列を設定しても、取得時にはすべて \r\n になっています。このような状況に対応するため、私は次のように改行コードを統一することがあります。

var value = control.value.replace(/\r\n?/g, "\n");

なお、この改行コード変換用正規表現は、Perl では正しくないそうですが、JavaScript では問題ないと思います。

IE での属性セレクタ

IE 7 以上は CSS の属性セレクタに対応していますが、スクリプトから属性に変更を加えても表示が更新されないというバグがあります (IE 8 でも発生)。その場合でも class 属性などをいじると、それまでの変更が表示に反映されるようです。

<style type="text/css">
[title="foo"] { color: #c63; }
</style>

element.setAttribute('title', 'foo');
// IE では、ここで終了すると element の色が変化しない

element.className += '';
// この時点で element の色が変化する

JavaScript の Iterator、関数とコンストラクタ

Sun, 09 Aug 2009 16:21:26 +0900

オンライン勉強会の Jetpack 入門に参加して Jetpack のソースコードを読んでいたら、Iterator を関数として呼び出したときとコンストラクタとして呼び出したときとでは挙動が違うということを知りました。

`Iterator` の動作

オブジェクト o に対して for-in 文、for-each-in 文を実行したとき、及び Iterator 関数、Iterator コンストラクタを呼び出したときの (SpiderMonkey の) 動作は、それぞれ次のようになります。

コード	`o` が `__iterator__` メソッドを持つとき	`o` が `__iterator__` メソッドを持たないとき
`for (... in o)`	`o.__iterator__(true)` の返り値がイテレータとして使われる	`o` の列挙可能なプロパティの名前を列挙する `Iterator` オブジェクトが作成され、イテレータとして使われる
`for each (... in o)`	`o.__iterator__(false)` の返り値がイテレータとして使われる	`o` の列挙可能なプロパティの値を列挙する `Iterator` オブジェクトが作成され、イテレータとして使われる
`Iterator(o, keysOnly)`	`o.__iterator__(Boolean(keysOnly))` の返り値が返される	`o` 自身の列挙可能なプロパティの名前 (`keysOnly` が真と評価されるとき)、または名前と値を収めた配列 (そうでないとき) を列挙する `Iterator` オブジェクトが作成され返される
`new Iterator(o, keysOnly)`	`o` 自身の列挙可能なプロパティの名前 (`keysOnly` が真と評価されるとき)、または名前と値を収めた配列 (そうでないとき) を列挙する `Iterator` オブジェクトが作成され返される	`o` 自身の列挙可能なプロパティの名前 (`keysOnly` が真と評価されるとき)、または名前と値を収めた配列 (そうでないとき) を列挙する `Iterator` オブジェクトが作成され返される

列挙可能なプロパティとは ECMAScript でいう DontEnum 属性を持たないプロパティ、o 自身のプロパティとは o のプロトタイプチェーンをたどらずに得られるプロパティのことです。また、Iterator 関数及びコンストラクタの keysOnly 引数は省略可能であり、省略した場合は false を指定したものとして扱われます。

なお、JavaScript 1.7 では for-in 文で分割代入を使ったときにこれと異なる動作をしますが、JavaScript 1.8 で修正されたのでここでは触れません。

事例

var iteratorLikeObject = {
  array: ['p', 'q', 'r'],
  index: 0,
  next: function () {
    if (this.index < this.array.length)
      return this.array[this.index++];
    this.index = 0;
    throw StopIteration;
  }
};

var o = {
  a: 10,
  b: 20,
  __iterator__: function (keysOnly) {
    print('keysOnly = ' + keysOnly);
    return iteratorLikeObject;
  }
};

for (let i in o) print(i);
// => keysOnly = true
// => p
// => q
// => r

上のコードでは、__iterator__ メソッドを持つオブジェクトに対して for-in 文を実行しているので、__iterator__ メソッドの返り値である iteratorLikeObject がイテレータとして使われます。よって、列挙される値はその next メソッドの返り値である文字列 "p"、"q"、"r" となります。

ここで、Iterator 関数を使ってみるとどうなるでしょうか。

for (let i in Iterator(o)) print(i);
// => keysOnly = false
// => array
// => index
// => next

Iterator 関数の返り値は iteratorLikeObject なので、このオブジェクトに対して for-in 文が実行されます。しかし、iteratorLikeObject は __iterator__ メソッドを持っていないため、そのプロパティの名前が列挙されます。

では __iterator__ メソッドを追加してみましょう。

iteratorLikeObject.__iterator__ = function (keysOnly) {
  print('keysOnly in iteratorLikeObject = ' + keysOnly);
  return this;
};

for (let i in Iterator(o)) print(i);
// => keysOnly = false
// => keysOnly in iteratorLikeObject = true
// => p
// => q
// => r

再び iteratorLikeObject に対して for-in 文が実行されますが、今度は __iterator__ メソッドが存在します。しかも、__iterator__ メソッドでは自分自身を返しているため、iteratorLikeObject がイテレータとして使われ、その next メソッドの返り値が列挙されます。

ここで、Iterator を関数ではなくコンストラクタとして使うと、そもそも o の __iterator__ メソッドが呼び出されなくなります。

for (let i in new Iterator(o)) print(i);
// => a,10
// => b,20
// => __iterator__,function (keysOnly) {
// =>     print("keysOnly = " + keysOnly);
// =>     return iteratorLikeObject;
// => }

Iterator コンストラクタは、オブジェクト自身が持つプロパティを調べるときに便利です。

var o = {
  public1: 10,
  public2: 20,
  _private: 30,
  __proto__: {
    inherited: 40
  }
};
var keys = [i for (i in new Iterator(o, true)) if (!/^_/.test(i))];
print(keys.toSource());
// => ["public1", "public2"]

`Iterator` オブジェクト

Iterator 関数またはコンストラクタにより作られる Iterator オブジェクトは、next メソッドと __iterator__ メソッドを持ちます。他の組み込みオブジェクトのメソッドと異なり、これら 2 つのメソッドは上書きも削除もできません。

Iterator オブジェクトの __iterator__ メソッドは、引数によらず常に自分自身を返します。これにより、for (... in new Iterator(...)) と for each (... in new Iterator(...)) は同じ動作をすることになります。

var anyObject = {};
print(Iterator.prototype.__iterator__.call(anyObject) === anyObject);
// => true

ある Iterator オブジェクトが、どのオブジェクトのプロパティを列挙するものなのかは、__parent__ プロパティからわかります。

var anyObject = {};
var iterator = new Iterator(anyObject);
print(iterator.__parent__ === anyObject);
// => true

LiveCoding #6 の 2

Sun, 19 Jul 2009 23:40:45 +0900

OSC Kansai に出た帰りに satzz 君に電話したら、ちょうど LiveCoding #6 をやっているとのことだったのでその足で寄ってきました。前回も第 6 回だった気がするのは何かの間違いでしょうか。

LiveCoding とはプログラミングの実演と実況を楽しみましょうというイベントで、出てくる言語も C から PHP まで色とりどり。まともとは思えないテクニックも多々披露されたわけですが、中でも驚愕だったのが ujihisa さんが書いた Ruby のコード、

def fib n, x = (n < 2) ? n : fib(n - 1) + fib(n - 2)
  x
end

fib 10 # => 55

Ruby ではデフォルト引数内で再帰呼び出しができるだなんてちっとも知りませんでした。

飛び入り LiveCoder も大歓迎といわれ、その特典である参加費 (お寿司 + カレー代 + etc.) キャッシュバックを目当てに手を挙げたのですが、ネタが思い浮かばず、bit.ly API の存在を教えてもらって「Web ページ閲覧中にリンク先が bit.ly 経由で何回クリックされたかを表示する Greasemonkey スクリプト」を作ることにしました。

Greasemonkey スクリプトでは let を使えないのについ let と打ってしまって var と打ち直したり、Greasemonkey と bit.ly と wedata の API リファレンスを読みふけったり、E4X で構築した要素を手っ取り早く使うために innerHTML を使おうと思ったら、そもそも要素を作成する必要がないことがわかって単なるテキストを innerHTML に代入する羽目になったり、それならとテキストノードを直接生成するように書き換えたりしているうちに制限時間 20 分はあっという間に過ぎ、45 分かけてどうにか動くものができるという有様。動くのは LDRize 対応サイトのみ、利用するには Firefox 3.5 以上と bit.ly のアカウントが必要です。

その場で cho45 が「こういうときは JSDeferred を使えば」とプッシュしていた気がするので、後日 JSDeferred を使って書き直してみました。JSDeferred をうまいこと使えているかは不明ですが。

ちなみに Greasemonkey スクリプトで let が使えないというのは、Components.utils.evalInSandbox で JavaScript のバージョンが指定できないという制限によるものです。この仕様は Firefox 3.5 で改善され、適切なバージョンを指定すればサンドボックス内でも let、yield を使えるようになりましたが、Greasemonkey 側はまだ対応していません。

コーディングが終わった後はまったり過ごしていましたが、JSDeferred のロゴを作れば女子高生の間で JSDeferred が流行るんじゃないかという話になったため、実際に作ってみました。secondlife さんに「何この 5 秒で描いたような」と dis られましたが、30 秒はかかっています。JSDeferred のトップページにもこのロゴを貼り付けたので、ナウなヤングにバカウケ間違い無しですね。

それと、Gist で Greasemonkey スクリプトを管理しようという話を聞きますが、皆さん具体的にどうやって管理しているんでしょうか? とりあえず Greasemonkey スクリプトを書いた後、gisty で投稿してそれを git remote で引っ張ってきてとやったのですが、これでいいのかよくわかりません (環境は Cygwin + Meadow)。

$ cd FIREFOX_PROFILE_DIR
$ cd gm_scripts/bitly_referred/
$ ls
bitly_referred.user.js
$ gisty post bitly_referred.user.js
Initialized empty Git repository in GISTY_DIR/149553/.git/
$ git init
$ git remote add origin git@gist.github.com:149553.git
$ git pull origin master
$ cat > .gitignore
*
!*.user.js
$ meadoww bitly_referred.user.js
$ git add .
$ git commit -m "Rewrite with JSDeferred"
$ git push

第 2 回 Firefox 出張ワークショップ発表資料

Wed, 15 Jul 2009 02:17:01 +0900

先日京都コンピュータ学院で開催されたオープンソースカンファレンス 2009 Kansai、その中の一セッション「第 2 回 Firefox 出張ワークショップ～基礎から学べる拡張機能開発～」に講師として参加させていただきました。私の担当した後半、実際に拡張機能を作ってみる部分の資料及び完成版の拡張は以下になります。

Firefox 拡張機能開発ワークショップ in OSC Kansai 2009
contexthistory-0.1.xpi
ソースコード
- chrome/
  - content/
    - contexthistory.js
    - contexthistory.xul
- chrome.manifest
- install.rdf

「わからないことがあったとき、どうやって調べるか」をひとつの柱として話を進めていきたかったのですが、つたない進行で後半ややペースが押し気味になってしまい、終了時間を 5 分ほど過ぎて最低限動くものが完成するという有様でした。人によっては休憩時間もろくに取れない状態になってしまい申し訳ありません。

以下に質問のあった点、補足等を記します。

「進む」メニューの特定

DOM Inspector でコンテキストメニューの「進む」メニューを探すのにいちいち文書ツリーをたどっていったのですが、後ほどあさんから指摘があったように、クリックで要素を選択する機能を使ったほうがはるかに簡単でした。

具体的には、DOM Inspector でブラウザウィンドウを選択後、マウス選択ボタンをクリックし、ブラウザウィンドウに戻ったらアプリケーションキーまたは Shift + F10 キーでコンテキストメニューを表示させます。そうすれば後は「進む」メニューを直接クリックするだけで DOM Inspector 側で適切な要素が選択されます。

マウス選択状態では右クリック (Mac では Ctrl + クリック) してもその要素が選択されてしまうので、文書ツリーをたどっていく必要があると思っていたのですが、キー操作でコンテキストメニューを表示させればいいというのは個人的に盲点でした。

名前付き関数式

ContextHistory オブジェクトの各メソッドを記述する際、

var ContextHistory = {
  init: function CH_init() { ... },
};

と CH_init のような名前をつけていることへの質問がありました。名前をつけることでスタックトレースにその名前が出るようになり、デバッグが楽になります。つけないと anonymous function といった表示になり、名前から関数を特定できません。

XUL 要素の動的な生成

XUL、XHTML、SVG といった特定のXML応用の要素を生成するときは、document.createElementNS メソッドを使い、第 1 引数にその XML 応用の名前空間 URI を指定します。一応 XUL 文書中では createElement メソッドでも XUL 要素が生成されますが、そのような DOM 仕様にない Mozilla 独自の振る舞いに依存すべきではありません。さもなくば XUL と他の XML 応用とを組み合わせるときなどに混乱を招くことになります。

よく参照する Firefox のソースコード

Mozilla Cross-Reference で Mozilla の (Firefox の) ソースコードを閲覧・検索できます。私の場合、実際によく参照するのは次のような箇所です。

Firefox の機能とそのソースコードの場所
機能	Firefox 3.5 系統	最新開発版
ブラウザの UI	/browser/base/content/	/browser/base/content/
DOM インターフェース	/dom/public/idl/	/dom/interfaces/
UI 部品	/toolkit/content/widgets/	/toolkit/content/widgets/

数値への変換

JavaScript で +expr は Number(expr) と同じ意味であり、expr を数値へ変換した結果を返します。

ラベルの国際化

追加したメニューのラベルを、ロケールによらずツールバーの履歴ドロップダウンボタンのツールチップと同じにするのが目標でした。たとえば次のような手順が考えられます。

DOM Inspector で履歴ドロップダウンボタンを選択し、その id を確認する。
view-source:chrome://browser/content/browser.xul からその id を検索し、ツールチップ文字列を表す実体参照を見つける。
MXR で実体名を検索し、その実体が含まれる DTD ファイルを見つける。
MXR で見つかった DTD ファイル名と browser.xul のソースで参照している DTD の chrome URI とを見比べ、その DTD ファイルを指す chrome URI の見当をつける。
オーバーレイファイルからその DTD を参照し、メニューのラベルとしてその実体参照を記述する。

<!DOCTYPE overlay [
  <!ENTITY % browserDTD SYSTEM "chrome://browser/locale/browser.dtd">
  %browserDTD;
]>

修正の反映

最初のほうで QuickRestart を紹介した影響か、ソースコードを修正するたびに Firefox を再起動していた人が多かったですが、実は about:config から nglayout.debug.disable_xul_cache を true にしておけば、新しいウィンドウを開くたびに最新のソースコードが読み込みなおされます。ただし、XPCOM コンポーネントや JavaScript モジュールはこの限りではありません。

拡張の JavaScript の名前空間

JavaScript には名前空間が存在しないので、拡張のスクリプトを書くときは、Firefox 本体や別の拡張が使っている名前と競合しないように注意する必要があります。これは拡張から Firefox 本体を自由に操作できることの裏返しでもあります。

JAR ファイルの利点

拡張の構成ファイルを単独の JAR ファイルに固めることで、アクセスするファイルがひとつですむようになり、ファイルアクセスの負荷を減らすことができるそうです。

ローカルな拡張の自動更新

たとえば企業内のみで使いたい拡張があるというとき、自動更新に対応させるためには、SSL を通じて更新を配布するか、電子署名を使い拡張に公開鍵を含める必要があるそうです。

Kanasan.JS JSDeferred コードリーディング

Tue, 30 Jun 2009 23:55:57 +0900

すっかり記事を書くのが遅れてしまいましたが、Kanasan.JS JSDeferred コードリーディングへ行ってきました (参加者ブログ記事一覧)。JSDeferred は cho45 さん作の、非同期処理を簡単に記述するためのライブラリです。簡単なリファレンスもありますが、実際に動かせるサンプルのほうがどんなものか感覚をつかめると思います。

Deferred オブジェクト

JSDeferred では、ひとつの処理をひとつの Deferred オブジェクトとして表現し、処理の流れは Deferred オブジェクトを順につなげた Deferred チェーンで表します。Deferred オブジェクトは三つのプロパティを持ちます。

callback.ok プロパティ: (正常) 処理の本体を表す関数。
callback.ng プロパティ: 例外処理の本体を表す関数。
_next プロパティ: Deferred チェーン上の次の処理 (継続) を表す Deferred オブジェクト。

さらに、Deferred オブジェクトの実行状態を意識すると、JSDeferred を使って書かれたコードが読みやすくなるのではないかと思います。

待機 (idle) 状態: 処理が実行されない状態。call/fail メソッドが呼び出されると実行中状態へ移る。
実行待ち (waiting) 状態: 処理がそのうち実行される状態。cancel メソッドが呼び出されると待機状態へ移る。
実行中 (running) 状態: 正常処理または例外処理が実行されている状態。処理本体の実行が終了したら待機状態へ移る。このとき、処理本体の返り値が Deferred オブジェクトなら、その Deferred オブジェクトの継続 (_next プロパティ) を自身の継続と同じにする。そうでなければ、自身の継続たる Deferred オブジェクトを実行する (実行中状態へ移す)。

わかったこと、注意すべきこと

単に new Deferred() または Deferred() とすると、待機状態の Deferred オブジェクトが作られる。
処理本体で Deferred オブジェクトが返されたなら、自身の継続を (直接は) 実行しない。
parallel 関数は飛ばして、先に next 関数、wait 関数を読んだほうがよさそう。
next 関数 (Deferred.next) と next メソッド (Deferred.prototype.next) は別物。
- next 関数は、実行待ち状態の Deferred オブジェクトを新規作成する。引数に渡された関数がその Deferred オブジェクトの処理本体となる。
- next メソッドは、待機状態の Deferred オブジェクトを新規作成し、それを自身の継続とする。引数に渡された関数がその Deferred オブジェクトの処理本体となる。自身の実行状態は変化しない。
next 関数については、とりあえず next_default だけを見れば十分。
- next_faster_way_readystatechange、next_faster_way_Image は、特定の環境用に高速化を施した版。詳細は「JSDeferred を高速化する (試し中) - 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 - subtech」を参考に。
他の記事では、「JSDeferredがやっとわかった - by edvakf in hatena」が詳細でわかりやすい。

Deferred チェーンの図示

next(function f() {
  ...
  return next(function g() {
    ...
  });
}).
next(function h() {
  ...
});

は、最初に次のような Deferred チェーンを作ります。

ここで、Deferred チェーン先頭の Deferred オブジェクトの処理が終了し、f が Deferred オブジェクトを返すと、Deferred チェーンは次のようになります。

h (を処理本体とする Deferred オブジェクト) は f (を処理本体とする Deferred オブジェクト) の継続として実行されるわけではありませんが、g (を処理本体とする Deferred オブジェクト) の継続として実行されるので、結局 f、g、h の順番で処理が進むことになります。

また、f で待機状態の Deferred オブジェクトを返せば、処理の流れをいったん f で止めておき、明示的にその Deferred オブジェクトの call メソッドを呼び出したときに h から処理の流れを再開するといったことができます。

Web 開発者の責任 (翻訳)

Wed, 06 May 2009 19:31:46 +0900

John Resig 氏による A Web Developer's Responsibility という記事が素晴しかったので、著者の許可を得てここに日本語訳を掲載します。

Web 開発者の最大の負担は、ブラウザのバグと非互換性への対応に膨大な時間を費やすことであるといって間違いないでしょう。それゆえに、それらへの対応に不満をいうのは、Web 開発者全員の常となっていました。ブラウザのバグは迷惑でいらだたしく、仕事を大幅に難しくします。

ブラウザのバグはとてもいらだたしく、通常の開発における最大の負担です。ですから、開発対象のブラウザが、自身のバグを見つけ修正できるようにしてやるのは、すべての Web 開発者にとっての責任です。自分が見つけたバグに対して責任を持ち、「ほかの誰かがこれを見つけるだろう」とは思わないことで、ブラウザの進歩の速度は加速していくでしょう。

ブラウザを支援する解決策は 2 段階からなります。第 1 に、ブラウザのバグを見つけるたびに、個別のブラウザへバグ報告を登録しましょう。第 2 に、自分のサイトを主なブラウザの最新のビルドで積極的にテストしましょう。

Web 開発者の圧倒的多数は、一度もブラウザベンダにバグ報告を登録したことがないばかりか、ブラウザのナイトリー版を使ったことさえありません。これは恥じるべきことです。考えてみれば、ブラウザの何が異常かを評価するのに、ブラウザでの開発に日々を費やす人ほどその資格がある人というのはほとんどいないのです。

ブラウザのバグを登録せず、ナイトリーでのテストもしないプロの開発者を見たとき、私は特に驚きました。ほとんどの開発者の主な仕事のひとつに、クロスブラウザの問題を取り繕うことがあります。よって、バグの数を減らす (そして仕事を劇的に単純化する) ことは最優先事項になります。

私は個人的に全主要ブラウザベンダにバグ報告を登録してきて、良い報告を生み出すいくつかの特徴に気づきました。

良いバグ報告の登録方法

良いバグ報告を生み出す 3 つのポイントは、分類、テストケース、そして単純化です。正しく分類され、単純化されたテストケースが提供されたバグは、どんなものでもブラウザの開発者によるレビューが保証されます。

バグを登録する場所から始めましょう。

バグ報告を登録する

大抵、バグ報告を登録するときは、実際の提出フォームへたどり着く前に、いくつかの深い層を通り抜けなければいけません。最も利用すべきフォームの直接の URL を以下に示します。

バグを登録するときは、登録対象のブラウザの最新のナイトリー (後で説明します) でもテストしておきましょう。これは、ブラウザの開発者が最初に尋ねることのひとつです。もしそのブラウザの現在の開発版でも依然としてバグが存在し、いまだ修正されていないことを示せたのなら、ブラウザの開発者たちはずっと簡単に取り組み始められるでしょう。

注: 多くのバグ報告ページは、報告を提出する前にアカウントの作成を求めてきます。これは迷惑ですが負担は 1 回きりです。

バグを分類する

バグを適切に分類することは重要な第一歩です。しばしば、(レイアウトや DOM といった) 特定のモジュールのオーナーは、新しく来た提出をすべて監視しています。バグを適切な分類に割り当てることは、そのバグを修正するのにもっとも適した人物の眼前へ、直ちにバグを持ち込むことになります。

バグの分類はブラウザ次第です。(Opera や Internet Explorer のような) いくつかのブラウザがバグの登録に簡易的な分類を用意している一方で、他のブラウザ (WebKit/Safari や Mozilla/Firefox) は機能が存在する特定のモジュールを示すために複雑な分類を使います。

Mozilla/Firefox: コンポーネントを選択してください。最も一般的なのは DOM、Layout、JavaScript Engine などです。

WebKit/Safari: コンポーネントを選択してください。最も一般的なのは HTML DOM、Layout and Rendering、JavaScriptCore などです。

Google Chrome: Chrome に対して登録すべきか判断するのには注意が必要です。最初に Safari の最新リリースと最新の WebKit ナイトリーとの両方でバグをテストしてください。もしバグが Chrome のみに存在するのならそこに登録し、そうでなければ WebKit/Safari にバグを登録しましょう。しかし、もうひとつ問題があります。Chrome の JavaScript エンジン (V8) にのみ存在するバグは、(どさくさにまぎれて行方不明にならないよう) Chrome ではなく V8 のバグトラッカーに登録されるべきです。

また、Chrome は明示的な分類手段を提供していません。すべてのバグは開発者によりレビューされ、それから分類されます (このプロセスを制御することはできません)。

複数のプラットフォーム (OS X と Windows、Windows と Linux など) でのテストも手早く行うべきです。バグが複数のプラットフォームに存在することを特定すれば、ブラウザの開発者がバグの原因の発見に必要とする時間を削減するのに劇的に役立ちます。

テストケースを提供する

再現可能なテストケースは、どんな形式であれ何もないよりは優れています。問題が封入された Web ページは一般的に良い取っ掛かりとなります。もし Web ページをバグ報告に直接添付できるのなら、さらに良いでしょう (ブラウザの開発者がそのチケットに取り組むのには、しばらく時間がかかるかもしれません。指定された URL にテストケースがもはや存在しなければ、開発者は単にチケットを閉じてほかの作業へ移るでしょう)。

そうはいっても、悪いテストケースというべきものもあります。最悪なのは「http://example.com の Web サイトを見たら、ブラウザ X では動かなかったので、修正してください」といった類のものです。これは、失敗の正確な理由を見つけだすため、誰かに膨大な時間をとらせることになり、バグをキューのより後ろへと押し出すでしょう。

最良のテストケースは単純さを提供する類のものです。

単純さを提供する

単純なテストケースを提供することは、間違いなくバグ報告を作成する上で一番難しく、かついらだつ部分です。しかしこれは、大概報告に気づき修正してもらう上での重点でもあります。最も資質のある開発者でさえ、十分良いテストケースを作成するのに 30 分もかからないでしょう。

このようなテストケースを作成する手順は単純です。バグがあるページを持ってきて、バグの再現に影響しないものをすべて切り取ってしまうのです。これは、スタイルシート、画像、JavaScript ファイル、JavaScript ライブラリ、そして HTML を含みます。

たとえば、しばらく前に私が Dromaeo テストスイートを走らせていたとき、WebKit がある地点に到達すると常にクラッシュすることに気づきました。私はまず、不必要な HTML、CSS、画像などテストを切り取ることから始めました。最終的に私は単独のテストにたどり着きました。文字列の分割です。それから私は、外部依存が必要なくなるように、可能な限りテストスイートを剥ぎ取っていきました。

最終結果に注目してください:

var str = "", ret, fn = [];

for ( var i = 0; i < 16384; i++ )
  str += "a";

for ( var i = 16384; i <= 131072; i *= 2 ) (function(i){
  fn.push(function(){
    ret = str.split("");
  });

  str += str;
})();

window.onload = function(){
  setInterval(function(){
    if ( fn.length )
      fn.shift()();
  }, 13);
};

残ったものは、依然としてクラッシュを起こすにもかかわらず、これ以上ないほど単純です。この単純化に基づいてこの問題の理由はすばやく特定され、たった 2 週間後には解決されていました。

私のバグに取り組んでいますか?

これは興味深い点です。しかし、Mozilla/Firefox、WebKit/Safari、Chrome では (これらはすべて比較的開かれたプロジェクトなので) 判断しやすい点です。これら各ブラウザでバグの状態を判断する最良の方法を以下に示します。

Mozilla/Firefox: バグは、最初に選択したコンポーネント分類のデフォルトの窓口係に割り当てられるところから始まります。これはまだ何も意味せず、単純に人々の目をチケットにひきつけるだけです。人々はそのチケットに自分自身を CC し始めます (これはその人がそのバグの進行に興味を持つという意味です)。しかしながら、決定的な瞬間は、誰かがそのバグを自分自身に割り当てたときで、事実上その人がそのバグの状態に責任を持ち始めます。ほとんどの貢献者はそのバグにつけられるコメントが自動的にメールされるよう設定しているので、そのバグの状態に関して何かしら疑問があれば、遠慮せずコメントを投稿できます。しかし、そういったことは適度なペースで行ってください (日ごとに、あるいは週ごとにでさえ、更新状況を尋ねることは貢献者をいらだたせるでしょう)。

WebKit/Safari: WebKit は Mozilla/Firefox ととてもよく似た設定を使います。そのバグを管理し完了まで後押ししてくれる誰かをただ受け入れましょう。しかしながら、黄金のチケットはそのバグが「rdar へ行く」時です。Radar は Apple の内部的な (非公開の) バグトラッカーです。バグがそこへ移動したということは、事実上 (そのバグを「所有する」人によってでなくても、別の Apple の従業員によって) そのバグのある時点での完了が保証されるということです。Apple は依然として WebKit の更新の裏での大きな立役者なので、バグが rdar に移されるのは期待すべきことです。とはいっても、rdar は非公開で Apple の従業員向けなので、バグが完全に修正されるか、またそれはいつかを知るという恩恵はもはや得られません。そうなれば後は待つのみです。

Chrome: Chrome は Mozilla/Firefox ととてもよく似たシステムを使います。そのバグが現在割り当てられている人とのコミュニケーションを持続し、彼らが持つだろう質問には何でも答えるようにしましょう。

最終的にバグが解決されたのなら、おめでとうございます! あなたは Web を万人にとってよりよい場所にするのに役立てたのです。

しかし、いつもそうなるとは限りません。

私のバグが却下されたらどうなりますか?

却下されたバグは次の 2 通りに分類されます:

バグではなかったので却下された。
ブラウザベンダがそのバグに取り組みたくないので却下された。

1 番目はさらに 2 つの小分類に分けられます。

本当にバグでなかったのなら、おめでとうございます! 標準、あるいはそれ以外のブラウザのあいまいさに関する、今まで詳しくは知らなかったことを学べました。今やあなたはよりよい Web 開発者です! ブログへ向かい、発見したあいまいな新しいバグや API に関して書き、それを世界に向けて説明すべきです。

または、バグなのに所有者が不必要にバグを閉じてしまいました。こうなると、バグを再開するために、この状況について議論する必要があります。

2 番目 (ベンダーがバグに取り組みたくない場合) もまた 2 通りに処理されます。

第 1 に、バグの状況について議論しましょう。これはブラウザの開発者に、この問題を修正するために貴重なリソースをささげるべきという情報を与えるのに役立ちます。

または第 2 に、もし彼らが本当にそのバグの修正を嫌がっているのなら、ブログや Twitter アカウント、それに他の Web 開発者があなたの言うことを聞いている場所で厳しく叱責しましょう。もしあなたの立場に同意してくれる人を誰も見つけられなかったのなら、おそらくあなたがおかしいです。しかし、もしそれが、ブラウザベンダが修正を拒んではいるが正当な問題だったのなら、結束しおおっぴらに苦情を申し立てられるほかの人が簡単に見つかるはずです。まさにこれでいいのです。あなたはこの結果を正しく獲得しました。このバグを明るみに出すのに必要なすべての正当な努力をすることにより、すべての宣言でこれに関して不満を言うのに十分な特権を得るのです。

バグを議論する

ここで、あなたはバグが閉じられた時点にいるものとします。このとき、閉じた人にそれは間違いだ、すなわち、このバグは実際に正真正銘のバグである、と納得させる必要があります。

こうしたときに使える最良の論拠のいくつかを、使うべき順番に沿って以下に示します:

そのバグが退行であることを示しましょう。それが以前のリリースでは動いており、変更のせいで動かなくなったことを証明しましょう。#2 と併用するととても効果的です。
実在の Web サイトが壊れていることを示しましょう。もし実際の利用者が、ポーランドの X 銀行やカナダの Y ショッピングサイトをもはや訪れようとしないことを示せれば、ブラウザはその問題を修正するためにあっさり全力を尽くすでしょう (Opera でない限り。その場合 Opera 側はサイトを強制的に動かすために browser.js を使うかもしれません。しかし、それはまた別の話です)。
そのバグが修正されないことで破られている Web 標準を示しましょう。もしある特定のバグが修正されないことが原因で、W3C DOM 仕様が正しく実装されていないことを示せたなら、ブラウザベンダはそれを修正しなければいけないと感じるでしょう。もしそう感じないなら、これは格好のブログの題材となるでしょう。
そのバグを修正しないことで他のブラウザとの互換性が失われることを示しましょう。もし IE と Safari、Opera のすべてがある特定の機能を実装するか、ある特定のバグを修正したなら、Firefox は (それが仕様と矛盾しない限り) 他の実装に従わなければならないでしょう。これは最も議論しづらいことです。しかし、より多くのブラウザが同行していればいるほど、話はより簡単になります。

もしこれらの段階のいずれも証明できなかったなら、何にせよあなたはただ自分の痒いところを掻いているだけであり、そのバグはほうっておくべきです。

例

私が異なるブラウザベンダに登録したバグの代表例をいくつか見せたいと思います。

WebKit/Safari

半径 0 の canvas の arc() が例外を投げる: canvas の arc() メソッドの呼び出しが例外を投げていました。私はとても単純なテストケースを提供し、仕様のうち WebKit が一致していない部分を指し示しました。これは投稿されたのと同じ日に解決されました。

多数の生きたオブジェクトに起因する .split("") でのメモリ不足エラー: ホストされた Web ページを単純簡潔にしたものを提供し、約 3 週間後に修正されました。

Mozilla/Firefox

Array.prototype.sort の大幅な速度低下: 単純簡潔な退行を示しました。正確な問題を突き止めるのにとても役立つ大量の Shark プロファイルデータをバグに含めました。これは 1 ヶ月以内に修正されました。

.children を実装すべき: Mozilla が (他の主要なブラウザすべてに存在する) .children メソッドを実装する必要があるか議論しました。十分な議論から、最終的 (約 6 ヵ月後) にそれを含めることになりました。

Internet Explorer 8

querySelectorAll の NodeList の例外: 単純なテストケースを提供し、「時間不足」のため却下されました。

現時点で私たちはこの問題を修正するつもりはありません。報告を理解してはいますが、残念ながら私たちは、顧客と Web 開発者に対する価値を最大化するために、何の作業をするか選択する必要がある段階にいるのです。

つまり、彼らはそれが問題であるということに同意しながら、修正するつもりはないのです。ですので、私は今それについて不満を訴えています。

HTMLElement.prototype.querySelectorAll が存在しない: 後でわかりましたが、これは querySelectorAll が標準準拠のページにのみ存在する (互換モードには存在しない) ことが原因でした。これはまったく奇妙なことですが、私はその決定の背後にある論拠を理解したと思います。いずれはっきりしますが、一度 IE 8 が動き始めれば、これが多くの人々を困惑させるのではないかと私は思っています。私は今や IE 8 についてより多くのことを知っており、IE 8 に対するより良い開発者です。

Google Chrome

for in ループが定義された順序で発生しない: これは互換性の問題でした (他のすべてのブラウザは特定のやり方で振舞います)。私は単純なテストケースを提供しました。このバグは誤って WontFix として閉じられましたが (これは混乱を招きました)、実際には修正されました。私はここで間違いを犯し、V8 に対して登録すべきこのバグを、実際は Chrome に対して登録してしまいました。V8 側でこの問題を扱うバグをここに示します。

setTimeout(..., 0) の発火が早すぎる: これは実際には Chrome チームによる構造の変更に起因するものでした。Mike Belshe (その変更の作者) が何が起きたのかを説明するために私へ個人的にメールを送ってきました。結果として私はより情報を得て、そのことに関するブログを書きました。

Opera

(私の知る限り、Opera はバグ報告に対する公式の公開された場を提供していません。)

ナイトリービルドのテスト方法

ブラウザのナイトリービルドでのテストの詳細に入る前に、私はおそらく最も一般的な質問に答えるべきでしょう。なぜブラウザのナイトリービルドをテストすることに気を遣うべきなのですか? それには 2 つの理由があります。

第 1 に、バグ報告を登録するときは、提出しようとするバグが既に修正されているかどうかを判別する必要があるでしょう。もしそれがナイトリーで既に修正されていたなら、それを提出するか悩む必要はありません。そのバグは次のリリースで修正されるでしょう。しかしながら、もしそのバグが解決されていなかったら、バグの登録を続けるべきです。

第 2 に、ブラウザがリリースされたときにあなたのコードが壊れていないか確かめるために、そのブラウザの最新のナイトリーであなたのサイトまたはライブラリを定期的にテストすべきです。どれくらいの頻度でテストするかはあなたしだいです。しかし、より頻繁にテストすればするほど、あなたのサイトまたはライブラリが、ある時点で大規模な退行に遭遇する可能性は低くなります。自分たちのサイトを壊す新バージョンのブラウザがマーケットに存在することを見つけて喜ぶ開発者はいないといって間違いないと思います。

ナイトリーに対するバグの登録は、他のバグの登録と同じです。単純化されたテストケースを提供し、退行が起きたことを強調するようにしましょう。もしあなたが十分な頻度でテストしていれば、開発者は行動に取り掛かるに違いないでしょう。

Kanasan.JS JavaScript 第 5 版読書会 #7

Tue, 28 Apr 2009 00:36:25 +0900

Kanasan.JS JavaScript 第 5 版読書会 #7 に行ってきました (当日のチャットログ)。範囲は前回に引き続き CSS の操作、そしてイベント周りと、一般に「JavaScript」といったとき話題になりやすい部分です。参加者のブログ記事は「JavaScriptでCSSとイベントを扱う from Kanasan.JS | Blog.37to.net」のほか読書会のページからたどれます。

`display: inline-block;`

サイ本では解説されていませんが、CSS の display プロパティの値 inline-block に関して話が盛り上がりました。inline-block 及びそれがどのようなレイアウトに使えるかについては以下で解説されています。

ところで、上記ページのサンプルはいずれも Firefox 2 以下で -moz-inline-box を使っています。しかし、-moz-inline-box が指定された要素の子要素は XUL のボックスモデルに従って整形されるため、そのままでは期待した表示になりません。ヨモツネットのサンプルではこの問題への対策として子要素に幅を指定していますが、別のアプローチとして子要素に -moz-box-flex プロパティを指定するという方法もあります。実際にこの方法を用いたページ送りのサンプルを作ってみました。HTML と CSS は次のようになります。

<ul>
  <li><a href="http://example.org/">1</a></li>
  <li><a href="http://example.org/">10</a></li>
  <li><a href="http://example.org/">100</a></li>
  <li><a href="http://example.org/">1000000000000</a></li>
</ul>

/* デフォルトのマージン、パディングが影響しないように。 */
ul, li {
  margin: 0;
  padding: 0;
}

ul {
  text-align: center;
}

li {
  display: -moz-inline-box; /* Firefox 2 以下用。 */
  display: inline-block;
  /* 内容の幅が大きいとき自動的に自分の幅も広がるよう、width ではなく
   * min-width を用いる。Firefox 2 以下では -moz-inline-box な要素の
   * min-width がボーダーボックスの最小幅として解釈されてしまうが、
   * ここではボーダー、パディングの幅が 0 なので影響しない。
   */
  min-width: 3em;
}
/* IE 6/7 では、デフォルトで inline でない要素は inline-block を
 * 指定した後、さらに inline を指定しないと inline-block 表示にならない。
 * margin をつけるのは inline-block 間の空白文字が表示されないため。
 */
* + html li {
  display: inline;
  margin: 0 0.2em;
}
* html li {
  display: inline;
  width: 3em; /* IE 6 は min-width 非対応だが width で代用可。 */
  margin: 0 0.2em;
}

li a {
  display: block;
  border: 0.1em solid;
  /* Firefox 2 以下でマージンボックスの幅が包含ブロック (この場合は
   * -moz-inline-box な要素の内容ボックス) の幅いっぱいに広がるように。
   */
  -moz-box-flex: 1;
}
/* IE 6 でボーダーボックス全体がリンクとして機能するように。 */
* html li a {
  height: 0;
}

この方法の利点として、-moz-inline-box な要素の幅が % 単位で指定されていても内容の幅がそれに追従してくれるといったことが挙げられます。

ちなみに、IE 7 以下での inline-block 表示に display: inline; zoom: 1; を用いず、いったん inline-block を指定して別の規則で inline を指定していたり、ひとつの規則内に _width: 3em; /margin: 0 0.2em; とまとめて書くのではなく、* + html ... { margin: ...; } * html ... { width: ...; margin: ...; } と IE 用の規則に分けて書いていたりするのは、できるだけ CSS の書式に則りたいという個人的な趣味によるものです。

MacIE 5 にも対応しようとすれば IE 6/7 向けの指定を /*\*/ ～ /**/ で囲む必要があるのかもしれませんが、確認できる環境がないのでそこまではしていません。Firefox 2 もすでにサポート期限が切れているので、最低限リンクが機能すればレイアウトが期待通りでなくてもかまわないという姿勢もありでしょう。

この例では -moz-inline-box な要素の子要素がブロック要素だったので子要素に -moz-box-flex を指定しましたが、Takazudo Clipping* のサンプルのように -moz-inline-box な要素の内容がテキストノードだったりインライン要素だったりした場合には、-moz-inline-box な要素に -moz-box-pack: center; を指定することで内容を中央ぞろえにできます。

このように、inline-block 表示はちょっと無理をすれば大抵のブラウザで可能ですが、別に無理をしなくてもいいときもあります。ページ送りに関していえば、各項目の幅をそろえなくてもいい (「1」の項目と「10」の項目の幅が異なってもいい)、かつ項目内で行の折り返しが発生してもいい (または内容が数字だけなので折り返しが発生しない) というのなら、そもそも inline-block を使う必要がありません。(IE 6 での不具合を避けるために inline-block を指定することはあるかもしれませんが。)

なお、zoom: 1; という指定はいわゆる CSS ハックの一環として用いられることが多いですが、このときそのまま zoom: 1; と書いてはいけません。/zoom: 1、_zoom: 1、* html ... { zoom: 1; } など、必ず IE のみに適用されるような書き方をしましょう。これは、WebKit も zoom プロパティをサポートしており、そうしたハックを必要としないブラウザに想定外の影響を与えるのを防ぐためです。もちろん、実際にズーム効果を求めて zoom プロパティを使用する場合はこの限りではありません。

rect 関数の書式

CSS の clip プロパティに rect 関数を指定することで、絶対配置の要素の一部だけ切り抜いて表示できます。rect 関数の引数には切り抜く矩形の各辺の位置を示す値を指定しますが、各引数の区切り文字には注意が必要です。CSS 2 だと、本文中ではスペース区切りなのにサンプルではコンマ区切りになっています。CSS 2.1 だと本文もコンマ区切りに統一され、製作者はコンマ区切りを使うべきであり、ユーザーエージェントはコンマ区切りをサポートしなければならないが、同時にスペース区切りをサポートしても良いということになっています。実際は IE 7 以下がスペース区切りしか受け付けてくれないので、スペース区切りを使うことになるでしょう。

このほかにも clip プロパティと rect 関数の挙動は CSS 2 と CSS 2.1 とで大きく変化しており、「clip CSS 表示と配置 (World Wide Web Guide)」に詳しくまとめられています。

getComputedStyle と currentStyle の違い

ある要素の実際の CSS プロパティの値を調べるのに、IE 以外のブラウザでは getComputedStyle メソッドが、IEでは currentStyle プロパティが使えます。しかし、この両者から得られる値は、前者が使用値 (used value) であるのに対し後者が指定値 (specified value) であるという違いがあります。二つの値に関しては以下の文書が参考になります。

JavaScript から CSS の値を操作するときは、指定値よりも使用値を得られたほうが嬉しい場面が多い気がします。

イベントハンドラ内容属性とスコープ

HTML 要素の属性としてイベントハンドラを記述した場合、そのイベントハンドラを実行する際のスコープにはその要素を表す DOM 要素ノードオブジェクト (これは this から参照できる値でもあります) が含まれます。this.value と書く代わりに単に value と書いても同様に動くということです。サイ本にはこうした動作に関して何も標準が存在しないと書かれていますが、HTML 5 草案ではイベントハンドラを実行する手順が明文化されています。

IE のメモリリーク

IE のメモリリーク問題は、IE 6/7 で部分的には解決されました (IE 6 は更新プログラムを適用した場合)。「部分的」という理由は以下の記事で解説されています。

IE 8 では COM という基盤技術に手を入れることで循環参照によるメモリリーク問題を根本的に解決したようです。

雑感

ブラウザ上で何かしようとするとネックになってくるのが IE の存在です。CSS に関しては IE 8 で大きく前進しましたが、イベントモデルをはじめとする DOM 周りはいまだ独自路線のままです。IE 9 でこれらの点が改善され、Range や XPath といった高度な機能を手軽に扱えるよう、Web 開発者の一人一人が積極的に発言し Microsoft に声を伝えていく必要があると思います。

ちなみに、今回の範囲である DOM Events や DOM Style については、WEB+DB PRESS Vol. 46/47 の連載『JavaScript + ブラウザ探検』でも解説しています。よろしければそちらもご覧ください。

改名します

Wed, 01 Apr 2009 00:18:28 +0900

私は普段テキストエディタに Emacs (正確には Meadow) を使っているのですが、nanto_vi という名前のせいか vi 使いに間違えられることが多く、先日も人に挨拶しようと思ったら「僕は Emacs 派なんで」と握手を拒否されてしまいました。ただ静かにエディタを使っていたいだけなのに、このようないわれなき差別を受けるのはもうこりごりです。争いのない平和な世界のためにいいエディタはないかと探していたところ、TeraPad というエディタの存在を思い出しました。

TeraPad は何よりもアイコンが優れており、今でこそやや古さを感じさせるものの、Windows 2000 のころには一番 Windows にマッチするアイコンのエディタといっても過言ではありませんでした。GUI アプリケーションにとってアートワークは命であり、アイコンが漢字一文字だったりした日にはどれだけ機能に秀でていようと使いたくなくなります。以後 vi 派と Emacs 派の宗教論争という古き時代から決別し、グラフィカルな未来へと邁進するという意志をこめ、名前を nanto_terapad と改めます。名前は変わってもブログの更新頻度は変わらないと思うので、今後とも気長にお付き合いしていただければ幸いです。

なんか仲直りできたっぽいんでやっぱ改名はなしで。