» Web 開発

Firefox 16 のサイト互換性に関わる修正のまとめ

Firefox 16 の正式版が今日 深夜にリリースされる予定です。可能な限り互換性を維持するよう開発されましたが、他のブラウザとの相互運用性や最新 Web 標準仕様への準拠のため、後方互換性に関わる修正も含まれます。そのような修正点をまとめましたので、動作検証時などにご参照ください。

ここでは後方互換性に影響し得る修正のみ解説します。その他の新機能や変更点については次のページをご覧ください。

この一覧に漏れや間違いがあるときはコメント欄でお知らせください。

CSS

多くの CSS プロパティから接頭辞が外れました

CSS アニメーショントランジショントランスフォーム の各プロパティから -moz- ベンダー接頭辞が外れました。また グラデーション の各関数と calc からも接頭辞が外れました。グラデーションについては、接頭辞の有無で構文が大幅に変わっていることに注意してください

接頭辞付きのプロパティや関数を使用する場合は、前方互換性のため、接頭辞なしの形式も必ず併記するようにしましょう。今後、そうした配慮がなされていない CSS は適用されなくなる可能性があります。

トランジションとアニメーションの継続時間に指定した負の値は無視されるようになりました

transition-durationanimation-duration の各プロパティに負の値を指定した場合、従来は初期値の 0s と解釈されていましたが、今後は不正な値として見なされ、宣言自体が無視されます。

matrix() に指定した長さの値は無視されるようになりました

トランスフォーム関数matrixmatrix3d について、Firefox はこれまで誤って数値だけでなく長さの値 (例えば 10px のように単位の付いた値) を受け入れていました。この挙動が仕様に合わせて修正され、長さの値が指定された場合はパースエラーを返すようになりました。

ボーダーによってテーブルセルの高さが変わる問題が修正されました

これまで、テーブルセル (td 要素) の上下に borderpadding が指定されると、その分セルの高さが縮まって表示されていました。Firefox 16 では、CSS 標準に従うよう、このレイアウト問題が修正されています。実際の例はバグに添付されたテストケースを参照してください。

メディアクエリの解像度が CSS ピクセル単位で扱われるようになりました

CSS3 メディアクエリの仕様が更新され、解像度の単位である dpidpcmdppx が、物理単位ではなく CSS ピクセル単位のドットに相当するようになりました。Firefox の実装もこれに合わせて更新されました。

DOM

いくつかの API から接頭辞が外れました

IndexedDB から接頭辞が外れました。今後は mozIndexedDB ではなく標準の indexedDB オブジェクトを使用できます。また、バッテリー、バイブレーターの各 API についても接頭辞が外れています。

Microdata API が実装されました (10/15 追記)

HTML5 の Microdata DOM API が実装され、documentgetItems プロパティが、elementitemIditemPropitemRefitemScopeitemTypeitemValueproperties プロパティが追加されました。

Six Apart 社から提供されている Movable Type がこの影響を受けたことが確認されています。各要素に itemId という独自プロパティを付加していたために一部機能が正常に動作しなくなり、急遽パッチが公開されています。

各要素に独自データを付加したい場合は、独自プロパティの代わりに element.dataset を使う方法が安全でしょう。文字列型以外のデータも保存できる setUserData/getUserData も Firefox には実装されていますが、これらは 廃止予定 であり、WeakMap で代用可能とのことです。

java オブジェクトが廃止されました

window.javawindow.packages の各グローバル DOM オブジェクトが廃止されました。これらのオブジェクトはほとんど文書化されておらず、実際に使われることは非常にまれかと思います。この変更は Firefox 15 で行われる予定でしたが、既存の拡張機能との互換性を保つためバックアウトされていました

SVG と XPath の例外の種類が DOMException に統一されました

SVGExceptionXPathException は削除され、DOMException に置き換えられました。

SmsRequestDOMRequest に置き換えられました

SmsRequest は、より一般的で同じ属性とイベントハンドラを提供する DOMRequest に置き換えられました。

select.size に負の値を指定した場合の挙動が変わります

select 要素の size プロパティに負の値を与えた場合、従来は例外が投げられていましたが、今後は 0 と見なされます。

CSSNameSpaceRule.type が正しい値を返すようになりました

CSSNameSpaceRuletype プロパティが、CSSRule.UNKNOWN_RULE (0) ではなく CSSRule.NAMESPACE_RULE (10) を返すよう修正されました。

mozApps.installPackage が無効化されました

Apps API の installPackage 関数は、機能の実装が完了するまで削除されることになりました。

その他

MD5 アルゴリズムで署名された証明書は受け入れられなくなります

MD5 ハッシュアルゴリズムは安全でないことから、Firefox 16 以降無効化する措置が取られました。MD5 アルゴリズムで署名された SSL 証明書を使用しているサイトを Firefox で開くとエラー画面が表示されます。便宜的に、ユーザがこのエラーを無視することも可能となっています

なお Thunderbird でも同様に、メールサーバがそうした証明書を使用している場合はエラーとなり、メッセージの送受信を行えなくなります。ただし Thunderbird 16 では何もエラーメッセージは表示されません。

ユーザエージェント文字列にセキュリティパッチレベルのバージョンまで含まれなくなります

この変更により、例えば予定外の Firefox 16.0.1 がリリースされた場合も、ユーザエージェント (UA) 文字列内のバージョンは 16.0.1 ではなく 16.0 とだけ表記されます。

半角空白の後、全角空白の前で行が折り返されるようになりました

実際の日本語のページについて「Firefox のみレイアウトが崩れる」と指摘があった問題です。他のブラウザと同様に、全角空白の前で行が折り返されるよう修正が行われました。

WebSockets の接続切断処理が最新仕様に合わせて更新されました

コードから close 関数が呼び出された際の切断処理中に onerroronclose イベントが発生しないようにするなど、最新の WebSockets 仕様に合わせて実装が更新されました。

execCommand() はコマンドが無効の場合 false を返すようになりました

