» Web 開発

Firefox 24 & 25 サイト互換性情報

Firefox 24 のベータ版と Firefox 25 Aurora (プレベータ版) がリリースされました。それぞれのサイト互換性情報を投稿していますので、Web 開発者の皆さんはご確認ください。もし一覧に漏れや間違いがあるときは、下のコメント欄でお知らせいただければ幸いです。

さまざまなHTML5のプログラミングを公開中

ビジュアル表現における、さまざまなHTML5のプログラミングを公開しています。オープンで公平なFireFox OSの発展にささやかながらも貢献できればと思います。

HTML5.evagelist

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

先ほど Firefox 23 Aurora (プレベータ版) がリリースされました。Firefox 23 のサイト互換性情報を投稿しましたので、Web 開発者の皆さんはご確認ください。今回のバージョンでは、SSL 使用ページ内に混在している非 SSL コンテンツ (スクリプト、スタイルシート、動画など) が初期設定でブロックされるという点に注意が必要です。

なお、Firefox 22 (現在のベータ版) で予定されていた、初期設定でのサードパーティ Cookie のブロックは、事前に使用状況データの収集解析を行うため、延期されました。

もし一覧に漏れや間違いがあるときは、下のコメント欄でお知らせいただければ幸いです。

Firefox OS の課金アプリを作るには

原文: Building A Paid App For Firefox OS

Firefox OS の Firefox Marketplace をぱっと見たところでは Apple Store や Google Play と大差なく見えるかもしれないが、重要な違いがあります: あなたを Mozilla にロックインしたり、Firefox OS 端末にロックインしたりすることはありません。レシートプロトコルによって、どのオープン Web デバイスでも動作する Web アプリを販売できるようになります。Mozilla 以外のマーケットもレシートフォーマットを実装することで Firefox OS のアプリ販売に参加でき、ユーザは何処のストアで課金したアプリを使ってもその違いに気づくことはありません。

他のデバイスがレシートプロトコルを実装すれば、理論的には 一度買えば何処でも使える ようになります。もちろんこれは、鶏か卵かの問題であり、Mozilla は卵となって、分散的なレシートコンセプトを実証し、プロトコルの改善を続けます。Mozilla はレシートが正しく機能し、課金アプリができるかぎりポータブルで「Web らしい」ものとなるよう他のベンダーと協力していきます。

開発者のみなさんへ

自分のアプリのレシートを検証する責任は各アプリにあります。Firefox OS でアプリを販売しようとしている開発者は、この投稿を読めばレシート検証の実装をするにあたって幸先の良いスタートが切れるでしょう。仕様に準拠した Web ランタイムやマーケットプレイスを実装しようと考えている方にも役立つかと思います。

navigator.mozApps JavaScript API でアプリケーションのデバイスレシートにアクセスできます。レシートを検証する最も簡単な方法は、receiptverifier.js などのクライアントサイドライブラリを読み込み、レシートに埋め込まれたホスト型の検証サービス URL を使うことです。receiptverifer のドキュメントに詳細が書かれていますが、アプリの起動時に次の JavaScript を呼び出すだけでとても簡単です:

mozmarket.receipts.Prompter({
  storeURL: "https://marketplace.firefox.com/app/your-app",
  supportHTML: '<a href="mailto:you@yourapp.com">email you@yourapp.com</a>',
  verify: true
});

じゃじゃーん！これは高水準なショートカット検証であり、レシートが確認できないか無効である場合にはアプリ内に問い合わせ画面が表示されます。verifier のドキュメントには低水準の検証方法も書かれています。

