投稿されたすべてのトピック

ARM 版 Windows ユーザーにもブラウザの選択肢が必要だ

原文:Windows on ARM Users Need Browser Choice Too
過去8年間、ユーザーと開発者は快適なデジタルライフを過ごすことのできるように、ブラウザの選択肢を与える Windows プラットフォームを楽しんできました。これは常にそうであったわけではありません。 Firefox  が2004年に登場する前、ブラウザはただ1つ Windows – Internet Explorer のみでした。2005年から2009年にかけては、ただ IE と Firefox だけが Windows プラットフォームにおいて意味のあるシェアを築いていました。選択肢はさらに Chrome の登場に伴って増加し、今日ユーザーは様々なブラウザを選択することができます。 かつてそのような状況があったことを想像するのは難しいこととなりました。不幸なことに、 ARM 版 Windows の迫るリリースとマイクロソフトの Windows 8 Metro に対するブラウザの実践は、ユーザーと開発者にブラウザ選択の自由が与えられない、招かれざるデジタル暗黒時代への回帰を示しています。

Windows RT (マイクロソフトが ARM 版 Windows に与えた名称) は二つの環境、クラシック環境とアプリ向けの Metro 環境が存在すると報じられています。しかしながら、  ARM 版 Windows では特権的な IE を除き、あらゆるブラウザがクラシック環境での動作を禁じられています。 実際のところ、 Internet Explorer のみがユーザーが慣れ親しんできた速度、安定性、セキュリティのようなモダンブラウザの高度な機能を実現できるということです。IEがARM 版 Windows で動く以上、他のブラウザが技術的理由で同じことができない理由はありません。

なぜこれがユーザーにとって問題なのでしょうか? とてもシンプルなことです。なぜなら現在設計されている ARM 版 Windows はユーザーの選択肢を制限し、競争と、打ち震えるような革新を減少させているからです。 IE のみがモダン web ブラウザとして高度な機能を許されることによって、 サードパーティのブラウザはプラットフォームから明らかに除外されてしまいます。これは今日のタブレットや未来の PC ユーザーにとって問題です。 ARM チップセットが主に電話やタブレット端末に今日使用されているのに対して、 PC ハードウェアプラットフォーム上でも同じように 将来的には ARM  は 重要になっていくでしょう。 これらの環境(訳注、既存の XP や 7 のような Windows OS 上)では現在 、ユーザーと開発者双方に利益をもたらす強烈なブラウザの競争が起きています。 PC がとても幅広いフォームファクタと設計に対応している現状に視野を広げてみれば、あるいは他の様々な予測からも、ARM上で動作する Windows がラップトップやタブレットや携帯電話をはじめとしたデバイスの全範囲で動作するであろうことは簡単に想像できます。これは ARM 上で Windows が動作する環境がある限り、ユーザーがただ 1 つのブラウザしか選択できないことを意味します。

我々は、 Microsoft がユーザーの選択に関する原則を堅持することをお勧めします。サードパーティ製のブラウザを除外することは、ユーザーと開発者が何年も依拠しているMicrosoft 自身の公表原則と矛盾しています。これらの原則は、司法省への独禁法対策という一側面を超えて、注目すべき Microsoft の市場に対するアプローチの表明となりました。

ARM 版 Windows はブランド、コード、フットプリント、および経験を含む非常に多くの従来の Windows の資産に依存しているので、 IE 以外のブラウザを除外することには独禁法への影響があるかもしれません。もしも ARM 版 Windows が単なる新しいハードウェアに対する「新しい Windows」であるとしても、それはまたEC のブラウザ選択に関する同意(pdf)に抵触しうると同時に、そのようなふるまいは司法省と Microsoft の同意(訳注、 Microsoft の市場独占による競争阻害を防ぐための同意)がまさしく禁止しようとしていたことそのものです。

ARM デバイス上の次世代 Windows が1つのブラウザにユーザーを縛り付けるという方向性は理不尽であり、新しいプラットフォームへのロックインの第一歩を表しています。それはこのような方法である必要はありません。かつて発表された Windows の原則において、 Microsoft社の ジェネラルカウンセル Brad Smith 氏は“世界中で幅広く使用されているオペレーティングシステムの製作者として、我々は情報技術業界での技術革新を進めること、競争を維持を援助することの双方に特筆すべき責任がある”と表明しています。  我々はマイクロソフトがユーザーの選択に関する原則を堅持し、閉じられた道(訳注、ユーザーの選択肢を奪うようなプラットフォームの構成)へ進みたいという誘惑を排除することをお勧めします。世界はこれ以上閉じた独自の環境を必要としていませんし、Microsoft にはそれ以上のものになる機会があります。