リッチテキストエディタexecCommand 関数が呼び出された際に、コマンドが有効でなければ正しく false を返すようになりました。これまでは常に true が返っていました。

メディアを巻き戻したときの played プロパティの値が修正されました

video/audio 要素を再生し、巻き戻した後に played プロパティの値を取得すると、巻き戻した位置が返っていました。再生が終わった位置を正しく返すよう実装が修正されました。

リグレッション

Firefox 16 で発生したことが判明しているリグレッションのうち、サイト互換性に影響すると思われるバグは以下の通りです。

以前のバージョンについて

以前のバージョンについても同様に、後方互換性に関わる修正点をまとめています。

JavaScript でメディアクエリを行う window.matchMedia の使い方

原文: Using window.matchMedia to do media queries in JavaScript (on June 5, 2012 by Robert Nyman)

Web サイトを構築する人々にとって、レスポンシブ Web デザイン で、可能な限り多くのユーザがコンテンツを利用できるようにすることが自然なアプローチになってきました。これには CSS メディアクエリ が使われますが、JavaScript でも同じことができます。

window.matchMedia の紹介

JavaScript でメディアクエリを利用するには、window.matchMedia を使います。基本的には CSS で行うのと同じことを、JavaScript コールで行います:

var widthQuery = window.matchMedia("(min-width: 600px)");

このクエリは、MediaQueryList オブジェクトを返します。このオブジェクト上では、次のことができます:

matches
クエリがマッチするかどうかの真偽値。
media
シリアライズされたメディアクエリのリスト。
addListener
イベントリスナをメディアクエリに追加する。値のポーリングなどよりも優先される。
removeListener
イベントリスナをメディアクエリから削除する。

メディアクエリがマッチするかどうか簡単に調べるには、matches プロパティを使います:

var widthMatch = window.matchMedia("(min-height: 500px)").matches;

リスナを追加するのはとても簡単です:

function getOrientationValue (mediaQueryList) {
    console.log(mediaQueryList.matches);
}
 
portraitOrientationCheck = window.matchMedia("(orientation: portrait)");
portraitOrientationCheck.addListener(getOrientationValue);

デモとソースコード

window.matchMedia のデモ で、いくつかのクエリの動作を確かめられます。ウィンドウをサイズ変更して値がどのように変わるか見てみてください。

このデモの完全な JavaScript コードは、GitHub にも置いてあります:

(function () {
    var matchMediaSupported = document.querySelector("#matchmedia-supported"),
        width600 = document.querySelector("#width-600"),
        height500 = document.querySelector("#height-500"),
        portraitOrientation = document.querySelector("#portrait-orientation"),
        width600Check,
        height500Check,
        portraitOrientationCheck;
 
    if (window.matchMedia) {
        matchMediaSupported.innerHTML = "supported";
 
        // Establishing media check
        width600Check = window.matchMedia("(min-width: 600px)"),
        height500Check = window.matchMedia("(min-height: 500px)"),
        portraitOrientationCheck = window.matchMedia("(orientation: portrait)");
 
        // Add listeners for detecting changes
        width600Check.addListener(setWidthValue);
        height500Check.addListener(setHeightValue);
        portraitOrientationCheck.addListener(setOrientationValue);
    }
 
    function setWidthValue (mediaQueryList) {
        width600.innerHTML = mediaQueryList.media;
    }
 
    function setHeightValue (mediaQueryList) {
        height500.innerHTML = mediaQueryList.matches;
    }
 
    function setOrientationValue (mediaQueryList) {
        portraitOrientation.innerHTML = mediaQueryList.matches;
    }
 
    // Setting initial values at load
    function setValues () {
        width600.innerHTML = width600Check.matches;
        height500.innerHTML = height500Check.matches;
        portraitOrientation.innerHTML = portraitOrientationCheck.matches;
    }
 
    window.addEventListener("DOMContentLoaded", setValues, false);
})();

Web ブラウザのサポート

この記事の執筆時点で、window.matchMedia は次のブラウザに実装されています:

  • Firefox 6 以降。
  • Google Chrome 9 以降。
  • Safari 5.1+。注記: addListener はサポートしていません。
  • モバイル版 Firefox
  • Android 版の Google Chrome ベータ。注記: addListener はサポートしていません。
  • iOS 版の Safari 5。注記: addListener はサポートしていません。
  • Android ストックブラウザ。注記: addListener はサポートしていません。

Internet Explorer 10 でのサポートも計画されています。

古い、サポートしていない Web ブラウザでは、matchMedia() polyfill を試してみてください。ただし、addListener はサポートしていません。

Archive API experimental implement rev.2012.07.28.

Mozilla Hacks よりも先に解説記事を書けました。

概要

10日ほど前に 772434 – Blob support for Zip file contents のパッチが mozilla-central に投入され、DOM File API 経由で取得した zip 形式のアーカイブファイルの取り扱いを行うための API、Archive API が試験的に実装されました。このAPI は最新の Firefox Nightly 17 で試すことができ、このまま何事もなければ 年末にリリースが予定されている Firefox 17 にも載ると予測されます。

今回の Archive API の試験実装は、 今年 7月 17日に Andrea Marchesini によってwhatwg の ML にて提案されたもの( [whatwg] Archive API – proposal )を実装したものになります。

API

今回の試験実装によって、Gecko に以下のインターフェースが実装されました。

使い方の流れとしては以下のようになります

  1. 取得した zip ファイルの Blob または File オブジェクトを ArchiveReader コンストラクタに渡してオブジェクトを生成
  2. 生成した ArchiveReader オブジェクトのメソッドを呼び出して ArchiveRequest オブジェクトを取得
  3. 取得した ArchiveRequest に、操作の完了時に呼び出すイベントハンドラを設定

コード的には以下のようになります。

// ArchiveReader のインスタンスを生成
var reader = new ArchiveReader(file);