より完備な例としては、テストに使用しているアプリ Private Yacht のコードをチェックアウトしてください。このアプリでは receiptverifier.js ライブラリでクライアントサイドの確認をどのように行っているかだけでなく、サーバサイドの確認を Node.js を使ってどのように行っているかご覧頂けます。他にも Python ライブラリ (更に Django 用ライブラリ) を用意しており、サーバ側でのレシート確認にお使いいただけます。仕組みはどうなっているのか？各レシートは JSON Web Tokens のマッシュアップです。プロパティにはレシートの確認に使える検証サービスがホストされているリンクも含まれます。レシートをオフラインで検証することも可能ですが、定期的な鍵の同期が必要になりますし、オフライン検証では今のところ払い戻しや再発行などが上手く扱えません。デフォルトでは、レシートはアプリの manifest に記載の installs_allowed_from パラメータのストア URL のいずれかにのみ許可されています。開発者としてあなたは各マーケットプレイスと明示的に支払いの関係を作り、アプリを売ったと主張できるサイトを制限できます。誰がアプリのレシートを提供できるかというホワイトリストとして機能します。クライアントサイド JavaScript はゆるい性質があるので、サーバサイド (つまり、アプリのサーバで) でレシートを検証することでよりしっかりと制御できるようになります。

Firefox Marketplace の課金アプリはまだ完全に有効になっていませんが、間もなくです。今のうちにレシート確認をアプリに統合していただければ、アプリの登録フローが課金をサポートする時に備えられます。

詐欺防止

だれもが Web でアプリを販売できるようにすることは、Mozilla の Opwn Web アプリのビジョンにおいてきわめて重大です。しかしながら、(DRM なしで) アプリを完全に保護しながらレシートを分散化させることは困難なことです。現時点ではユーザが課金アプリにアクセスできるように自身のクライアントに対して行える、DNS プロキシなどの攻撃がありますが、少し例を挙げれば、CSP, CORS や HSTS といったもので緩和できます。今日の iOS や Android の課金アプリの状況も大差はありません。マーケットプレイスのホワイトリストをより効果的に出来るよう現在すすめられている取り組みもありますし、Mozilla ではより多くの開発者とより多くのストアが参加するようシステムを改善していくつもりです。署名付きのパッケージ型アプリへと切り替えればもう一つの資産保護レイヤーを提供できますが、これは権限の問題を解決するために設計されたものです。

例によって、問題があればバグを報告してください！アプリプラットフォームのバグであれば Core (component: DOM: Apps) あるいは Marketplace (component: Payments/Refunds) へと報告してください。

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

昨日 Firefox 22 Aurora (プレベータ版) がリリースされました。Firefox 22 のサイト互換性情報を投稿しましたので、Web 開発者の皆さんはご確認ください。サイト運営者の皆さんにとっては、サードパーティ Cookie のブロックが大きな変更点でしょう。

なお、5 月 17 日に Aurora がリリースとなる Firefox 23 のサイト互換性情報も、1 件の重要な変更点を先行掲載しています。その変更点とは、セキュリティ保護のため、SSL 使用ページ内に混在している非 SSL コンテンツ (スクリプト、スタイルシート、動画など) が初期設定でブロックされるというものです。サイト運営者の皆さんは注意が必要です。

旧バージョンの互換性情報はバージョン別ドキュメントから参照できます。

もし一覧に漏れや間違いがあるときは、下のコメント欄でお知らせいただければ幸いです。

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

Firefox 20 ベータ版と Firefox 21 Aurora (プレベータ版) がリリースされました。それぞれのサイト互換性情報を投稿しましたので、Web 開発者の皆さんはご確認ください。もし一覧に漏れや間違いがあるときは、下のコメント欄でお知らせいただければ幸いです。

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

このドキュメントは Firefox 19 のサイト互換性に関わる修正のまとめに移動しました。もし一覧に漏れや間違いがあるときは、下のコメント欄でお知らせいただければ幸いです。

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

このドキュメントは Firefox 18 のサイト互換性に関わる修正のまとめに移動しました。もし一覧に漏れや間違いがあるときは、下のコメント欄でお知らせいただければ幸いです。

HTML5 にまつわる誤解を解く

原文: HTML5 mythbusting on November 1, 2012 by Chris Heilmann

HTML5 の実用性を巡って昨今繰り広げられている議論は、多くの間違った憶測に基づいています。それは、一度言われてからずっと繰り返されている、そして多くの場合正しいのかどうかまったく検証されていない、HTML5 に関する誤解につながっています。