– Harvey Anderson, Mozilla ジェネラルカウンセル

学生Add-On勉強会2012.10.27

Firefox学生マーケティングチーム(以下 学生マーケ)主催の勉強会を行い
「Add-Onは使っているけど、Add-Onの開発は未経験。興味を持っているけど、どうしたらいいかわからない!」
そんな学生を対象としたAdd-On勉強会を学生マーケで開き、少しでもFirefoxへの興味を持ってもらいたい。
勉強会を広く開催するにあたってまずは、テストとして、学生マーケの友人等を招待し、勉強会を開催しました。

<趣旨>
Add-On開発初心者に向けて、開発環境の構築~実際に自由な発想でAdd-Onを作ってみる。

講師:EnsekiTT あっきー
参加者:5人
お持ちいただいたもの:ノートPC持参

Twitter:#gakumoz

まずは講師のEnsekiTT君から、環境設定について。

GakuseiStudy2012.10.27.1

メンバーが作成したハンドアウトが役立ちました。
GakuseiStudy2012.10.27.2

参加者もJS初心者~Python,Rubyでの開発経験者まで様々でしたが、実際に導入が
終わって開発の時間には、黙々とコーディングしたり、講師に質問したり。

GakuseiStudy2012.10.27.3
GakuseiStudy2012.10.27.4

実際に作成された、Add-On達

小川さん
名前:わさびちゃん
概要:アドオンバーのアイコンをクリックするとわさびちゃんが表示されるアドオン

伊納さん
ハンドルネーム:legokichi
名前:ネガポジ反転
概要:ページを問答無用でネガポジ反転します

野田さん
名前:click 2 play mod
概要:click to play使用時にブロックした要素名を表示するアドオン

EnsekiTT
名前:dragANDtweet
概要:Webページ上で気に入ったフレーズをドラッグ&ツイートするアドオン
フレーズが長い場合の短縮と任意のハッシュタグと、フレーズ位置にフォーカスする機能をつけたいところ

GakuseiStudy2012.10.27.5

最後は、アンケートを書いていただき、集合写真を撮って終了しました。
GakuseiStudy2012.10.27.6

<アンケート集計結果>
普段使う言語:JS 2,C 2,C++ 2,C#,php,Ruby,あまり開発しない 2
難しかった:適度だった=2:3
興味分野:WebDev,App開発

<反省点>
・時間はもう少し長め5時間程度?
・比較的簡単なアイデアやソースのサンプル・見た目におもしろいアドオン等 のサンプルの用意
・講師1人あたま2人がベスト(3人が限界?)
・成果のアウトプットの仕方

もう一度、もう少しオープンに人を募って開催してみて、そのフィードバックを踏まえ
実際に開催していこうという予定となっております。

講師や、協力してくださる方も絶賛募集中です!
お問い合わせは、こちらまでお願いいたします。
campusreps@mozilla-japan.org

今回の資料

学生アドオン勉強会テキスト

作成:あっきー

Addon sdkはじめの一歩 from EnsekiTT

作成EnsekiTT

お誕生日おめでとう、Firefox!

[この記事はThe Denのブログ記事 Happy Birthday Firefox! の訳です。
2012年11月9日は2004年にリリースされたFirefoxの8歳の誕生日です!]

(画像: フォクすけ at Facebook )

お誕生日おめでとう、Firefox!

今から8年前の今日に、Firefox 1.0はリリースされました。 — そして今では世界中のとても多くの人々に選ばれているブラウザになりました。お祝いするために、私達はあなたに認識していただきたいのです — 私達はWebが全ての人に対してオープンであり続けるために、そしてFirefoxを最も安全で、最も速く、最もセキュアなブラウザにできるように努めているからだということを。ありがとう!

Firefox 17 のアドオン互換性に関わる修正のまとめ

[これは Mozilla Add-ons Blog の記事 Add-on Compatibility for Firefox 17 の抄訳です]