// 格納されたファイル名一覧の取得
var requestFileList = reader.getFilenames();
requestFileList.onsuccess = function (event) {
  var request = event.target; // this を使っても良い
  var fileList = request.result; // 配列でファイル名の一覧が返ってくる
  console.log(fileList);
}; 

// 格納されたファイルの取得
var requestFile = reader.getFile("hoge/sample.txt"); // zipファイル内でのパスを指定
requestFile.onsuccess = function (event) {
  var request = event.target;
  var file = request.result; // File オブジェクトが返ってくる
  console.log("file name" + file.name);
  console.log("file type" + file.type);
  console.log("file size" + file.size);
};

サンプル

筆者が作成した zip ビューアのサンプルコードへのリンクを以下に記します。

Archive API sample for Firefox Nightly 17 — Gist

テキストファイルのエンコード判別が未実装であったりと、色々と雑な作りとなっています(申し訳ありません)。実行の際には注意をお願いします。

現在の実装における注意点

現在の実装は試験的なものであるため、各所にバグ・考慮漏れと思われる挙動が散見されます。上記のサンプルコードの作成を通じて、筆者が発見したものを以下に挙げます。

パスワードをかけた zip ファイルを渡した場合、ファイルの MIME タイプが application/x-javascript となる

アーカイブファイル内の構成(格納されているファイルのパス名など)までは読み込むことが可能ですが、ファイル自体の展開は不可能です。

アーカイブされたファイルの名前の文字コードが utf-8 以外の場合、2 byte 文字のファイル名を正しく扱えない

  • そのような zip ファイルを開いた場合、ArchiveReader.getFilenames() で取得したファイル名の一覧は空文字列の要素の配列になっているように見える(それらの配列の要素は、直接 ArchiveReader.getFile() にパスとして渡した場合にファイルの取得はできるが、文字列として取り扱うことはできない )。
  • 同様の zip ファイルを開いた場合、ArchiveReader.getFile() にパスを文字列で指定すると、パスが 2 byte 文字の場合はファイルを取得できない

アーカイブされたファイルのサイズが大きい場合(画像・音声・動画など)、ArchiveReader.getFile() を経由したファイルの展開が途中の状態のまま処理が完了してしまう(ArchiveRequestsuccessイベントが発行される)

  • 取得したファイルの Blob から window.URL.createObjectURL() すると、ファイルの読み込みが途中のまま
  • FileReader.readAsDataURL() を介した場合、生成された dataURI が中途半端なところで切れている旨の警告が表示される
  • ArchiveRequest.onload() で回避できるのではないかとおもったが、load イベントが発行されないためハズレ

780145 – ArchiveReader doesn’t unzip large files が修正され、最新の Nightly では、大きいファイルもちゃんと展開されるようになりました。

まとめ

現在の実装は非常に試験的なものであり、今後、どのような形に API および実装が落ち着いていくかは不透明ではありますが、手軽に zip アーカイブファイルを使用できるようになる可能性が示されたため夢は広がります。Archive API の提案がなされたメールアーカイブでは導入理由として「ゲームの開発のため」と書かれていますが、ゲームに限らず、epubのようなzip形式のコンテナを使用しているフォーマットのビューアの実装や、「複数のリソースファイルを1つに集約して通信をおこなうことによるリクエスト数の軽減」「ファイルを zip で圧縮することによる通信料の軽減」などのテクニックとして取り扱えることが期待できます。

反面、zip アーカイブされたファイルをクライアント上で展開させるという根本的な仕組みから、要求されるメモリ量も大きなものとなりますが、仕様の安定化および実装の普及までの時間がハードウェア性能の向上というかたちで解決してくれるものと前向きに期待しましょう(笑)

MDN が新システムに移行しました

米国時間 8/3 午前 10 時過ぎ(日本時間 4 日 午前 2 時過ぎ)に、MDN の技術ドキュメント Wiki のシステムが新システムに移行しました。

今までは、DekiWiki という Mozilla 外部のシステムを使っていましたが、新システムは Kuma と呼ばれる、Mozilla 内製のシステムになりました。

ドキュメント翻訳のための機能として大きなものは、翻訳版と英語版との紐付けがシステム側で行われるようになったことです。新しい翻訳方法については、MDN 日本語版の翻訳についてのドキュメントを参照してください。

Kuma は SUMO のシステム Kitsune を元にしているものの、まだ実装の足りない部分や解決されていない不具合があります。主なものは、Mozilla 翻訳フォーラム内の Kuma の既知の問題を参照してください。

未知の不具合に遭遇したときは、MDN サイト右上のバグ報告ボタンから、Bugzilla に報告してください。

英語での報告が難しい場合は、翻訳フォーラム、あるいは、MDC 日本語版 MLへ報告してください。Twitter ユーザであれば、MDN 日本語版リーダー宛 (@potappo)にリプライやメンションを飛ばすのでもかまいません。

MDN 日本語版も、新システムになっても引き続き、コンテンツの充実を目指していきたいと思いますので、興味のある方はぜひ翻訳にご参加ください。

Firefox for Android をリモートデバッグ

Android 版の Firefox 14 以降にはリモートデバッガ機能がサポートされており、PC 版の Firefox 15 以降と組み合わせることでモバイル Web サイトをリモートデバッグできるようになっています。リモートでバッグをするまでの手順を簡単に説明しますので、興味のある方は是非お試しください。

デバッグ環境の準備

Android 端末に Firefox 14 または Firefox 15 Beta をインストールし、Android の設定で USB デバッグを有効にしてください。Android 2.x であれば Android 設定 → アプリケーション設定 → 開発 → USB デバッグで設定できます。

PC 側では Android SDK および Firefox 15 Beta 以降をインストールしてください。Android SDK を使うには、Windows であれば端末に応じた デバイスドライバが必要になることや、~/.android//adb_usb.ini ファイルにサードパーティベンダー ID の記載が必要なことがあります (本来は manifest.ini を書くべきだという話もあります)。

SDK のインストールができたら、USB 接続して次のコマンドで Android 端末を認識できているか確認してください。

adb devices