HTML5 は遅い？

HTML5 の問題について話したがる人たちが必ず主張することと言えばパフォーマンスです。ここでの一番の問題は、そうした比較のほとんどがリンゴとナシの比較に過ぎないという事実を見落としている点です。

HTML5 アプリとネイティブアプリのパフォーマンスを比較することは、オーダースーツと既製品のスーツを比較するようなものです。もちろんオーダースーツは手袋のように体になじみ、見た目は素晴らしいですが、もし後でそれを売りたい、あるいは誰かに譲りたいと思っても、残念ながら難しいでしょう。他の人にも同じようになじむとは限らないからです。

ネイティブアプリとはまさにそういうもので、特定の環境と目的のために開発、最適化され、その状態に固定されるものなのです。これに関しては後ほど詳しく述べたいと思います。

一方 HTML5 は、その定義にも書かれているように、環境、ディスプレイ、あるいは技術とは独立して動作する Web 技術です。Web 上で成功するため柔軟性を最大限に備えています。そして Web もその定義通り解釈すれば、すべての人のために存在するのであって、非常に高価なハードウェアを購入する余裕があり一企業によって管理された固定環境に縛られることもいとわない、少数の恵まれた人たちのためだけのものではありません。

ネイティブアプリは端末やプラットフォームごとに一から開発しなければなりませんが、HTML5 アプリなら、スマートフォンからタブレット、デスクトップまで、ひとつの製品で対応できます。また、想定画面サイズや機能を固定せずユーザ環境をチェックして適宜対応することも可能であり、新しい携帯電話を買えない人たちを閉め出さなくても、より高速な最新端末を使用している人たちのユーザ体験を向上させられます。

一方でネイティブアプリは、多くの場合アップグレードを求めてきます。エンドユーザは新たなハードウェアの購入を強いられ、さもなければ製品自体を手に入れられません。柔軟性という観点から見れば HTML5 アプリは見事な役割を果たしており、逆にネイティブアプリはユーザを特定のハードウェアに依存させ、購入する余裕のない、あるいはあえて避けたいアップグレードが提供された場合、行き場を失わせることになります。その最たる例は、最近話題となった iOS 上での Apple 独自地図アプリへの移行です。多くのユーザが不満を抱え Google マップを使い続けたいと思っていますが、それは不可能です。

HexGL — WebGL ベースのレースゲーム

HTML5 は、デスクトップではパフォーマンスの点でネイティブアプリに十分勝る能力を備えており、スクロールのパフォーマンス、動画の即時解析・編集、さらには超高フレームレートでのフル 3D ゲームの実行や高速レースゲームの実現まで見る限り、パフォーマンスに関する問題がどこにあるのか自問しなくてはなりません。

その答えはハードウェアアクセスです。HTML5 アプリは、iOS や Android 向けに開発されたモバイルハードウェア上では二級市民として扱われており、最高のパフォーマンスを得られる部分にはアクセスできません。iOS の Web ビューは、ネイティブアプリと変わらない原理を用いているにもかかわらず、同じように高速に動作することを OS によって妨げられています。Android では、標準ブラウザがモタモタしているのに比べて、Chrome も Firefox もブラウザがどれほど高速に動作するかを証明しています。

Android の標準ブラウザは、長期間改良されることなく Web の進化を妨げる脅威となっていた 90 年代の Internet Explorer を思い起こさせます。思えば、それこそまさに Mozilla と Firefox が誕生したきっかけでした。

要するに HTML5 は砂利道でも運転できるよう設計された F1 レースカーですが、今はまだ回避するすべのない多くの重荷を OS によって課されている状態と言えるでしょう。

HTML5 はカネにならない？

HTML5 はオープンな Web 技術をベースとした技術の集合体です。HTML5 はマネタイズモデルを持ち合わせていないという見方は、Web がマネタイズできないというのと同じことです (広告で支えられているニュースサイトにそうした論調の記事が載った場合、特に皮肉っぽく聞こえます)。