Firefox 17 が 11 月 20 日の日本時間深夜にリリースされます。Firefox 17 の変更点でアドオンの互換性に影響を及ぼす可能性のあるものを以下にまとめました。Firefox 17 for Developers により詳しい情報が載っていますので、こちらも併せてご覧ください。

General

XPCOM

新機能

その他、Firefox 16 で判明した 読み込みハンドラの問題 が Firefox 17 で修正されています。

この一覧に載っていない変更点や間違いを見つけたらコメント欄でお知らせください。もしあなたのアドオンが Firefox 17 で動かなくなった場合は、筆者の方でも調査したいと思います。

AMO に登録されているアドオンの 自動互換性テストと対応バージョンの更新 は来週行われますので、後日メールをチェックしてみてください。

HTML5 にまつわる誤解を解く

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

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

HTML5 は遅い?

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

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

IMG_4197.jpg by Hello Turkey Toe, on Flickr

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

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

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

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


HexGLWebGL ベースのレースゲーム

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 アプリ開発に挑戦してみましょう。

ブラウザ選択が求められたときの問題について知る

原文:Knowing about choice matters, when millions are asked to select a browser | The Mozilla Blog

※この記事は既に内容が古く、記事中の役職等が現在のそれと違う場合があります。

※本記事で触れている Open To Choice は既に終了したキャンペーンです。

今週、 Mozilla は Open To Choice キャンペーンを開始しました。欧州の web ユーザーの間で、インターネットにアクセスするソフトウェアやサービスについて正しく情報を伝えられたうえで選択することがいかに重要か、その認知を高めることを目標としています。このキャンペーンは32か国で約2億の人々が、彼らのオンライン体験の代理人の役割を果たす web ブラウザの積極的な選択を求められるようになる(訳注、 BrowserChoice のリリース)のと同時にスタートします。

Open To Choice は Mozilla CEO の John Lilly と 代表 Mitchell Baker が、欧州委員会とマイクロソフトの生んだ”より多くの人がオンライン上の生活をコントロールすることを支援する重要な指標である”画期的なブラウザ選択画面 Browser Choice に対して送った公開書簡から始まりました。公開書簡はより深い理解、つまり今日のブラウザの決定的な重要性について説明すること、選択肢を与えるだけでなく正しい情報をもとに選択できるように教育を施すことを求めています。

John Lilly が公開書簡となぜブラウザを選択することがそこでま重要なのかについて解説した動画をごらんください (外部サイト、全編英語)

今後数週間は Opentochoice.org はブラウザの基本に関する情報をさらに発信していき、 Web 上の選択肢の重要性について語り合うためのハブとなっていくことでしょう。

ぜひ公開書簡を読んで、 http://www.opentochoice.orgの会話に参加してみてください。

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までに提供することができるでしょう。

アドオン互換性情報: Firefox 16 でウィンドウ読み込みハンドラが呼び出されない可能性

[これは Mozilla Add-ons Blog の記事 Possible window load handler failures in Firefox 16 の抄訳です]

アドオンの互換性問題が最近になって Firefox 16 に見つかりました。Firefox 16 だけでなくそれ以上のバージョンにも影響し、現在 Mozilla の開発者が調査を進めています。

その問題とは、多くのアドオンが依存しているウィンドウ読み込みイベントハンドラが特定の状況で呼び出されないというものです。既に分かっていることは、この現象は、ポップアップウィンドウが開かれており、なおかつ新しいウィンドウ内のドメインがそのウィンドウを開いたドメインと異なる場合に限って発生するようです。大半のアドオンのスクリプトは読み込みハンドラの呼び出しに依存していることから、その多くは新たに開かれたポップアップウィンドウでは動作しないという状態になっています。詳しくは Bug 799348 をご覧ください。

今のところ、私たちはこのバグの影響は非常に軽微であると考えています。そのため、予定外の Firefox 16.0.1 を提供するだけの十分な理由がない限り、Firefox 17 まで修正は行いません。もしあなたのアドオンが影響することが分かりましたら、コメント欄でお知らせください。

[訳注: 問題が発生するのは window.addEventListener("load", func, false) のような典型的なコードのようです。原文やバグのコメントによれば、Adblock Plus や InstantFox Quick Search などが影響を受けるとの報告があります]