接続した端末が表示されるようになれば準備は完了です。

リモートデバッガの接続手順

リモートデバッガを有効化

Android と PC 両方の Firefox でそれぞれ about:config ページを開いてください。ページ上部の検索バーに “debugger” と入力して絞り込み、devtools.debugger.remote-enabled という真偽値の設定を見つけ、true に切り替え、Firefox を再起動してください。

Android 端末を USB 接続し、次のコマンドで端末側のポートと PC 側のポートを中継させてください。

adb forward tcp:6000 tcp:6000

あとはデバッグしたりソースを確認したいページを Android 版の Firefox で開き、PC 版の Firefox で「開発者メニュー」 → 「リモートデバッガ」を選択してください。接続するホスト名とポート番号を入力するように求められますが、remote.debugger.port などの設定を変えたりしない限り、デフォルトの 「http://localhost:6000/」 で問題ありません。

接続できたらリモートデバッガウィンドウにソースが読み込まれるので、いつも通りファイルを選択、ブレークポイントを設定し、デバッグしてください。ステップ実行、コールスタックの確認、各タックでの変数の確認、変数の書き換えなど基本的なデバッグ機能は揃っています。

モバイル Web アプリをデバッグ


ブレークポイントを設定

なお、現時点の Android 版 Firefox 16 Aurora および Firefox 17 Nightly にはバグがありリモートデバッグできません(PC 版は問題ありません)。いずれ修正されますが、それまでは安定動作するバージョンでテストしてください。

Enjoy Remote Debugging!

pdf.js:PDF を HTML5 と JavaScript で表示する

原文:pdf.js: Rendering PDF with HTML5 and JavaScript | Andreas Gal

原文投稿日: 2011年6月15日

なぜ?

ソウルと台北での Firefox 4 リリースパーティーからカリフォルニアに戻る間に、私達はウェブプラットフォームでどんな事ができるかについてのクールなブレインストーミングで多くの時間をつぶしました。私達以前にそう考えた人は何人もいたでしょうが、私達はなぜ誰も HTML5 と JavaScript で PDF リーダーを実装しないのだろう、と疑問に思いました。PDF リーダーに必要とされる動作は、素早くテキストをレンダリングし、直線を描画し、画像を転送する事、そしてブラウザー上でも素早く表示する事です。ブラウザーはすでにこれらの作業に対して高度に最適化されているのです。

HTML5 に基づく PDF レンダラーを作る事ができれば、ウェッブプラットフォーム、特に canvas と SVG の API が PDF を効率的かつ忠実にレンダリングできるだけの成熟度を持っているか、という疑問への回答にもなります。

PDF をブラウザー内で表示する事は、ユーザー体験を確実に向上させるでしょう。ウェブには文字通り数百万の(数億の?) PDF が存在しており、多くのデバイスにおいて、PDF を読み込む際には異なったアプリケーションへの変更(例えば、OS X では Preview、Android では PDF View)が行われます。また、外部 PDF リーダーと多くのプラグインは、重要な PDF の機能、例えばコンテンツ内のリンクや fetch-as-you-go (HTTP の範囲リクエスト)などを充分にサポートしていません。

外部リーダーとプラグインは、独自の UI パラダイムを再発明しなければならず、その結果、例えばブラウザーで HTML ページをスクロールする方向と PDF リーダーでページをスクロールする方向が逆になるという事態が生じるのです。

私達は、HTML5 とは違って、PDF を ウェブの第一級市民として広めようとしているのではない、という事は特筆しておきます。私達が望んでいるのは、ウェブプラットフォーム上で作られたブラウザーネイティブな PDF レンダラーが、PDF を包含するウェブ技術になる事です。

利点

ブラウザーで PDF をレンダリングするには、ネイティブコードのプラグインを使用するのが通例でした。これは、Adobe 自身の PDF リーダーであっても、Adobe 以外の商用レンダラーであっても、あるいはオープンソースのもの(例えば Poppler)であっても同じでした。セキュリティの観点からすると、これは信頼されたコードベースを拡大する事であり、そのために Google の Chrome ブラウザーはコード・インジェクション攻撃を避けるために PDF レンダラーをサンドボックス化するという手間を強いられています。HTML5 に基づく実装なら、この種の問題が発生する事はありません。

プロジェクトの現状

私達は pdf.js の開発を、(github.com で)オープンにではあってもひっそりと、約1ヶ月の間、続けてきました。いくつかの大きな機能(Type1 フォントや、グラデーションなど)が完成してから、pdf.js についてより広くお知らせしようと考えていたのです。私達の作業がすぐに捕捉され、強い興味が示された事に、私達は驚きました。それで私達は、当初の予定よりも早くこの計画をブログで公開する事にしたのです。

私達のプロジェクトプランの一つとして、私達は、2009年の ACM SIGPLAN PLDI カンファレンスで行った Trace Compilation に関する論文 (訳注:リンク切れのようですが、後述される デモページ の文書と思われます)をピクセル単位で忠実にレンダリングする事を目標としています。この論文で述べられている Tracemonkey の作業によって JavaScript の JIT への道が開かれました。私達は pdf.js によってウェブプラットフォーム上にレガシーなフォーマットを実装するための扉が開かれるものと期待しています。

pdf.js のデモをご覧になりたいのであれば、この リンク をクリックして下さい。不具合や不自然なレンダリングもあるでしょうが、おおまかな所はご理解いただけると思います。Type1 の PostScript フォントはまだ実装されていませんが、Vivien Nicolas が作業中です。

この先、私達は HTML5 の canvas 要素に新たなインターフェースをいくつか追加しなければならず、PDF のスペックにある難しい機能を JavaScript で実装する方法を見つけなければなりません。技術的な概観については Chris の 記事 を、「シェーディング・パターン」のレンダリングに関する詳細は Shaon の 記事 を参照して下さい。

次には何が?