閉鎖的なアプリマーケットは、一見すれば自社製品を売るのに簡単な方法と思われますが、その成功には多くの誇張表現があり、実際のところ閉鎖的なマーケットでひとつのアプリを売って生計を立てられている開発者はほんの一握りです。アプリマーケットでの発見性や検索性がますます低下していく中、素早く見つけられること、そしてマーケット内の検索結果で 1 ページ目に載ることが最重要課題となり、多くの開発者はひとつのアプリを集中して開発する代わりに同じようなアプリを量産しています (例えば、話す犬、話す猫、話すロバ… といった具合で)。

ネイティブアプリを揃えた閉鎖的なマーケットが開発者にとって実際にデメリットであると言えるのはこのためです。アプリは Web 上での住所 (URL) も持たず、マーケットの外から見つけることはできません。作ったアプリはひとつずつ別々のマーケットに手作業で登録する必要があり、またそれぞれの審査と登録のプロセスに従わなければならず、製品の機能停止を避けてアプリを簡単に更新する方法はありません。

HTML5 アプリは Web 上にあって URL を持ち、Adobe PhoneGap Build のようなツールでパッケージ化すれば iOS や Android 向けのネイティブアプリに変換することも可能です。その逆は不可能です。

長期的な視点に立った場合、開発者にとってより最適な戦略は何かという問題が提起されるでしょう。マーケット側の独断でいつでも製品を取り下げられる可能性のある特定の閉鎖的な環境に賭けるか、あるいは世界的でオープンな配布ネットワークを通じてアプリを提供しつつ閉鎖的なマーケットもカバーするか、です。

Android と iOS のマーケットにある多くのアプリは実際、HTML5 で書かれ PhoneGap で変換されたものですし、Financial Times が自社アプリを HTML5 で開発し、ネイティブアプリより多くの収益を上げているというニュースは大きな話題となりました。最近でも New York Times が同様に Web アプリ化を行うと発表しています。

HTML5 はオフラインで使えない？

HTML5 は Web 技術の集合体であることから、使用中ずっとオンラインでいなければならないと思い込んでいる人たちがいるようですが、そうした考えは完全に間違っています。HTML5 アプリでは、コンテンツをオフラインに保存しておく方法がいくつもあります。最も簡単な方法は、すべてのモダンブラウザが対応している Web Storage API です (ただし特別な例として Opera mini は除きます。このブラウザはクラウドサービスを通じてコンテンツを受信しており、独自のストレージツールを備えています)。また、Internet Explorer 以外の全ブラウザが対応しているアプリケーションキャッシュを使えば、アプリ自体をオフラインに保存しておけます。Web Storage API が提供する機能以上に複雑なデータを保存したいときは (Chrome と Firefox が対応している) IndexedDB か (iOS と Safari が対応している) WebSQL を使用できます。Lawnchair のような、互換性の問題を回避し開発者の使い勝手を高めるライブラリも公開されています。

HTML5 には開発環境がない？

よく言われる懸念のひとつに、HTML5 には開発者向けのツールが不足しているという点が挙げられます。不思議なことに、そのような声を開発者自身から聞くことはありませんが、自社の開発者に効率を上げる方法を考えさせる代わりにソフトウェアを購入することで解決したいと考える経営陣などからはそうした意見も耳にします。

HTML5 開発は基本的には Web 開発であり、驚くほど実用的な開発環境が整っています。繰り返しになりますが、本質的な問題は Web にまつわる誤解です。どこでもまったく同じに見えて同じように動作する製品を開発するのではありません。それは Web 本来の強みを奪おうとする考え方です。真の Web アプリとは、どのような環境でも動作しつつ、主要なプラットフォームではより優れたパフォーマンスを発揮する製品です。そのため、開発環境は特定の万能な製品ではなく一連のツールということになります。何を開発するかによって、その中からいくつでも選べるのです。もちろんひとつだけでも構いませんが。