私達は、pdf.js によって、Firefox 内で「ネイティブに」 PDF をレンダリングするつもりです。直近の目標は、最もよく使われる PDF の機能を実装し、ウェブにある PDF の大多数を表示できるようにする事です。この目標には3ヶ月以内に到達できると考えています(現在のコードができるまでにかかった期間は1ヶ月弱であり、すでにかなりの数の PDF 機能をレンダリングする事ができています)。

まず、pdf.js を使用してインラインの PDF レンダリングを可能にする拡張機能を作成して、興味を持ったユーザーに提供するのが最初になるでしょうが(訳注:拡張機能は PDF Viewer として公開されています)、私達の最終的な目標はもちろん pdf.js を Firefox に同梱する事です(訳注:翻訳時で Firefox 15 のベータ版に同梱されています)。ユーザーにとっては、利便性が向上するばかりでなく、セキュリティの面でも改善になります。pdf.js は安全なウェブ言語しか使用せず、攻撃者が脆弱性を突けるようなネイティブコードは一切使用していません。

オープンソース

私達は pdf.js をコミュニティによって運営されるオープンソースのプロジェクトにしたいと思っています。Firefox には使用しますが、他にも多くのクールなアプリケーションがあるでしょう。Firefox 以外のブラウザーやウェブアプリケーションに組み込まれるのを見てみたいと思っています。標準に準拠したウェブ技術だけで書かれているので、標準に準拠したブラウザーであればコードは動作する筈です。ライセンスは非常にリベラルな三条項 BSD ライセンスであり、外部からの貢献者も歓迎します。pdf.js を改善するあなたのアイディアやコードを期待しています! github あるいは 私達の wiki に目を通すか、 IRC の #pdfjs で私達にご連絡ください。

Chris Jones と Andreas Gal (そして pdf.js チーム)

HTML5 と HTML.next

Hixie が WHAWG のニュースグループに投稿したことを切っ掛けとして再び HTML5 およびその先の標準化について注目が集まる中、HTML5 仕様策定に関する最新の状況について W3C Blog に書かれた記事です。公式ブログの記事らしい落ち着いたトーンで書かれています。
誤訳の指摘はコメント欄や Twitter で @dynamitter 宛にお願いします。

原文: W3C BlogHTML5 and HTML.next

HTML5 は現在 Web コミュニティが築いているオープンな Web プラットフォームの要となるものです。今週は私たちの取り組みを加速する重要なことが W3C で 2 つありましたが、それについて幅広い Web コミュニティの皆さんに知っていただくと同時に、HTML についての最新状況をお伝えしたいと思います。

始めに背景をお話しすると、4月に HTML ワーキンググループの議長達 —Paul Cotton (Microsoft)、Sam Ruby (IBM) と Maciej Stachowiak (Apple)— と HTML5 のエディタ —Ian Hickson (Google)— は仕様の編集範囲を変更する必要があると結論づけました。また同時に、HTML5 「勧告」まで持っていき「.next」つまり HTML5 の次に来る仕様に向けた作業を始める必要があると確認しました。Ian は既に後者に取り組んでおり、彼は議長達に HTML5 を勧告に持って行くための新しいエディタを選ぶよう頼んだのです。

そして 4月の終わりに、議長達は HTML ワーキンググループに別のエディタを探すと共に今後の作業においても WHAT WG との協力関係を続けていくと告知しました。また、Ian はこの協力関係を強固なものとするため、W3C に WHAT コミュニティグループを設立しました。

今週は 2 つのことがありました。1 つ目は、2014 年に向けて HTML5 を 勧告とするため、W3C が仕様策定や相互互換性テストに必要となる職員を確保できるよう、Adobe、Google そして Microsoft が多くの資金を提供して頂いたということです。ワーキンググループの扱う仕様のサイズや数、広がり続ける Web 技術を実装するデバイスの種類 (パソコン、ノートパソコン、スマートフォン、電子書籍リーダー、セットトップボックス、などなど…)、テストに対する要求が大きくなってきているため、オープン Web プラットフォームのテストは空前の規模になることが予想されます。

2つ目は、HTML5 仕様を完成させるエディタチームにコミュニティから参加するメンバーを発表したことです。Travis Leithead、Erika Doyle Navara、Ted O’Connor 並びに Silvia Pfeiffer ですが、まだ増える予定です。私たちの会員からこのように時間と資金の援助を頂いたことで、私たちは HTML5 を先に進めていけると自信を持っています。また、私たちはワーキンググループがコミュニティの多くの皆さんと協力して次に来たるものにも注力していけることを嬉しく思います。Web 技術が生きた技術として成長を続けられるように。

2012-08-02 追記: HTML ワーキンググループの議長達は Canvas 2D Context の編集チーム も発表しました。

– 2012年 7月 26日 Jeff Jaffe

訳者コメント

Michael Smith さんも Google+ にも書いていましたが、何か驚いたり慌てたりするようなことが起きているわけではありません。かつて無い速度と規模で Web 技術が進化し続ける中で、進化と安定化の両立を図るための協力・調整が続いています。

「HTML5 が 2 つ分裂する」と心配される方もいますが、HTML4 から HTML5 で変わったところがあるように、HTML5 とその次でも Web で求められ使われる技術の変化に応じて変わっていくのは自然ではないでしょうか。変化が早いから同時進行になっているだけで、対立や分裂とは違うと思います。

心配しすぎることなく、進化を続けるオープン Web プラットフォームの未来に期待しましょう。(・・).

運営メモ: WHATWG の HTML Living Standard と W3C の HTML5 仕様との関係についての最新情報

若干テンション高めというかフレンドリーというかそんなニュアンスで訳しました。Hixie の意図するニュアンスとは異なる可能性がありますがご了承ください。
誤訳の指摘はコメント欄や Twitter で @dynamitter 宛にお願いします。

原文: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jul/0119.html

HTML 仕様策定にここ数年 W3C が参加していたのを無視してこれた人は読まなくてオーケー。大量のバグメールが飛んできたけど何でだ?と思った人は続けて読んでね。

当時僕らが公式には “Web Applications 1.0″、裏では “HTML5″ って呼んでた仕様について W3C と共同作業を始めたのは今から数年ほど前 (2007 年頃) だった。僕らは仕様の名前を “HTML5″ と変更し、W3C もそのコピーを公開するようになったんだ。すると程なく、W3C では標準をいくつかの標準に分割したから (つまり、2D Canvas API, Server-Sent イベント、postMessage とかにね)、WHATWG 側でもそれに合わせるよう努力してみたんだ。けれど複数バージョンの仕様があることで混乱し、結局 WHATWG 側では僕が担当するすべてをまとめた、1 つの仕様だけに戻すことにしたんだ。僕らが今 “HTML Living Standard” って呼んでるやつにね。それから数年、この文書と W3C 側のいろんな文書はちょっとずつフォークしていったんだ。WHATWG 標準の冒頭 (訳注: 多分ここのこと) で書いてるようにね。

最近になって、HTML 戦線における W3C と WHATWG の目標もちょっとずれてきた。WHATWG では HTML や関連技術の正確な説明を作り上げることに集中してきた、つまり、バグは見つけたらすぐ [1] 直し、新しい機能は必要になったり使えるようになったら追加し、実装も追いかけてきた。その間 W3C はご立派な W3C 標準化プロセスに従ってスナップショット作りにいそしんできたんだ。そして遂に W3C ワーキンググループの議長達と僕は作業を 2 つに分けることにしたんだ。W3C HTML5, Canvas, Microdata 仕様の執筆に責任を持つ人と WHATWG 仕様のエディタ (僕) は別にしようってね。[2]

W3C と一緒にやっていく中で、僕らは WHATWG 仕様右下のウィジェットで登録されたバグを W3C の Bugzilla システムで管理してきた。W3C は WHATWG 仕様に対して登録されたバグのホストを快く続けてくれていたんだ。これまで W3C と WHATWG の仕様を両方を一人のエディタが担当していたから両仕様のバグを 1 つにまとめて、僕は仕様は 1 つしかないかのように処理してこられた。でもフォークしちゃうと (訳注: エディタが別になると) それは続けられない。だから、W3C の Bugzilla システムで HTML 仕様に登録されていたバグをすべて取り出して複製したんだ。1つは W3C 用に、もう一つは WHAWG 用にね。僕は WHATWG のバグを扱っていき、W3C の新しいエディタ(達) [a] は W3C のバグを扱っていく。もし君が最近大量の “operation convergence” って書かれたバグメールを受け取っていたら、そういうことさ。具体的にどうなるんだってことはこのメールに続けて書くね。

僕にどんな影響があるの?

* WHATWG の仕様にフィードバックを送るなら、このメーリングリスト (whatwg@whatwg.org) に送ってくれるのが一番簡単だよ。

*WHATWG の仕様のバグを報告するなら、WHATWG 仕様に付いてるツールを使ってくれれば適切なコンポーネントを選んでくれる。

*W3C Bugzilla を直接使ったり WHATWG 仕様のバグを検索したいのなら、Bugzilla で “WHATWG” プロダクトを選択してくれ。僕が編集してる仕様のコンポーネントは “HTML” だよ。他のコンポーネントは Anne とか他のエディタが編集してる仕様のためのものだからね。

*Bugzilla にコメントを書いて僕に読んで欲しいのなら、僕に割り当てられてるバグにコメントしているか確認してね。”WHATWG” プロダクトじゃなくて “HTML WG” プロダクトのバグは HTML WG のエディタに割り当てられているもので、多分僕は見ないから。(もちろん僕も W3C 側の変更をできる限り追い続けるけど、個別のバグコメントまでは目を通せないと思うんだ。)

WHATWG HTML 仕様で現在未解決のバグはこのリンクで確認できる:

https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWG&component=HTML&resolution

フィードバックがどれくらい溜まってるか確認するには、僕はこのグラフを見てる:

http://www.whatwg.org/issues/data.html

“operation convergence” についての詳細:

これまでバグには2つのバケツがあったんだ。(“HTML5 spec” とかいろんなコンポーネントの) W3C 仕様に登録されたバグと、(“other Hixie drafts” コンポーネントの) WHATWG 仕様に登録されたバグがね。その殆どは僕に割り当てられ、コンポーネントなんて気にしてこなかった [3]。

僕は最近 W3C スタッフと協力して 2 つのスクリプトを走らせて、バグを全部複製したんだ。1つ目のスクリプトでは “HTML5 spec” コンポーネントにあったバグを選択して、複製したバグを WHATWG プロダクトに登録して僕に割り当て、元のバグは nobody に割り当てた。2 つ目のスクリプトでは “other Hixie drafts” コンポーネントにあったバグを選択して、”WHATWG” プロダクトに移動させ、”HTML5 spec” コンポーネントに複製し、nobody に割り当てた。今回 nobody に割り当てられたバグはそのうち W3C の HTML5 仕様エディタになる誰かに割り当てられることになるだろう。今後登録されるバグには何も影響しない。これから先に進むため、長期的な計画をどうしていくか、僕はこれからも HTML ワーキンググループの議長達と一緒に決めていく。古い “other Hixie drafts” コンポーネントは無くしたよ。

ここで書いたことは、4月にアナウンスした WHATWG は W3C コミュニティグループ になるって件とは関係ないんだけど、要するに、W3C の HTML ワーキンググループからは独立するけど W3C との協力関係は保たれるってことさ。[4]

最終的な結果としては、HTML Living Standard の策定作業が再び加速され、W3C ワーキンググループと共同作業を始める前のペースを取り戻せることを、僕は期待している。