Web がメディアとして大きな成功を納めているのは、開発者でなくても自由にコンテンツを公開できるためです。ブログプラットフォーム、CMS、あるいは OS に付属しているシンプルなテキストエディタを使って HTML ページを書き始められます。開発者としてのキャリアを積むにつれ、気に入ったツールをたくさん見つけ、それらに慣れ効率性を高めていくことでしょうが、ひとつの定番ツールというのは存在しません。Visual Studio や Eclipse のような統合開発環境 (IDE) を好む開発者もいますし、Dreamweaver のような WYSIWYG スタイルのエディタを求める人たちもいます。ただ Web 開発者の多くはテキストエディタかコマンドラインを使っているでしょう。秀丸、Jedit から、Vim、Emacs に至るまで、それらはすべて実用的なツールであり、実際に多くの開発者が Web コンテンツを開発するため日常的に使用しています。

デバッグやテストについても、最近ではツールが充実してきています。私たちが作り、エンドユーザ必ず目にするソフトウェア、つまり Web ブラウザも、デバッグ環境やテスト環境を兼ねているからです。変更箇所をリアルタイムで確認し直接編集可能な Firebug アドオンを追加できる Firefox をはじめ、Opera には Dragonfly、Safari や Chrome には開発ツールが付属しており、今やすべてのブラウザに開発者用の機能が多数搭載されています。Firefox の新しい開発ツールはさらに進んでおり、単なるデバッグ環境を超え、それ自体開発者が自分のニーズに応じて拡張可能なツール群として設計されています。

今ではリモートデバッガ機能まで提供されています。つまり開発者は、自分の開発マシン上で、モバイル端末上で動作しているアプリケーションに直接変更を加えられます。スマートフォン向けに開発し、それを端末に転送して、インストールし、テストし、間違いを見つけて… といった作業の繰り返しはもう不要です。これにより開発期間が劇的に短縮されるでしょう。

Firefox のリモートデバッガ機能

視覚的な環境を求める開発者が増える中、Adobe が最近 Edge スイートを公開しました。これは WYSIWYG スタイルによる HTML5 アプリ開発を実現するツールとサービス群で、例えば Photoshop からドラッグ＆ドロップで画像を配置するといったことも可能です。Edge Inspect は複数端末での同時テストを効率化し、PhoneGap Build を使えば HTML5 アプリを iOS や Android 向けのネイティブアプリとしてパッケージできます。

配布とパッケージに関して言えば、Google がつい最近 Yeoman プロジェクトを公開しました。これは、Web 開発者が Web 製品をアプリケーションとしてパッケージ、配布する手間を大幅に削減するもので、高速な動作を実現する機能まですべて備えています。

結局のところ、HTML5 はプラットフォーム中立であることから、決まった開発環境というのはありません。それが Web というものであり、自分に最も合ったツールを選べば良いのです。

ネイティブアプリにできず HTML5 にできること

HTML5 にまつわる誤解の多くは、突き詰めると、あるプラットフォームに特化して開発されテストされたアプリと、そのプラットフォームにも対応しているアプリとの比較だったという点に集約されるでしょう。競艇用モーターボートとホバークラフトの速度比較のように、同じ予測可能な結果になるのと似たようなものです。より興味深い質問を挙げるとすれば、開発者やエンドユーザにとって HTML5 を素晴らしいものにしている要素は何か、つまりネイティブアプリができないこと、あるいはしないことは何かということです。

一度書けばどこでも動く — HTML5 アプリは、ブラウザ内、タブレット上、そしてデスクトップで実行でき、iOS や Android に対応するネイティブコードへ変換することも可能です。その逆は不可能です。
Web を通じた共有 — HTML5 アプリは URL を持っていることから、Web を通じて共有したり Web 検索で発見できたりします。マーケットに足を運んで、混み合い限られたスペースの中から探す必要はありません。一方、他の Web コンテンツを宣伝するのと同じ方法がここでは使えます。より多くの人たちがあなたのアプリを気に入ってリンクすれば、それに伴って Web 検索の順位が上がり見つけやすくなるでしょう。
合意されたマルチベンダー標準に基づく技術 — HTML5 は現在の Web を形成している様々な企業の共同成果であり、開発者が不満を持つ方向へ傾く可能性のある、単独企業によって規定された仕様ではありません。
大勢の開発者 — 近年 Web 開発に何らかの形で携わった人たちは誰でもアプリを開発する準備ができていると言えます。もはや小さく専門的なコミュニティではありません。
消費ツールと開発ツールは同じもの — まず最初に必要なものは、テキストエディタとブラウザだけです。
小規模で部分的な更新が可能 — ネイティブアプリを更新するには、アプリケーション全体を再度ダウンロードする必要があります (例えば Angry Birds の新バージョンは 23 MB あり、それを 3G 接続でダウンロードする人もいます)。HTML5 アプリならデータを必要なだけダウンロードしオフラインに保存することができ、その上更新もはるかに簡単です。
シンプルな機能のアップグレード — ネイティブアプリはインストール時にハードウェアへのアクセス許可を求め、後からそれを変更することができません。あらゆるアプリがあらかじめ様々なアクセス許可を求めてくるのはそのためです (これはもちろんプライバシーやセキュリティに関わるリスクとなります)。HTML5 アプリは、ハードウェアやデータへのアクセス許可を、必要なときに更新や再インストールなしに求めることが可能です。
様々な環境への適応 — HTML5 アプリは、レスポンシブデザインを使って、コードに変更を加えることなく環境ごとに最適なユーザ体験を提供できます。デスクトップからスマートフォンへ、あるいはタブレットへ、それぞれに別々のアプリをインストールすることなくスムーズに移動できます。

ネイティブアプリでこうしたことが可能か考えてみてください。

ハードウェアからの締め出しを破り、マネタイズを簡単にするために

HTML5 が開発者にとって未だ確実な選択肢となっていない理由は、上述したハードウェアからの締め出しという問題によるところが大きいでしょう。iOS 端末では WebKit 以外のエンジンを搭載したブラウザの提供が許可されておらず、カメラやアドレス帳、バイブレーション、通話、テキストメッセージへのアクセスも HTML5 に許可されていません。それらはすべて、開発者にとってモバイル端末を面白いものにし、アプリにとって必須の機能と言えます。

このような問題を解決するため、Mozilla はいくつかの企業と共同で一連の API を開発し、標準化された方法による端末へのアクセス手段を定義してきました。これが Web API と呼ばれるものです。この API を使用すれば、あらゆるブラウザがハードウェアへのアクセス許可を安全な方法で取得することが可能となり、締め出しを破れます。

Web API を実装した最初の環境が Firefox OS で、来年には端末が出荷される予定です。Firefox OS では、ネイティブアプリと同じようにハードウェアへのアクセス権を持った HTML5 アプリを提供できます。開発者はハードウェアへ直接アクセスすることが可能であり、そのためより高速で、また重要なことにより小さなアプリを開発できるのです。エンドユーザにとってのメリットは端末が非常に安くなるということで、Firefox OS は、例えば最新の Android へアップグレードできない非常に低スペックのハードウェアでも動作します。

マネタイズに関して言えば、Mozilla は独自の HTML5 アプリ向けマーケットプレイスを開設しようと取り組んでいます。ここでは単に HTML5 アプリを登録できるだけでなく、単純な Web 検索でも発見可能となります。エンドユーザがアプリを簡単に購入できるよう、モバイルキャリアと提携し通話料と併せて請求する仕組みも整えようとしています。これによって、クレジットカードを持たないユーザでもアプリを購入し、モバイル Web 革命に参加できます。

HTML5 の実用性はどのぐらいか？

全体的に見れば HTML5 は急速に成長しており、アプリ開発者にとって非常に面白く信頼できるプラットフォームとなりつつあります。取り除かなければならない大きな障壁はハードウェアアクセスですが、Web API の標準化作業や PhoneGap のようなツールによって、従来考えられていたよりはるかに問題は小さくなってきています。

上で述べたネイティブアプリを超える HTML5 のメリットは、プラットフォームごとに別々のコードを書く時間を費やす代わりに、HTML5 アプリ開発に取り掛かるだけの十分な理由となるはずです。たとえ対応したいのがひとつの特定のプラットフォームだけで、HTML5 を選択する必要がなくても、そうした決定について HTML5 の問題のせいにするのは的外れでしょう。