質問があるなら、僕に直接メールするか、IRC チャンネル (Freenode の #whatwg)で聞いてね。技術的議論の S/N 比を保ちたいから、このメーリングリストでは仕様策定プロセスに関する議論はしないで欲しいんだ。

— 脚注 —
[1] あるいは、見つけてから数ヶ月後にね… 今僕は 6 ヶ月ほど遅れてる。ゴメンね。頑張るよ! (・・).

[2] http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html

[3] 詳しく書くと、僕は W3C HTML WG コンポーネントのバグについては “Accepted” や “Rejected” として閉じるブックマークレットを使っていた。HTML ワーキンググループのプロセスで要求される雛形があったからね。”other” コンポーネントのバグについては雛形なんて使わなかった。HTMLWG のプロセスを経る必要があるのは彼らのバグだけだったから。

[4] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Apr/0240.html

[a] 訳者追記: W3C 仕様のエディタについて、Canvas 2D などのエディタは未確定ですが HTML5 のエディタは Travis Leithead, Erika Doyle Navara, Ted O’Connor, Silvia Pfieffer になったようです: http://lists.w3.org/Archives/Public/public-html/2012Jul/0183.html

— Ian Hickson

訳者コメント

今回の件で「WHATWG と W3C が決別して HTML5 がフォークした!」と騒ぐ人もいるかと思いますが、そんな話ではありません。フォークって言葉を強調した記事に釣られないようにしましょう。

プロジェクトやツリー全体がフォークするのではなく、安定バージョンのブランチを切ってブランチ専用のメンテ担当者を割り当てましょうって話が進んでいて、バグ管理もトランクとブランチで分けるようになったんだと理解するのが正しいかと思います。普通の製品開発でも安定ブランチ作りますよね?

Hixie の期待通り再び HTML の仕様策定が加速され、Web がより魅力的なプラットフォームになることを期待しています。(・・).

Firefox 15 の主な新機能を紹介します

今週は Firefox 14 がリリースされ、続けて Firefox 15 のベータ版も公開されました。ベータ期間中は安定性や互換性の修正が行われるのみで、基本的には新機能は追加されません。Firefox 15 のリリースは 8/28 を予定していますが、機能がほぼ確定するベータ版リリースに合わせ一足先に主な新機能と改良点をご紹介します。

Firefox 15 の特長

Firefox ではメモリ管理が改善され、特にアドオンを使用したり長時間ブラウジングを続けたときのメモリ使用量が大幅に削減されたり、Incremental GC の実装によりゲームのアニメーションなどが滑らかになるなど、パフォーマンス面で大きな改善が行われています。また、HTML5 と JavaScript で実装した PDF ビューアを同梱し、ブラウザの中で直接 PDF を表示可能になりました (当面ベータ版のみデフォルト有効)。

Web 開発者向けには、JavaScript デバッガレスポンシブデザインビューレイアウトビューといった新しい開発者ツールが追加され、標準の開発者ツールだけで一通りの Web 開発が行える環境が整いました。Web 標準のサポートについては High Resolution Time, Opus 音声コーデックなどをサポートするほか、次世代 JavaScript で標準化予定となっている関数のデフォルトパラメータや Rest パラメータに対応しました。

前回のバージョンで生まれ変わった Android 版では、続けてタブレット版も生まれ変わります。機能面では標準ブラウザからブックマークと履歴をインポートできるようになったほか、ページ内検索やページ中のテキストコピーに再対応したり、タブの操作性を改善したりするなど要望の多かった機能を実装しています。Web 開発者向けには近接センサーや光センサーのイベントに対応し、新しい Web アプリケーションを開発できるようになりました。

ユーザ向けの新機能・改良点

メモリ管理が改善されます

Firefox ではメモリ管理を改善し、一部のアドオンを使っていると長期間ブラウジングを行っているとメモリ使用量が増加し続ける問題を解決します。

一部のアドオンはタブを閉じてもそのページで使用していたオブジェクトへの参照を維持し続け、メモリが解放されない問題があります。今回 Firefox ではアドオンがページ中のオブジェクトへの参照を保持し続けている場合でも、閉じたタブで使用してたメモリが解放されるシステムを実装しました。これにより例えば Firebug 1.9.1, PicPasso 1.0.1, LoL 1.5, Youtube rating preview 1.03, Enter Select 7, Link Resolve, AutoPager 0.7.1.4 などを使用しているとタブを閉じてもメモリが解放されなかった問題が解決しました。

Firefox 14 と 15 で SiteAdvisor 3.4.1 を使用して 151 ページを開いた状態と、150 のタブを閉じた後の使用メモリ量を比較すると、右の図のようにタブを閉じた後で使用しているメモリは以前の約 1/5 にまで減少していることが分かります。詳しくは MemShrink プロジェクトのレポートをご覧ください。

Incremental GC が実装されました

訂正: 問題が見つかり Firefox 15 ではデフォルト無効となりました。Firefox 16 からデフォルト有効になる見込みです。

Firefox 15 では JavaScript エンジンに Incremental Garbage Collection が実装されました。これによりゲームのように大量のデータを処理し続ける Web アプリケーションが高速かつなめらかに動作し続けるようになりました。

PDF ビューアが同梱されます (リリース版では無効設定)

これまで PDF ファイルは Adobe などが提供するプラグインまたは別のアプリケーションでファイルダウンロード後に表示していましたが、プラグインはしばしばセキュリティホールの原因となっているし、Mac OS などにはプラグインが提供されていませんでした。

そこで Mozilla では PDF を Firefox のエンジンで直接描画できるよう、HTML5 と JavaScript で PDF ビューアを実装する PDF.js プロジェクトを進めてきていました。今回の Firefox ベータ版からはこのプロジェクトの成果が Firefox ベータ版に組み込まれます。但し、この機能はまだ完全ではなく実験的なものであり、すべての PDF ファイルを完全に描画できるわけであはりません。しばらくの間は Firefox のベータ版や開発版でのみ有効にされ、リリース版では無効化されます。リリース版で有効化するには about:config で pdfjs.disabled=false と設定してください。問題を見つけたら バグレポートをお願いします。

PDF.js の実装についての詳細は Mozilla Vision 2012 での講演をご覧ください。

設定画面をタブ内に表示可能になります

Firefox の設定画面は別ウィンドウで開かれますが、タブの1つとして開くことが可能になります。about:config ページで browser.preferences.inContent 設定を true に設定すると設定画面が新しいタブで開かれるようになります。

Web 開発者向けの新機能・改良点

開発者ツールにデバッガ、レスポンシブデザインビュー、レイアウトビューが追加されます

Firefox 標準の開発者ツールに JavaScript デバッガ、レスポンシブデザインサイトの表示を確認するツール、要素を調査するときにボックスモデルのサイズを一目で確認できるビューが追加されます。

JavaScript デバッガではブレークポイントや例外で停止し、関数呼び出しスタック、関数スコープやグローバルスコープの変数などを確認や書き換えしながらステップ実行するといった、基本的な JavaScript デバッグ機能が実装されています。

ステップ実行時には更新された変数がハイライトされたり、configurable, enumerable, writable といった変数のプロパティをツールチップで確認できるなど便利な特徴もあります。一方で一般的なデバッガで提供されているが未実装である機能には、オブジェクトのプロパティ値変更を監視する監視点機能があります。監視点が必要な場合は Object.watch() を利用するか、Firebug などをご利用ください。

レスポンシブデザインビューでは、マルチデバイス対応のサイトを作る際に様々な画面サイズでの表示を簡単に確認できます。指定サイズのウィンドウで表示したときの結果を確認したり、画面を回転して縦横のサイズを入れ替えた表示もボタン 1 つで確認できます。

レイアウトビューは要素の CSS ボックスサイズ(width x height, margin, border, padding)をグラフィカルに表示するビューです。「要素を調査」するときにスタイルビューを開くと右下にレイアウトビューが表示されます。不要なときは右上のボタンをクリックすればレイアウトビューが折り畳まれ width x height だけが表示されます。

Firefox 15 での開発者ツール強化について詳しくは Hacks Blog の記事をご覧ください。Firefox 標準の開発者ツール全般についてまとめたスライドもあります。

High Resolution Time に対応します

High Resolution Time の Performance.now() に対応しました。これにより従来より正確に時間を取得、パフォーマンス測定などが行えるようになります。

Opus Audio Codec をサポートします

Firefox 15 では IETF で標準化が進められている Opus 音声コーデックをサポートします。このコーデックでは MP3, AAC, Ogg などといった既存のコーデックよりも圧縮率が高く、低帯域でも高音質な音楽や通話を実現できます。

Opus は <audio> タグではもちろん、開発版では実装済みの WebRTC の Media Capture and Stream で高速かつ低帯域で高品質な通話アプリケーションを実現するためにも使われます。詳しくは Hacks Blog の記事をご覧ください。

関数のデフォルトパラメータ、rest パラメータに対応します

次世代 JavaScript の標準である ECMAScript 6th で導入される予定の機能を順次実装しています。Firefox 15 では関数の引数定義に使用するデフォルトパラメータrest パラメータ に対応しました。

Device Storage API をサポートします

写真のギャラリーアプリケーションのように、ファイルを管理するアプリケーションのため Device Storage API を実装しました。ファイルなどバイナリデータの保存には IndexedDB と Device Storage API を用途に応じて使い分けることを提案しています。この機能は Firefox OS 以外では無効になっているため、PC や Android で試す場合には about:config ページで device.storage.enabled を true に設定してください。

な お、類似した目的で提案されている API として Chrome が実装する File System API がありますが、Web アプリケーション向けの API として最適ではないと考えており、今のところ Firefox での実装予定はありません。詳しくは Hack Blog の記事をご覧ください。

Android 版の新機能・改良点

タブレット版も生まれ変わります

Android 版 Firefox は先日ユーザインターフェイスをすべて書き直し、マルチプロセスからシングルプロセスマルチスレッドへと設計を変更し、Android のブラウザで最高のパフォーマンスを実現しました。この生まれ変わった Firefox はスマートフォン限定のリリースとなっていましたが、Firefox 15 ではタブレット版も生まれ変わって再リリースします。

標準ブラウザからのブックマークインポートに対応します

Android 標準ブラウザのブックマークと履歴をインポートできるようになりました。設定画面の一番下にある「Import from Android」という項目をタップして、インポートしたい項目を選択してください。

Firefox が「ブラウザの履歴とブックマークを読み取る」権限を必要とするようになったのはこの機能のためです。

ページ内検索やテキストのコピーに再対応します

Firefox 14 では大幅に高速化して生まれ変わったバージョンを皆さんにいち早くお届けするため、これまでのバージョンでサポートしていた機能が一部未実装になっていました。Firefox 15 では再びページ中のキーワード検索やテキストを範囲選択してコピーできるようになります。

ページ切り替えの操作性を改善します

生まれ変わった Firefox では片手でも操作しやすいように、右上から左下に右手親指で操作しやすいところにメニューやボタンが集められています。しかし、右上の開いているページ数をクリックしてページ一覧を表示したとき、各ページを閉じるボタンは左側にあってページを閉じる操作だけは右手親指ではしにくくなっていました。Firefox 15 では閉じるボタンも右側に移動させるだけでなく、開いているページ一覧で左右にスワイプすることでもページを閉じられるようになりました。

また、開いているページが 1 つだけのときには “+” を表示して、すぐに新しいページを開けるようになっていましたが、パソコンと同期しているタブ一覧にアクセスするには複数ページを開いている必要がありました。そのため Firefox 15 からは開いているページの数にかかわらず数字を表示し、タップするとページ一覧が開かれるよう統一されました。新しいページを開くときも同じ場所に表示される “+” を数字に続けてタップするだけで簡単です。

近接センサーや光センサーに対応します

Firefox では Web アプリケーションがネイティブアプリケーション同様、ハードウェアセンサーなどもフル活用できるよう Web API の実装と標準化をリードしています。Firefox 15 では当初 Sensor API として検討され、後に Proximity EventLight Event として標準化が進められている、近接センサーや光センサーを使用するイベント deviceproximitydevicelight に対応しました。

関連情報

以前のバージョンについて