HTML5 開発はプラットフォームやブラウザとは独立したものです。そうした考えを受け入れられない場合、その可能性に自ら制約を課していることになります。歴史的に、閉鎖的なプラットフォームは浮かんでは消えてきましたが、Web は今でも力強さを増しながら、世界中の膨大な数のユーザにリーチすること、そして誰かに許可を求めたり複雑な開発環境をインストールすることなく開発を始めることを可能にしています。これこそ多くの人たちが Web 上で何かを始めてきた大きな理由であり、今もそれは変わりません。そして Web では誰も閉め出されることはありません。さあ、あなたも HTML5 アプリ開発に挑戦してみましょう。

twitter.com のツイート入力欄で発生している、入力した文字が見えない問題の解説

twitter.comで発生している、長いツイートを入力すると、入力した文字が見えなくなってしまう、という問題ですが、最近、よく苦情を目にするようになっているので、ここに解説記事を書いておきます。Army of Awesomeでこの問題を見かけた方は、その、困ってるユーザに、この記事を教えてあげてください。

とりあえず、今、この問題を回避するにはどうすれば良いのか、という質問に答えるには非常に難しいものがあります。

最も簡単なのは、Firefoxのバグを利用することです。今回の一件で、入力欄の最後の行にキャレット(テキスト入力中に点滅しているインジケータ)がある時に、下矢印キーを押すと、一番下までスクロールすることが分かりました。これはバグなのですが、現在、ユーザが利用できる一番簡単なスクロール方法です。ですが、自由なスクロールはできませんので、最低限の回避策、というレベルのものです。

最も自然な解決策は、ユーザスタイルシートを記述することです。しかし、この解決策を行うには、ユーザが、ユーザスタイルシートを記述する知識を必要としますので、残念ながら、簡単ではありません。ユーザスタイルシートについて知識が無い方は、上記のバグを利用した操作で利用するしかありません。ユーザスタイルシートで解決したい方は、以下の原因に関する説明もあわせて読んでください。

何が、問題なのかを理解するには、CSSのoverflow: hidden;についての知識が必要になります。twitter.comのツイートの入力欄には、このスタイルが指定されており、CSS仕様では、ブラウザはユーザにスクロールするUIを提供してはいけないと定められています。このため、入力内容がはみ出してもユーザの操作を基に、スクロールしてはいけません。Javascriptからのスクロール位置の指定でのみスクロールできるのが正しいのです。これは、Webデザイナへ提供されたひとつのデザイン手法なのです。つまり、一言で言うなら、twitter.comのサイト側の設計に問題があります。

では、なぜ、今までは問題が無かったのか、というと、twitter.comでは、入力内容が入力欄からはみ出す場合に、入力欄のサイズを大きくし、全ての内容がスクロール無しで表示できるようになっていました。ですが、twitter.comはサイズ変更を行わないように変更され、入力内容がはみ出してしまうケースが出てきました。

では、なぜ、他のブラウザでは問題が無いのか、というと、他のブラウザでは、入力欄にoverflow: hidden;が指定されていても、キャレットが常に表示されるように、スクロールするためです。調査したところ、Internet Explorer、Safari、Google Chrome、Operaのいずれにおいても、キャレットの移動によるスクロールが可能でした。これでは、Webサイトの動作をFirefoxではテストされていない場合に、Firefoxのユーザに今回のような深刻な影響を与えてしまいます。このため、Firefox 18では、他のブラウザと同様に、内容が編集可能な場合にのみ、キャレットが常に表示されるようにスクロールするよう、修正されました。ですが、Firefox 16はもちろん、Firefox 17でも修正されないことが決定しました。これは、修正による副作用のリスクを考慮しての決断です。

現在、Mozillaでは、ツイッター社にサイト側でなんらかの対応がとれないか、コンタクトを試みています。ツイッター社がこの問題に、サイト側で対応してくれれば、一番良い解決策を、Firefox 18までに提供することができるでしょう。