編集長の白石です。

Web技術者であれば一度はその名を耳にしたことがあるであろうMozilla Japanが「WebDINO」と名前を変えた（プレスリリースへのリンク）ことを受け、WebDINOの代表である瀧田 佐登子さんにいろいろと話を伺ってきました。

瀧田さんはWikipediaにも紹介ページがあるように、日本のWebシーンを裏で支え続けていた立役者。90年代の第一次ブラウザ戦争時代にはNetscapeの開発者として活躍し、その後Mozilla Japanを設立して、Mozillaコミュニティを日本に根付かせた方でもあります。

本記事では、WebDINOへの名称変更の裏側のみならず、Netscape時代のエピソードやオープンソースコミュニティへのこだわり、そして今後のWebのビジョンまでお聞きしてきました。 読み応えのある対談になったかと思います。お楽しみください〜！

■瀧田 佐登子さんのプロフィール
国内大手IT企業で UNIX・インターネット事業に従事した後、1996年より米国 Netscapeの開発現場でブラウザの国際化・日本語化を担当。Netscape日本法人撤退後も、米国本社所属のプロダクトマネージャとして国内の金融関連サポートおよびプロモーション業務を担う傍ら、Webブラウザ技術のエバンジェリストとして国内でのコミュニティ活動を行う。2004年、米国Mozilla Foundation の設立を機に、同財団の公式支部であるMozilla Japanを設立。代表理事としてMozilla製品・技術の普及活動、Web標準技術やオープンソースの推進、Webの新たな可能性の探求や人材育成などに取り組む。
2017年7月に、Mozilla Japanを一般社団法人WebDINO Japanへと社名変更。現在は、Webとオープンを軸にした、産官学・コミュニティをつなぐ非営利組織として、テクノロジーの普及とイノベーション拡大を目指す活動を行う。
2007年より慶應義塾大学非常勤講師。2009年より中央大学大学院 理工学研究科 兼任講師。日経ウーマン・オブ・ザ・イヤー 2009 リーダー部門受賞。2009年度日本OSS貢献者賞受賞。第9回北東アジアOSS推進フォーラム特別貢献者賞受賞。

「Netscapeのオープンソース化」という事件の舞台裏

白石 こんにちは。瀧田さんにはずっとお会いしたかったので、お会いできて大変光栄です。

瀧田 こちらこそ。

白石 今回は、Mozilla JapanがWebDINOに名称変更したということで、実際のところを伺いに来ました。いろんな憶測も飛んでいる中で、いろいろと率直にお話を伺えればと思います。

瀧田 はい、ぜひ。なんでもお聞きください。

白石 瀧田さんはNetscape社にいらっしゃったんですよね。

瀧田 はい。元々は、日本企業でUNIXのエンジニアをしていたのですが、勤めていた会社がこれからはインターネット事業だ！ということで米国に視察に行ったんです。

そこでブラウザというものに初めて出会ったのですが、その頃のソフトウェアって当然のようにアメリカ中心で、国際化（Internationalization） のことなんかちっとも考えられていない。 インターネットってグローバルなものなのに、日本語対応とかが全然必要だとも思われていなくって。

「そんなんでインターネットを語るなよ」みたいな気持ちもあって(笑)、フィードバックを繰り返していたら、逆にNetscapeから「入社しないか」というオファーがあったんです。

その時は「Web」という言葉も一般に認知されていないような時代でしたが、「Webは爆発的に普及するな」という予感もあったので、そのオファーを受けて入社しました。それが1996年頃ですね。

白石 その当時は第一次ブラウザ戦争と呼ばれる、Internet Explorerとの競争も激しかった時期ですよね。

瀧田 そうですね。あの時はブラウザ間の互換性も低く、多くの批判もありました。ただ、今考えると、あの激しい競争があったからこそ、あれだけのスピードで技術が進歩したんだとも思っています。

白石 その後、1998年にNetscapeのソースコードが公開されるという大事件がありましたね。その時の様子はどんな感じだったんですか？

瀧田 あれは実は、当時現場で働いていた私たちにとっても突然の出来事だったんです。社内でもごく一部の人間にしか知らされていませんでした。ある時カフェテリアに集まるように言われたので行ってみると、ソースコードをコピーした紙が高く積んであって、それを撒き散らし始めたんです。そうして、全社員に対してオープンソース化の件が発表されました。ものすごくびっくりしましたね(笑)。

白石 それは面白い(笑)。

瀧田 この時公開されたソースコードは公開用に準備されていたものでした。というのも、Netscapeには、サードパーティー製のコードもたくさん含まれていたのですが、さすがにそれを一緒に公開するわけにはいかない。なので、そうした部分が取り除かれたものが用意されたのですが、コードが歯抜け状態だとちゃんと動かないわけです。ダウンロードしたユーザーからは多くの不満が寄せられました。

白石 そんなこともあったんですね！Netscapeのコード公開が、「オープンソース」という単語と文化の誕生に大きく寄与した…なんて知識しかないものですから、裏にそんな苦労があったとは知りませんでした。

瀧田 大変でしたよー！そもそも公開する前提なんかで書いてないコードでしたから、Netscape Communicator 4 当時はコードもかなり汚かったんじゃないかな。使ってない関数がそのまま残っていて、誤って呼び出しちゃうなんてバグもざらにあったし。そんなコードを世の中に晒すのは、はっきり言って恥ずかしかったですね(笑)。

白石 なるほど。ただ、今だからお聞きしたいのですが、Netscapeのオープンソース化は、IEに対して負けを認めての半ばヤケクソだったのか、それともシェアを奪還するための「勝とう」という動機からのものだったのか、どちらだったのでしょう？

瀧田 当時のNetscapeは独立した営利企業ですし、やはり勝つための行動だったとは思います。

ただ同時に、コードをオープンにすることが、多くの不確実性を呼び込むということもわかっていたとは思います。 あとは、社内のエンジニアだけでは得られない社外の多くの人の叡智に賭ける（そしてシェアを奪還する）という思いも大きかったのではないでしょうか。

Mozilla Japanの立ち上げ

白石 98年のオープンソース化から、瀧田さんが2004年にMozilla Japanを立ち上げるまでの経緯はどんなものだったのでしょうか？

瀧田 NetscapeのAOLによる買収などを経て2001年には日本法人も撤退し、一時はもうブラウザをやめようかと思った時期もあります。ただ、Web標準の重要性を日本の企業に説明に行ったり、個人的にNetscapeの広報活動をしたり、オープンソースコミュニティと一緒に行うイベントなどの活動は続けていたんです。

そして、2003年にAOLが Netscapeなどのクライアント事業を完全に分離し、Mozilla Foundationが誕生したのをきっかけに、日本でコミュニティ活動をスケールさせるためには母体となる組織が必要だと感じ、Mozilla Foundationの公式アフィリエイト（支部）として、2004年にMozilla Japanを設立しました。

白石 コミュニティのためにMozilla Japanを設立した、と言っても過言ではないわけですね。

瀧田 はい、日本はもともと世界的に見ても Mozilla のコミュニティ活動が特に活発でした。当時の状況だと、非営利の法人が存在した方が、そうしたコミュニティ活動やオープンソースプロダクトの信頼性の確保につながると考えたんですね。もちろん、インターネットを健全で開かれた場所にするという Mozilla Foundation のミッションに強く共感したということもあります。

その後Firefoxがリリースされてからは、国際化はもちろんのこと、オープンソースを活用した人材育成だけでなく、Webの可能性の探求をはじめとする日本発のイノベーションを世界に伝えたいと思って活動していました。 やはり、日本人が持つこだわりや繊細さは、世界に通用するものだと思っていますから。

Mozilla Japan設立から13年経ちますが、いまだにそうした想いは変わらないですね。

Mozilla JapanはなぜWebDINOに？

白石 ではその13年後である現在、瀧田さんはMozilla JapanをWebDINOに名称変更されました。WebDINOという名称には、どういう意味が込められているんですか？

瀧田 Webは私たちにとって欠かせないものです。そしてDINOはWebに対して私たちが重視してきた、そしてこれからも重視する価値観を表しています。

DはDiversity (多様性)。
Iは私たちがずっと注力してきたInternationalization (国際化)ですが、人によってInternetだったり、Innovationだったりしてもいいと思っています。
NはNeutrality (中立性)。
OはOpenness (公開性)です。

この4つの要素をつなげたらDINOになったわけです。

白石 なるほど、様々な意味と想いが込められた名前なのですね。WebDINOに名前を変えるまでに、どういう経緯があったのでしょう？

瀧田 昨年末、Mozilla Japanの今後について深く考える機会がありました。

まずMozillaという組織についてお話しますと、最初にできた母体であるMozilla Foundationとその後2005年に設立されたMozilla Corporationから構成されています。 非営利法人であるMozilla Foundationが、営利企業であるMozilla Corporationを子会社として所有しているという形になっています。

Firefoxは、検索エンジンへの窓口として収入を得ていますが、その収入が非常に大きくなってきたことでNPOであるFoundationで扱える範囲を超えるため、財団の下に営利企業を作って運営するという形を取っているんですね。

白石 営利企業が非営利団体の子会社、って面白い構図ですね。知りませんでした。

瀧田 Mozilla Japanは、Mozillaの中ではちょっと特殊な立ち位置だったのです。Mozilla Corporation ができる前にMozilla Foundationの公式支部としてできた組織で、日本の独立した法人ですから。そういう特殊な立ち位置のまま13年経過した。

しかし今は、グローバルに向けた業務はMozilla Corporation に所属するスタッフが行うことになっているので、特定の地域に向けてのみ活動する組織というのは、Mozillaの中では認められていないんです。そこでこの状況をどう整理するかという時期に来て、組織としてどうあるべきかをあらためて考えた時、私たちがしたかったこと、してきたことを見直すきっかけになりました。

企業体としてのMozilla Corporationは、当然ながらプロダクトにフォーカスしています。 組織としてどうあるべきかをあらためて考えた時、私たちがしたかったこと、してきたことって、プロダクトを通じてMozillaの理念を伝えることもそうですが、日本の状況に寄り添ったMozillaの理念を軸にしたチャレンジングな活動だったはず。

だから、私には、Mozillaプロダクトのマーケティングだけを行っていくという選択肢はあり得なかったのです。 というのも、私たちはMozillaのユーザーはもちろん、すべてのWeb、インターネットを使う人たちのために何をすべきかを考えたいと思っていたので。

なので、組織体制的にMozilla Japanをどういう位置づけにするべきかという選択の中で、Mozilla Foundationの公式支部という立場を離れ、外部組織として連携を図っていくことにしたというわけです。

白石 元々ががミッションやコミュニティ、オープンソーススケールのために作ったのだから、プロダクトのマーケティングのみを行う組織には甘んじたくなかったと。

瀧田 というより、もともとAOLから離れて100％NPOとしてコミュニティ主導に変わり、Mozilla Foundationができた時に賛同して作った組織なので、その頃からの志は変えたくないというか。例えばMozilla Europeなんかは、Mozilla Corporationが設立された時点で、その傘下に入りました。Mozilla Japanにも、当時そういう選択肢はあったのですが、そうしなかったという経緯もある。

そういう歴史も踏まえつつ、これから5年10年先を見据えて「Mozilla Japanはどうすべきか」と考えているうち、自然と「Webはどうあるべきか」を考えていたのです。それに気づいた時、Mozilla組織内という立場にとらわれず、逆にもっと大きな視野でWebを考える立場として活動する方がフィットするのだと判断しました。

白石 それは大きな決断ですね。今後、Mozillaとの関わりはどうなっていくのでしょう？

瀧田 もともと特殊な立場だったので、当面はそれほど大きな変化はないですね。Mozillaのプロダクトマーケティングだけをやってきたわけではないのでスタンスも変わりませんし、引き続きMozilla Foundationの活動には協力していくことになっているので。 活動資金という面から言うと、これまではMozilla Corporationからマーケティング活動に対して予算を割り当てられていましたが、今後は外部組織という立場から、Mozilla Foundationにプロジェクトベースで相談していくことになります。

白石 なるほど、運営面では当面大きな変化はないと。ただ、その先もサステナブル（持続可能）な活動が可能なのでしょうか？

瀧田 Mozillaのマーケティング以外に行ってきた様々な事業も引き続き行いますし、今後も色々と構想しています。チャレンジであることは認めます。しかし実は数年前から、ブラウザという枠を出たい、もっと外からWebを眺めたいと思って活動していたんです。

現在、技術という面ではWebは多少停滞しているのでは、という思いがあります。だからこそ、Webをブラウザという枠の外にどんどん広げたいと思っています。IoT/WoTの活動や、CHIRIMEN OPEN HARDWARE のコミュニティ活動支援なども引き続き行っていきたいと思っています。そういうチャレンジに正面から向き合えることは、正直ワクワクしていますね。

オープンソースコミュニティとしてのMozilla、企業としてのMozilla

白石 ところで、Mozilla JapanがWebDINOに変わったように、Mozillaという組織やコミュニティ自体にも、何がしかの変化が起きているのでしょうか。

瀧田 Mozillaに限ったことではありませんが、企業体が大きくなったことで、企業体とコミュニティのバランスが難しいところに来ているとは感じています。

Mozilla Corporation内で給与をもらってエンジニアリングをしている人もいれば、コミュニティには純粋にボランタリーな人もたくさんいるわけです。そうした多様な開発者と、分け隔てなく接していけるかどうか。難しくも繊細な問題です。

白石 例えば、Mozillaが開発方針や優先順位を定めたとしても、善意や関心で関わっているコミュニティの人々は、Mozillaのリードに従う義務はないはずです。そこのバランスをどう取って、開発を進めているのかは、ずっと誰かに聞いてみたいと思っていました。

瀧田 Mozilla Corporationは、MozillaやFirefoxというブランドを保持している以上、そのブランドの価値を高めていく必要があります。そこで、開発全体を管理しようという欲求が生じるのはある意味やむを得ないところです。

それが、コミュニティ的な自由とのせめぎ合いになるところなのは間違いないですね。Mozilla Japanのメンバーは、Mozillaの組織がまだ小さかった頃から関わってきたので、そうしたせめぎ合いの中でも、常に「Mozillaらしさ」を意識して行動するようにしていました。

白石 なるほど、やはりそういうせめぎ合いはあって、バランスを取って進めていたのですね。

ではもう一つ、前から疑問に思っていたことを聞かせてください。Firefoxのシェアが下降しているというデータがありますが、それについてMozillaやMozilla Japanはどう捉えていたのでしょうか。

というのも、非営利組織であり、ミッションを重視するという立場からすると、競合と言えども「Webを盛り上げる仲間」という捉え方もできるわけです。そうなると、シェアを伸ばそうという強いモチベーションは生まれにくいのではないかと想像していました。

瀧田 おっしゃる通り、何が何でもマーケットシェアを拡大していこうという貪欲さは、Mozillaには馴染みがないものだと思います。ただ個人的には、ある程度のシェアを確保しておく必要はあると感じています。

というのも、Firefoxが登場して間もないころはInternet Explorerの独占状態で、私たちが何を言っても「なぜいまさらブラウザなのか」という扱いで、誰にも相手にされないような状態でした。目標とするマーケットシェアを尋ねられた時に「25%を目指します」と答えたら、あまりに非現実的だと受け止められて、鼻で笑われたものです。

しかし、シェアが10%を超えたあたりから明らかに周りの反応が変わってきて、実際に25%に近づいたときには、私たちの言うことにみな耳を傾けてくれるようになりました。そういう経験から言うと、発信力や発言力を保っておくためにも、シェアは少なくとも10%以上はキープしておかないと、という思いがあります。いくら崇高なミッションを掲げていても、耳を傾けてもらえなければ意味がありませんから。

ただし、シェアが高いだけではだめで、そのシェアを持つことで何を伝えるかが重要だと思っています。シェアを持ったベンダーは、マーケットに対して何を貢献するのか、Webの標準の重要性だったり、Webのエコシステムだったりと、ミッションとシェアの両方があることが重要なのだと思います。

あとは、製品を提供する企業が一社では良くないという想いもあります。先程も申し上げましたが、第一次ブラウザ戦争は痛みももたらしましたが、技術の急激な進歩を後押ししました。 技術革新の健全な競争は、Webの発展のためにも必要だと思います。

白石 発言力という点で言うと、シェアの変化に伴い、W3C内でのMozillaの発言力に変化はありますか？また、WebDINOになってW3Cとの関わり方に変化はあるのでしょうか？

瀧田 国内の話で言うと、これまでもW3C/Keioさんとは、日本独自のイベントなどをいろいろとコラボレーションをさせていただいてきました。日本のWeb発展のためにも、できればそうした関係はこれからも続けていきたいと思っています。

W3CでのMozillaの発言力という点については、それほど影響は出ていないのではないでしょうか。HTML5で最も話題になっていた頃に比べると、標準化の活動が落ち着いているな、という感はありますがWeb技術はどちらかというと発展のフェーズから活用のフェーズに入ったのではないかと思います。

これからのwebはどうなるか、どうあるべきか

白石 では瀧田さんは、今後のWebはどうなるとお考えですか？

瀧田 Webは、ブラウザの枠を出なくては…という思いはありますね。

Firefox OSの開発中止が発表されたあたりでしょうか、今後のコミュニティ、Web、そしてインターネットはどうあるべきか、よく考えたんです。その時感じたのは、ブラウザという枠から出ることのできないMozillaのままではいけない、一旦外に出てWebを見直さなければいけないということです。

そうして実際に、ブラウザの枠を超えた活動を通じて、実際に触ることのできるリアルなものとWebがつながることが大事だという想いを深めました。すべてのものにURLが振られ、触れるものすべてがWebとつながっている世界。そこには、今のブラウザが想定しているようなビジュアルなUIはありません。ブラウザは空気のようにならなくてはならない。

白石 そうなった時、もはやそれを「ブラウザ」とは呼ばないでしょうね。ブラウジングじゃありませんから。

瀧田 そうです。ブラウザは、この先もずっとブラウザと呼ばれているようではダメだと思います。

白石 すごく進んだ考え方だと思います。

瀧田 はい、もしかすると私はいつも早すぎるのかもしれません。

この間部屋を片付けていたら過去の講演資料が出てきたんですが、2004年くらいの時点で、Webはコミュニケーションとアプリケーションの基盤になるということや、モバイルWebについても語っているんです。

そしてMozillaがFirefox OS、つまりモバイルを語り始めた頃には、IoTとWebについて語っていた。技術というのは10年くらいで一つの区切りがあると考えているのですが、一区切り先を語ってしまっているのかもしれないな、と思います。

ただ、そういう人もいていいのかな、とは最近思うんです。私は鉄腕アトムが好きなんですが、その世界観が多くの人に影響を与えて、実際の世界にも近づいてきていると感じています。そういう、未来に関するビジョンを示すという役割も世の中には必要なんじゃないかな…と考えています。

ちなみに、白石さんはWebの未来について、今後どうなるとお考えですか？

白石 うーん…ぼくは、瀧田さんほどビジョンめいたものは抱いていません。が、最近ぼくはコミュニティというものに改めて価値を感じているんです。

瀧田 改めて、ですか？

白石 はい。ぼくがコミュニティ（html5j）を運営していた頃って、実はコミュニティというものにそこまで価値を感じていなかったんです。感じないようにしていたというか。それは、「自分の行っている活動に価値がある」なんて思い上がりをしないよう、自分の中でブレーキをかけていたのが大きいんですが。

コミュニティって、明確に形があるわけじゃないから、とらえどころがない。資本主義的な価値観から言っても、価値はそれほど感じられない。お金が儲かるかというと、そうではありませんから。

瀧田 そうですね(笑) 。お金を儲ける道具と考えてしまうと、コミュニティってうまくいきません。

白石 そういう意識を常日頃から持ち続けることで、コミュニティというものに価値を感じるという感覚を封じてたんですね。でも、自分がコミュニティリーダーを離れて、少し離れたところからコミュニティというものを考えられるようになって、ようやく価値を実感し始めたというところなんです。

なくてはならないものというか、価値うんぬんは関係なく、人間がたくさんいる限り自然に発生するものというか。そしてそういうコミュニティを作り、運営するという点については確実にスキルや経験が問われる要素がある。

そういう点では、瀧田さんがMozilla Japanを通じてオープンソースコミュニティを支えてきたという経験は、何物にも代えがたいものなのではないか…なんて思いながら聞いていました。

瀧田 Webの価値って、結局人なんですよね。人と人がWebを通じて繋がっている、そこにこそWebやインターネットの価値があるんです。Mozillaはブラウザというプロダクトを通じて、またオープンソースコミュニティを通じて、人と人を結びつけました。そこにはきっと、テクノロジーの流行り廃りを超えた普遍的な価値があると思います。

白石 そうした価値こそが、WebDINOが体現していくものなのかもしれませんね。お忙しいところ、本日はどうもありがとうございました。大変楽しかったです。

本記事は、2017/5/23, 24に開催された「de:code 2017」の1セッション、「War is over : ブラウザエバンジェリスト達とWebの未来を語ろう」を聴講したレポートです。

GoogleやMozillaのエバンジェリストたちがマイクロソフトのセッションで仲良くお話、って光景を見るだけでも楽しいセッションでした

左からMozilla Japan 技術戦略マネージャ 浅井智也氏、Google デベロッパーアドボケート 北村英志氏、日本マイクロソフト デベロッパーエヴァンジェリズム統括本部 物江修氏

Web Payments, WebVR, Web Assembly, Progressive Web Appsについてエバンジェリストたちが語る

Web Payments

物江 まず、Web Paymentsについてお聞かせ願いたいのですが、こちら北村さんご説明をお願いできますか？

北村 まず前提として、インターネットを利用する際に私たちがクレジットカードを利用するようになってから、それなりに時間が経過しましたね。そして現在転換期が訪れているといっていいのではないかと思います。これまでのように、フォームにクレジットカードの情報を生で入れて送信するというので、本当にいいのだろうか。

そうした問題を解決すべく提案されているのが、Payment Request APIです。他のサードパーティ製アプリに遷移して戻ってくるなどのUIを通じて、決済に必要な情報を、スムーズにユーザーに対して問い合わせることができます。

（筆者注: Payment Request APIの日本語による解説記事） （筆者注: よりシンプルな Web の決済方法 : Payment Request API の紹介）

Google デベロッパーアドボケート 北村英志氏

物江 なるほど。このPayment Request APIですが、Edgeではバージョン15からサポートしていまして、Creators Updateを適用したWindows 10上ではすでに利用可能です。Firefoxでのサポートは行われる予定があるんでしょうか？

浅井 はい、時期はまだ言えないのですが、サポートするのは確定しています。

北村 Chromeは現在Android版のみ対応していて、デスクトップ版は開発中です。

物江 あと、iOS版のChromeについても教えていただけますか？

北村 iOS版Chromeは、iOSのWebViewを使っていて、iOSのWebViewはPayment Request APIに対応していません。なので、そのままだとiOS ChromeではPayment Request APIは使えないのですが、実はこれを無理やり使えるようにしてしまおうという計画がありまして。

どう実現するかというと、ChromeからWebViewに対して機能を注入してしまうんですね。WebViewで通常使えないJavaScript APIを使えるようにしてしまう。Cordovaとかでは以前から普通に行われていたことです。

これまではiOSのWebViewに対してJavaScriptをインジェクトして、新しいAPIを使えるようにするということはしてきませんでした。なので、iOS版のChromeにとっては大きな方針転換でもあります。

物江 このように、各種のプラットフォームでサポートがすでに始まっていますので、今年中か、もしくは来年の初めくらいには、一般的に使えるAPIになってそうですね。

浅井 個人的には、（Mozillaの前身である）Netscapeが切り開いた商用インターネットの世界が、ようやくここまで来たか…と感慨深いものがあります。

WebVR

物江 では次はWebVRについてお聞きしていきましょう。WebVRについては、先日のCreators Updateから、1.1のAPIをサポートしはじめました。また、Babylon.jsやA-Frameといったライブラリを使うと、WebVRを簡単に扱うことができると。

浅井さん、A-Frameについて教えていただけますか？

浅井 A-Frameは、Web上で簡単にVRを扱えるようにすることを目指すライブラリです。例えば、HTMLタグを一つぽんと置くだけで360度画像を表示できるようにするとか。

Unityだとアセットストアがあって、アセットを購入したりすることができるのですが、それと同じようなエコシステムがコミュニティ主導で進められているのも特徴です。非常に簡単に3Dコンテンツを作れて、売り買いしながら作っていけるエコシステムができていくだろうと期待しています。

Mozilla Japan技術戦略マネージャ 浅井智也氏

物江 コンテンツで思い出したんですが、意外とWeb上で3Dを扱うような仕事ってまだ少ないらしいんですよね。WebGLがモダンブラウザ全部でサポートされるようになってから結構経つのに、WebGLってどこかゲーム用途のイメージも強いみたいで。

ただWebGLって、本来ゲーム以外の用途もたくさんあるはずなんです。例えばGrimoire.jsっていうライブラリがあるんですが、これは様々な3Dコンテンツを、簡単にWeb上で扱えるようにすることを目的としていて、こういう動きが盛り上がると、WebGLってもっと活用されるんじゃないかと思う。

浅井 その点VRは、コンテンツを中心とした盛り上がりも活発で、結構未来があるんじゃないかな、と思いますね。

物江 ちなみに、VRではなくてMR (Mixed Reality) でいうとHoloJSっていうのもあって、HoloLens用のアプリを作ることもできます…すごく大変なんですけどね(笑)。

ところでChromeも、WebVRには対応済みですよね。何か最近の動きとかを教えていただけますか？

北村 そうですねー、Daydream上でChromeを立ち上げることができるようにする、というのは聞きましたね（筆者注: VR/AR空間内でChromeを立ち上げられるように、ということだと思われる。参考: Chrome is coming to augmented reality and Google Daydream (TechCrunch)）。

WebAssembly

物江 では次は、WebAssemblyのお話を聞かせてください。やはりここは、（WebAssemblyの元になったasm.jsの開発元である） Mozillaの浅井さんにお聞きしようかと。

浅井 はい、WebAssemblyの元になったのはasm.jsという技術です。 もともと、JavaScriptは動的な言語なので、パフォーマンスの向上にも限界がある。そこで、JavaScriptのサブセットとしてasm.jsが提案されたんです。 変数の型が厳密に定義されており、さらに実行に先立ってコンパイルが可能なので、相当に速かった。

WebAssemblyは、さらにそれをコンパイル済みのバイナリとして配布できるようにする技術です。そのバイナリフォーマットに関する仕様がWebAssemblyです。実行速度は相当なもので、現在でもC言語の速度まであと20%というところまで迫っています。

物江 FirefoxやChromeではすでに対応済みなんですよね。Edgeでも、フラグをONにすると使えるようになります。 個人的にはJavaScriptを置き換えるようなものではなく、高機能な計算が必要なところに使うものだと思っていますが、合ってますか？

浅井 はい、そうだと思います。WebAssemblyに出力するのも、基本的にはC/C++やRust言語で書かれたものになりますし。

物江 ちなみに、WebAssemblyへのコンパイルって具体的にはどうやるんですか？

浅井 EmscriptenとBinaryenというツールを組み合わせて、C/C++のコードをWebAssemblyに変換する…というのが一般的ですね。基本的には、LLVMの中間言語が出力できれば、そこからEmscriptenを使ってasm.jsに変換でき、更にBinaryenでWebAssembly化できます。

（筆者注: https://github.com/kripken/emscripten/wiki/WebAssembly も参考のこと）

Progressive Web Apps

物江 昨今のWebの重要キーワード、Progressive Web Appsですが、これは北村さん説明をお願いできますか？

北村 はい。その前に、Progressive Web Appsって、ご存じの方どれくらいいます？…思ったより浸透してないですね。まだまだだな。

Progressive Web Appsっていうのは、一言で言うとモバイルウェブの新しい形です。

• Webサイトがホーム画面から起動できる
• プッシュ通知
• オフラインで動く

北村 百聞は一見にしかずで、twitter.comをAndroid 版 Chromeで開いてみるというのが一番わかりやすいと思います。 これはTwitter Liteと呼ばれていて、動作も素早いし、モバイルアプリと使い勝手はほとんど変わりません。

浅井 PWAは、アプリに比べてデータ通信量も抑えめになるそうです。例えばTwitter Liteではアプリに比べて70%データが削減できるとか。なので、ブラジル、インド、インドネシアといった、ネットワークインフラの整っていない新興国では、アプリよりもユーザのコンバージョン率が高く、採用も広まっているようです。

物江 Firefoxでの、PWA対応はいかがでしょう？

浅井 現在でもホーム画面へのインストールなど基本機能は対応していますし、今後フルスクリーン起動なども順次実装を進めていくそうです

物江 モバイルといえばネイティブアプリ、という印象はいまだに根強いですが、モバイルサイトも同時に構築できてしまうので、環境が整って利点が正しく理解されさえすれば、一気に広まりそうですよね。PWA対応していないブラウザでアクセスしたとしても、通常のWebアプリとして使えますし。

ちなみにEdgeでは、今年の夏頃から開発者向けのビルドでPWAを試せるようになります。年末ぐらいまでには、メジャーブラウザでは全体的にPWAが使えるようになりそうですね。

北村 ちなみにマイクロソフトさんの検索エンジンのBingが、PWAを見つけたらWindows Storeに並べてしまうようになるというのを最近知って、すごい荒業だけどこれは面白いなと思いました。

PWAって捉えどころがないふわっとした用語ではありますが、実際には個々の技術それぞれにもすごく価値があります。オフラインやプッシュ通知がWebアプリで行えるというのは、Ajax以来の技術的な革命じゃないかと思いますね。

Web Components

物江 そろそろお時間も迫ってまいりましたので、最後のトピックです。 Web Componentsについて語りたいのですが、北村さん、Web Componentsのご説明をお願いできますか？

北村 Web Componentsっていうのは、一言で言うと、自分でHTMLタグを作れるという技術です。そして、自作したタグ（コンポーネント）を配布できる。

Web Componentsは、最近だとSafariに搭載されたのが大きいですね。iOSを含め、割とどこでも使えるメジャーな技術になりました。

あともう一つ、AMP (Accellalated Mobile Pages）も実はWeb Componentsを使っています。AMPに対応しているサイトは、現時点でもかなりの数に上りますので、実際にはWeb Componentsはすごい勢いで広まっていると言っていいんじゃないかと思います。

物江 Polymerというライブラリもあるそうですが、それとWeb Componentsの関係はどのようなものでしょうか？

日本マイクロソフト株式会社 デベロッパーエヴァンジェリズム統括本部 物江修氏

北村 Web Componentsっていうのは、W3Cで標準化が進められている技術なんです。具体的には4つの技術から構成されています。

Custom Elementは、先程申し上げたように独自のタグを作ることのできる技術です。

Shadow DOMは、DOMのカプセル化を行えるようにする技術。

Template Elementっていうのは、「テンプレートである」という意味合い以外持たないHTML要素です。

HTML Importというのは、JSやCSSのように、HTMLもインポート可能にするという技術です。

一方でPolymerというのは、Web Componentsの上に構築されたライブラリです。

Web Components標準はそれほど高いレベルのAPIを提供しません。なので、実際にコンポーネントを作ろうとすると、実装の重複が多くなります。その重複を排除して、最小限のコードでコンポーネントを作れるようにするのがPolymerです。

物江 ちなみにEdgeは、Web Componentsについては長いこと意識しているようですが、まだ詳細は未定です。Polymerを使うと、現在のEdgeでもWeb Componentsが動作したりするんでしょうか？

北村 はい、PolymerはPolyfill（対応していないブラウザ上でAPIのエミュレーションを行うライブラリ）も含んでいますので、動作しますね。実は、現在のYouTubeサイトはWeb ComponentsベースのHTMLに全て書き換えられているんです。コードを見てみると面白いと思いますよ。

あと、Polymerはライブラリだけじゃなくてコンポーネントも提供しているんです。 http://webcomponents.org/ を見てみると、すでにいろんなコンポーネントが利用できるのを確認できると思います。

まとめ

物江 では、このディスカッションの締めくくりとして、Webの今後について一言ずついただけますでしょうか？

浅井 はい、モバイル時代は長らくネイティブアプリが中心でしたが、ここに来てWebの力が盛り返してきているのを感じています。ネイティブアプリと遜色ない機能を提供できるだけではなく、ユーザーにリーチするのも、アプリストアよりもWebのほうがハードルが低い。リンクを送るだけでプロモーションできますしね。そういう点で、PWAには期待しています。

北村 PWAについては、ぼくも同じく期待しています。とりあえずTwitter Liteを触ってみてほしいですね。

あとWebの今後という点で思いついたのですが、企業の枠組みを超えた合意形成の方法としては、Webはかなり進んでいるんじゃないかと思います。ディスカッションの場作りとか、標準化を行う上で蓄積されたノウハウはかなり貴重で、他の場面や業界にも活かされていくんじゃないかな…と考えています。

物江 ではそろそろお時間ですので、本セッションを終わりとしたいと思います。みなさま、本日は大変興味深いお話を、どうもありがとうございました。

こんにちは、清水です。先日のHTML5 ConferenceでFirefox OS上で動作するアプリの開発と、Firefox Marketplaceの公開に関する講演をさせていただきました。今回はその講演内容のうち、アプリ作成に関する部分を重点的に説明します。

すべてWeb技術で

Firefox OSの特徴は、ユーザの目にする部分は全てHTML5で実装されている点にあります。音楽アプリ、カメラ、ギャラリーといったプリインストールされているものはもちろん、ダイヤラーや、SMS、スマホのロックスクリーンや、ホーム画面といったシステムよりのアプリもすべてHTMLとJavaScript、CSSだけで実装されています。

Firefoxをインストールして、開発スタート

Firefox OSのアプリ開発に必要なことはただ一つ、Firefoxのインストールです。開発者アカウントの作成も、ディベロッパープログラムへの登録も、専用SDKのインストールも必要ありません。

FirefoxにはWebIDEという機能があります。これはアプリ開発ツールとして必要な機能を一通り持っています：

• ファイルの作成・編集機能、シンタックスハイライト
• デバッガ、インスペクタ
• シミュレータの起動、
• 実機との接続管理、アプリの転送機能

リリース版のFirefoxでも十分開発に耐えますが、開発をするなら Firefox Developer Editionの利用をお勧めします。Mozillaの提供する開発者向けの機能をいち早く利用できる点が特徴です。

Firefox Developer Editionは、リリース版とは異なる場所にインストールされます。また初回起動時に開発用のプロファイルを作成するため、リリース版との併用が可能です。Firefox Syncを利用して同期しておけば、ブックマークや履歴、パスワードは通常利用しているものと共有できます。

Hello World!

ではさっそく、WebIDEを利用してHello Worldしてみましょう。Firefoxのメニューから「Web 開発」→「Web IDE」と進んでWeb IDEを起動します。起動すると次のような画面が表示されます。

画面の左上にある「アプリを開く」をクリックすると展開されるメニューから「新規アプリ」を選びます。

選ぶとテンプレートの選択を求められます。「HelloWorld」テンプレートを選び、プロジェクト名にアプリの名前を入力して、「OK」ボタンを押すとアプリのテンプレートが作成されます。

シミュレータのインストール

次にシミュレータをインストールします。シミュレータはブラウザのアドオンとして提供されています。画面右上のメニューから「シミュレータをインストール」を選び、表示された画面の中から開発を行う Firefox OSのバージョンに合わせたシミュレータをインストールします。

KDDIから販売されているFirefox OS端末、Fx0はFirefox OS 2.0で動作しています。国内向けにアプリを書く場合は、Firefox OS 2.0のシミュレータをインストールするとよいでしょう。

アプリの起動と修正の反映

作成したテンプレートを、インストールしたシミュレータ上で実行します。WebIDE上部にある「実行ボタン」を押すと、実行できます。

実行すると、次のような画面が表示されます。

このテンプレートでは、起動時にindex.htmlが表示されます。これを次のように修正します。

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,user-scalable=no,initial-scale=1">
    <title>Hello World</title>
    <link rel="stylesheet" href="app.css">
    <script src="app.js" defer></script>
  </head>
  <body>
    <h1>こんにちは世界！</h1>
  </body>
</html>

また、app.jsを次のように修正すると、アプリのロードが終了した時点でアラートダイアログが表示されます。

window.addEventListener("load", function() {
  alert("Hello World!");
});

WebIDEの実行ボタンをもう一度押すと、これらの修正が実行中のアプリに反映されます。

アプリの構造

テンプレートに従って作成されるファイルは以下のような構造をしています。

HTMLやJavaScriptに加えて、”manifest.webapp”というファイルがあります。これはアプリに関するメタデータで、これはアプリのインストールや、Mozillaの提供するアプリストアであるFirefox Maretplaceにアプリを登録時に参照されます。

manifest.webappの実体は次のようなJSONファイルです。

{
  "name": "こんにちは世界",
  "description": "A Hello World app",
  "launch_path": "/index.html",
  "icons": {
    "16": "/icons/icon16x16.png",
    "48": "/icons/icon48x48.png",
    "60": "/icons/icon60x60.png",
    "128": "/icons/icon128x128.png"
  },
  "type": "privileged",
  "permissions": {}
}

各項目の詳細については、Mozilla Developer Networkのアプリマニフェスト をご覧いただくのが確実ですが、上記の例にある項目は以下のような意味を持ちます。

以上のように、HTML、CSS、JavaScriptにmanifest.webappを足したものが、Firefox OSアプリの最小構成となります。

Firefox OS で利用できる API

Firefox OS のアプリは、すべてJavaScriptで記述します。そのため カメラやGPSといったセンサー類へのアクセスや、バイブのコントロール、SDカードへのデータ保存などは、HTML5で利用できるAPIを通して行います。利用できるAPIの一部分を挙げると、以下のようになります。

• Ambient Light Sensor API：環境光センサーを利用して周囲の照度を取得できる
• Geolocation API：端末の物理的な位置を取得できる
• Vibration API：ゲームなどのフィードバックのために、バイブレーションをコントロールできる
• Camera：デバイスに内蔵されたカメラを利用して動画や、写真を撮影できる
• Contacts：連絡先データベースへのアクセスが可能になる
• Device Storage：SD カードなど、端末の持つストレージに対して読み書きが行える

例えばDevice Storage APIを利用して、SDカード中のファイルをすべてコンソールに出力するプログラムは、次のようになります。

var sdcard = navigator.getDeviceStorage("sdcard");
var cursor = sdcard.enumerate();
cursor.onsuccess = function(){
  var file = this.result;
  console.log(file.name);
  if(!this.done){
    this.continue();
  }
};

WebActivities：アプリの機能を利用する API

音楽のライブラリや、写真のギャラリー、カメラでの撮影といった機能を実装する方法は2つあります。1つは上記にあげたAPIを利用して1から機能を作る方法、もう1つはWebActivitiesを利用して他のアプリを呼び出す方法です。

標準でインストールされている音楽アプリや、ギャラリー、カメラアプリは、「ライブラリから音楽の選択する」「ギャラリーから写真を選ぶ」「写真を撮る」といったアプリの機能の一部を他のアプリから利用できるようになっています。

これを利用しているアプリの例には、Cameran があります。Cameranは写真にフィルタや効果を追加するアプリなのですが、自分で写真撮影や管理機能を実装しているのではなく、インストールされている他のアプリの提供する「画像を選ぶ機能」を利用しています。

他のアプリが提供している機能を、自分のアプリから呼び出して利用するためのAPIが、WebActivitiesです。例えば、他のアプリが提供するJPEG形式の画像を選択する機能の呼び出しは、次のようにWebActivitiesを利用して実現できます。

var activity = new MozActivity({
  name: "pick",
  data: {
    type: "image/jpeg"
  }
});
activity.onsuccess = function() {
  var picture = this.result;
  console.log("A picture has been retrieved");
};

尚、WebActivitiesを利用して呼び出せるのは機能の名前であって、アプリではありません。おなじ名前の機能が複数のアプリから提供されている場合、どのアプリを利用するかはユーザの選択に任されます。

WebActivitiesの詳細、特に標準でインストールされているシステムアプリが提供する機能名については、Mozilla Developer Network の Web アクティビティをご覧ください。

アプリケーションの権限

上記のAPIすべてを、アプリから利用できるわけではありません。強力なAPIの利用には、それに見合った権限が必要となります。

Firefox OSのアプリは権限に応じて次の3つに分類されます。

• 一般のアプリ (type:web)
• 特権アプリ (type: privileged)
• 内部アプリ (type: certified / internal)

最後の内部アプリ、以前は認定アプリ (Certified App)と呼ばれていたアプリは、キャリアもしくはそれに準じるベンダしか作成を許されていません。そのため私たちが作成するアプリは、一般アプリもしくは特権アプリのどちらかになります。

権限と、利用できるAPIの対応関係は、OSのバージョンによって異なります。対応関係はWebIDEの「許可設定一覧」で確認できます。

許可設定一覧は以下のようになっています。

✓は利用可能、✕ は不可能、! は利用可能だが利用時にユーザに対して通知されることを表しています。

以下の例では、Camera APIを利用するためには、アプリを特権アプリとしなければならないことがわかります。

実際に作ってみよう

以上がFirefox OSアプリの概要でした。これを踏まえて、ボイスレコーダーアプリの作成を例に、アプリの作成例をみてみましょう。

今回作成するアプリは次のような1画面のアプリとなります。画面をタップすると録音を開始し、もう1度のタップで録音を終了します。録音した音声は ogg ファイルとして音楽ライブラリに保存されるものとします。

なお今回作成したサンプルは、 gistで公開しています。 こちらもご利用ください。

使用するAPIとアプリの権限

今回は次のAPIを利用します。

DeviceStorage APIを利用するためには、アプリの種別を特権アプリとする必要があります。またいくつかのAPIを利用するためには、manifest.webappのpermissionsの項目に記述を行う必要があります。そのため manifest.webappを以下のように記述します。typeと permissionsの項目が、それぞれ設定されていることを確認してください。

{
  "name": "audio-caputre-sample",
  "description": "An sample app to capture audio through microphone",
  "launch_path": "/index.html",
  "icons": {
    "16": "/icons/icon16x16.png",
    "48": "/icons/icon48x48.png",
    "60": "/icons/icon60x60.png",
    "128": "/icons/icon128x128.png"
  },
  "type": "privileged",
  "permissions": {
    "audio-capture": {
      "description": "To record audio"
    },
    "device-storage:music": {
      "description": "To store captured audio",
      "access": "readwrite"
    }
  }
}

HTML と CSS の記述

アプリのビューは HTML と CSS で定義します。今回のアプリでは次のものを利用しました。

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,user-scalable=no,initial-scale=1">
    <title>audio capture test</title>
     <script src="app.js" defer></script>
    <link rel="stylesheet" href="app.css">
  </head>
  <body>
    <canvas id="canvas"></canvas>
    <p id="recording">●REC</p>
  </body>
</html>

CSS は以下のようになっています。

body{
   margin: 0;
   padding: 0;
 }
 #canvas{
   width: 100%;
   height: 400px;
   margin: 0;
   padding: 0;
   box-sizing: border-box;
 }
 #recording{
   color: red;
   position: fixed;
   top: .5em;
   left: .5em;
   display: none;
 }

JavaScript を使った録音

コードの全体像は gist に公開したものをご覧いただくこととして、 ここではマイクからの入力ストリームの取得、録音、そしてファイルへの出力部分について解説します。

まずは、マイクからの入力ストリームの取得方法です。manifest.webapp中のpermissionsの項目に”audio-capture”を追加すると、 つぎのようにGetUserMediaを使っ、てマイクからの入力を扱うための入力ストリームを取得できます。

navigator.getUserMedia({video: false, audio: true}, 
                       streamAquired, 
                       error =>{
                         console.log(error);
                       });

この実行が成功すると、コールバック関数が呼ばれます。取得した入力ストリームは、関数の第1引数として与えられます。上記の例では streamAquired という関数が呼ばれます。この関数は入力ストリームを利用する様々なオブジェクトの初期化を行います。

ここで初期化されるオブジェクトの中には MediaRecorder オブジェクトがあります。初期化は次の様に行われています。

var initRecorder = function(stream){
  recorder = new MediaRecorder(stream);
  recorder.ondataavailable = (event) => {
    console.log(event); 
    if(storage != null){
      var filename = createFileName(event);
      console.log("attempt to save as " + filename);
      var req = storage.addNamed(event.data, filename);
      req.onsuccess = function(){
        console.log("saved as " + this.result);
      };
      req.onerror = function(){
        console.log(this.error.name);
      };
    }
  };
};

MediaRecorderオブジェクトは、その名の通りメディアデータの記録を行うオブジェクトです。startメソッドを実行すると記録を開始し、stopメソッドを実行すると記録を停止し、記録したデータを用意します。データの用意できると、dataavailableイベントが発生します。用意されたデータは、dataavailableのdata属性でBlobとして参照できます。

上記の例では取得したBlobオブジェクトを、DeviceStorage APIのaddNamedメソッドを使って保存をしています。ここで利用しているstorageオブジェクトは次の様に作成されています。

var storage = navigator.getDeviceStorage("music");

これは音楽データ用のストレージを取得しています。取得できるストレージの種類は次の4種類です。これ以外にもappsというアプリ用ストレージがありますが、これはシステムアプリからのみアクセスが許可されており、我々の作成するアプリは操作できません。

取得したストレージに対してメソッド呼び出しを行うと、DOMRequestオブジェクトを返します。このオブジェクトのonsuccess属性やonerror属性に関数を登録することで、その操作が成功したか、失敗したかを知ることができます。上記の例では単に成否をログに出力しているだけですが、エラー処理が必要な場合などは、こちらにその処理を記述することになります。

気軽に作ろう！

以上 Firefox OSアプリの構成と作成方法について概観しました。

Firefox OSに向けたアプリの作成についてまとめると、次の3点になるかと思います。

• Firefoxがあれば開発をはじめられる
• Firefox OSアプリ = HTML + JS + CSS + manifest.webapp
• ライブラリの追加なしで、ハードウェアをコントロールできる

とにかく開発を始めるための敷居が低く、HTMLや CSS、JavaScriptといったWeb標準技術のみで、ハードウェアへアクセスし、コントロールするようなアプリが作れます。

しかもブラウザエンジンがOSに組み込まれているため、作成したアプリのコンパイルやビルドが必要ありません。Webページを作るように、修正したアプリを再読み込みして即座に実行できます。また本文中では解説しませんでしたが、実機へのアプリの転送やデバッグもシミュレータと同様の手順で行えます。

このように開発の敷居が低く、簡単にアプリを作り始められるFirefox OSで、みなさんも作る自由を謳歌してください。

当日のセッションの動画・スライドは、こちらからご覧ください。

Youtube / Slideshare

参考資料

• Firefox Developer Edition
• Firefox OS
• Mozilla Developer Networkのアプリセンター
• WebAPI
• GetUserMedia
• DeviceStorage API
• MediaRecorder API
• Web Audio API
• アプリマニフェスト

Firefoxで使えるWeb開発用のツールといえば、Firebugが有名です。FirebugはFirefoxのアドオンとして提供されており、利用するためには追加のインストールが必要です。ところで、インストールの必要がない開発ツールがFirefoxに付属していることをご存知でしたか？

今回から3回にわたって、Firefoxに標準付属の開発ツールをご紹介します。初回は開発ツールの持っている機能を概観します。

起動方法

まずは起動方法からご説明します。画面の左上にあるハンバーガーアイコンをクリックして表示されるメニューの中に開発ツールがあります。これをクリックすると、メニューがスライドします。この中から「開発ツールを表示」を選ぶと開発ツールが起動します。

起動すると以下のような画面が表示されます。上部にあるタブを切り替えることで、個々の機能を利用できます。

タブの左右にはいくつかのボタンが配置されています。設定に関するものは左側、機能に関するものは右側にまとめられています。

開発ツールの持つ機能

開発ツールはさまざまな機能を持っています。

上記の機能の中から、今回は代表的なもの4つを取り上げ、簡単にご紹介します。

ページインスペクタ

開発ツールで必要とされる機能といえば、まずDOMのインスペクタです。「インスペクタ」と書かれたタブをクリックすることで、表示できます。

DOMツリーの表示、適用されているCSSの表示、計算済みの値の一覧といった基本的なことはもちろんできます。ボックスの幅や高さ、マージンといったサイズに関する情報は「ボックスモデル」として確認できます。ボックスモデルは開発ツールの中で見ることもできます。また描画されたページにオーバレイする形でも表示されます（2014年5月の時点ではベータ版で利用可能）。

使用されているフォントや、色が実際に目で見て確認できるというのも、細かいことながら便利な機能です。色サンプルをクリックすることで、カラーピッカーが表示されます。カラーピッカーで選んだ色が、ページの描画結果へ動的に反映されます。

スタイルエディタ

ページの描画結果を確認しながら、要素やスタイルを編集できるのがFirefoxの大きな特徴です。その特徴がよく現れているツールがスタイルエディタです。CSS向けのエディタですが、編集内容が表示中のページの描画結果へ即座に反映されます。

コード補完も強力です。CSSのプロパティだけでなく、whiteやblackといった値も文脈に応じて補完します。またセレクタも補完します。タグ名はもちろんですが、表示しているページのid属性値やclass属性値などを使ってセレクタを補完できます。　

編集結果はファイルへ出力できます。既にあるCSSファイルを、レンラリング結果を見ながら修正しファイルへ出力、といった流れでスタイルの修正が効率的に行えます。

Webコンソール

ページインスペクタと同程度よく使われる機能がWebコンソールだと思います。

ここには様々なログが出力されます。console.log経由で出力されるもの以外にも、CSSやJavaScriptのエラー、通信の状況などが出力されます。出力するログは画面上部、ツールバー中のボタンをトグルすることで、フィルターできます。

要素の追加、削除、:hoverのような疑似クラスのアクティブ化といったことで起きるページの再秒にかかった時間も出力されます。ツールバーのCSSボタンををクリックして、ログを選択することで再描画時間が表示されます。この再描画がJavaScriptによって発生した場合、発生源のコード行へのリンクも表示されます。

JavaScriptデバッガ

JavaScriptデバッガはその名の通り、JavaScriptをデバッグするツールです。デバッガタブをクリックして利用できます。一般のデバッガ同様、ブレークポイントの設定や、ステップ実行、各スコープ内の変数値の確認、ウオッチ式の設定などが可能です。

ブレークポイントは行に対して設定できるほか、DOMイベントに対しても設定できます。以下のようにリスナが割り当てられているイベントの一覧の中から、ブレークさせたいイベントにチェックを入れます。チェックが入ったイベントが発生すると、そのリスナの視点で実行がブレークされます。

ミニファイされたJavaScriptファイルをデバッグする際には、ファイルの整形機能が便利です。画面左下にある大括弧の書かれたペアをクリックすると、ミニファイされたファイルがが読みやすく整形されます。

まとめ

Firefoxで利用可能な開発ツールは、Firebugが有名です。こちらもMozillaの製品で、豊富なプラグインが特徴です。特定のライブラリに対する開発を行うなら、Firebugとそのプラグインを利用する方が効率的に行える場合もあります。

これに対し、今回ご紹介した開発ツールは、オーサリングツールという側面も持っている点が大きな特徴です。編集が描画内容にその場で反映されるだけでなく、コード補完機能やシンタックスハイライト、行番号の表示と言ったエディタとして必要とされる機能も備えているため、単なる修正だけでなく、スクラッチからの作成にも耐えるものとなっています。

Firefoxの開発ツールの概要を、駆け足で見てきました。今回ご紹介したもの以外にも様々な機能を持っています。詳細な情報、使い方については Mozilla Developers Network (MDN) 内の記事をご覧ください。今回の記事をきっかけに、Firefoxを開発ツールの選択肢に入れていただければ（そしてメインの開発ツールにしていただければ！）幸いです。

それでは実際、レスポンシブ・ウェブとは何についての対応（レスポンシブ）なのでしょうか。

現在のところ、私たちがいうレスポンシブ・ウェブデザインとは、どんなスクリーンの幅や表示領域、デバイスの画面解像度や画面の縦横の向きにも対応したウェブデザイン、というのが事実上の定義となっているようです。

そこで今回、私はその定義を超えたレスポンシブ・ウェブのユースケースについて考えてみました。

太陽光下でのスクリーン・リーダビリティ

私は普段の仕事ではNokia Lumiaというスマートフォンを使っているのですが、これがなかなかの優れもの。環境光センサーでスクリーンの輝度値を自動調整してくれるので、晴天の空の下でもスクリーンのコンテンツがはっきり読めるのです。ところが私の個人用で使ってる別機種の場合、そうもいきません。例えば読みたいウェブがたとえ「レスポンシブ」であれ「モバイル・ファースト」であれ、まぶしいカリフォルニアの空の下では、全くコンテンツが見えないので使い物にならないのです。

一方、W3CのCSSメーリングリストでは、次世代のCSS Media Queries 4のひとつである

luminosity

しかしこれが実現するのは一体いつの日になることやら…

Ambient Light Events API

というわけで、今現在のブラウザでは、CSSを使って環境光の度合いに合わせてウェブのUIを調整するのは不可能。

しかし私たちには、HTML5を使ってブラウザから各種センサーやカメラなどのハードウェアが持つ機能にアクセスするための仕様、デバイス APIのひとつであるAmbient Light Eventsがあるでないですか！
これならJavaScriptを使って環境光センサーから照度を知ることができるはず。これを使えば、次世代メディアクエリをまねて、太陽や照明にレスポンシブなウェブが作れるかもしれない！
そう思って私は、実験的に簡単なデモを書いてみました。

Devicelight events

デバイスのセンサーが照度の変化に反応すると、ブラウザ側では

DeviceLightEvent

devicelight

そこで得られるプロパティの値、

value

実際、大変簡単にこう書くことができます。

window.addEventListener('devicelight', function(event) {
  console.log(event.value + 'lux');
});

照度にレスポンシブなウェブを作ってみる

これを使って、環境光が変わってもウェブの内容を読みやすくするためのUIを考えてみました。

デフォルトではライトグレーの背景に黒の文字、明るい照度の時には白地に黒の文字、そして暗い時には暗めな背景に白の文字、というUIにしてみましょう。

例のAPIを使って、照度によってコンテンツのコンテイナー（このデモではわかりやすいように

document.body

window.addEventListener('devicelight', function(e) {
  var lux = e.value;

  if(lux < 50) {
    document.body.className = 'dim';
  }
  if(lux >= 50 && lux <= 1000) {
    document.body.className = 'normal';
  }
  if(lux > 1000)  {
    document.body.className = 'bright';
  } 
});

body,
body.normal {
  background-color: #ddd;
  color: #111;
}
body.dim {
  background-color: #444;
  color: #fff;
}
body.bright {
  background-color: #fff;
  color: #333;
}

実際に、このデモが動いている様子がわかる動画を作ってみました。

ブラウザサポートとデバイス

このデモで使われた実際のソースコードは、CodePenを見てください。

ほとんどの方の観覧しているブラウザ上では “AmbientLightEvent is not supported.” というメッセージが出ていて何も起こらないのではないでしょうか。というのも、残念ながら今のところ、このAPIをサポートしているのはFirefox 22+ だけ、しかもデバイス側にも環境光センサーが必要。
ですので、デスクトップから見ている皆さんには、どのブラウザを使っていてもこのデモは作動していないでしょう。私のデモで実際に使ったデバイスはNexus 7ですので、AndroidやFirefoxOSのデバイス持っている方は、ぜひFirefoxで試してみてください。

イベントが返す値も、デバイスによってばらつきがあるようです。私が実験した機種2機ではずいぶん違う結果が出ました。たぶんセンサーの精度にブレがあるのでしょう。

この写真にあるデバイスは、Moto G(Android)と、Keon(FirefoxOS)です。暗めの部屋での照度が、一方が6lux、もう一方が61luxとなっています。

CSS Media Queries Level 4 Luminosity

さて、話題をメディアクエリに戻します。
今現在の仕様では、メディアクエリ・レベル4はまだeditor’s draftの段階なので、ブラウザに実装されるまでにはまだまだ時間がかかりそうです。

将来的に実装された際には、このデモで書かれたコードはCSSのみでこのように書き直すことができるようになります。

@media screen and (luminosity: normal) {
  body {background-color: #ddd; color: #111;}
}
@media screen and (luminosity: dim) {
  body {background-color: #444; color: #fff;}
}
@media screen and (luminosity: washed) {
  body {background-color: #fff; color: #333;}
}

このように、

luminosity

おわりに

近い将来、レスポンシブ・ウェブの定義も、デバイスなどの多様性に合わせて変わってくるのではないでしょうか。このユースケースも実際果たして本当に役に立つのかどうかもまだわかりませんが、発想の転換とブラウザの新しい可能性、という面でこの記事を楽しんでいただけたかと思います。

この記事は元々は私個人のブログ（原文は英語）に掲載したのですが、TwitterやReddit、Hacker Newsで思いのほか話題になりました。やはりディベロッパ、デザイナは国境を問わず、みな新しい可能性に興味津々なのでしょう。

では。

今月より、ブラウザ関連のニュース、とりわけレンダリングエンジンに実装されたWebプラットフォーム機能について取り上げる月一の連載を開始したいと思います。1月も後半ですが、2013年12月の話題を取り上げます。

注：MozillaやChromeのコミットログを主な情報元としているため、ここで紹介する機能がすぐに使えるとは限りません。

Firefox ― CSS Variablesをはじめ、機能拡張いろいろ

12月に「おおっ」と思ったのは、Firefoxでした。CSS Variablesなど目を引く機能が追加されました。Multiline Flexboxや開発者ツールのCSS Source Mapsなど、これが入ってくれたら助かると思った機能もサポートされました。

CSS Variablesがサポート

CSS Variablesがサポートされました。Firefox 29以降でlayout.css.variables.enabledを有効にすると利用できます。

• CSS Variables in Firefox Nightly ✩ Mozilla Hacks – the Web developer blog
• CSS Variables in Firefox 29 • Cameron McCormack’s blog

CSS Variablesは、変数として利用可能なカスタムプロパティを定義する仕組みです。カスタムプロパティはvar-接頭辞付きのプロパティに値を設定し定義できます。カスタムプロパティの値は、var()内にプロパティ名を入れることで参照できます。

:root { var-foreground: #222; var-background: #eee; }

body { color: var(foreground); background-color: var(background); }

名前の通り「プロパティ」ですので、SassやLESSなどのCSSプリプロセッサの変数とは違い、宣言として書かなければいけません。定義と参照で表記が違う点も含めて、少しクセがありますね。宣言として書く都合上、グローバルな変数は:rootセレクタのブロックにでも定義するとわかりやすいかもしれません。

CSS VariablesはBlinkでもすでに実装されていますが、仕様が未成熟なため、フラグを有効にしなければ利用できません。またコードが管理されていないことから、先日WebKitから削除されたなど、対応状況もよくありません。

また、Mozilla Hacksのポストなどには、構文への不満や「Sassがあるのになぜ必要？」といったコメントも寄せられています。DOMからのアクセスができることや継承するなど、プリプロセッサの変数にはない優位性もあるのですが、なかなか理解されるのは難しいかもしれません。

スタイルの継承については、エキスパートの谷さんが書かれたCSS Variablesのエントリでも触れられています。

• CSSカスタムプロパティとMythの話 | inkdesign

input要素のnumber型が有効に

input要素のnumber型（type="number"）がAuroraとNightlyで有効になりました。問題なければFirefox 28から利用可能になります。

• input type=number coming to Mozilla | jwatt.org

number型は数値入力用のinput型です。実装されているデスクトップブラウザでは、入力ボックスの右側にスピナーコントロールが付き、値を増減できます。

Firefoxでのinput要素のnumber型。他のブラウザと同じくスピナーコントロールが用意されている

さて、今回の実装を担当したJonathan Watt氏のエントリにおいて、小数点がドット（.）のままでローカライズされないことが触れられています。HTML仕様では小数点はドットとなっているものの、小数点をカンマ（,）で表記する地域もあります。Watt氏のエントリには、チェコなどではカンマを使うため、現在の実装では使いものにならないといったコメントも寄せられています。フォームのローカライズはHTML仕様で推奨されているものの、その仕組みは定義されていません。まだまだ検討が必要ですね。

開発者ツールがCSSのSource Mapsをサポート

開発者ツールでCSSのSource Mapsがサポートされました。Firefox 29以降でdevtools.styleeditor.source-maps-enabledを有効にすると利用できます。Source MapsのサポートはChrome DevToolsでJavaScript, CSSどちらも対応していますが、Firefoxの開発者ツールでは、これまでJavaScriptのみの対応となっていました。

Firefoxの開発者ツールでCSSをインスペクトすると、Source mapsによってlessファイルにリンクされる

• mozilla-central: changeset 159842— Bug 926014 – Support CSS source maps

ブラウザの開発者ツールは、該当するスクリプトやスタイルのファイル・行数などを表示してくれますが、minify/compact化されたソースにはあまり役立ちませんでした。Source Mapsは、CoffeeScriptやSass/LESSなどでコンパイルされたJavaScript/CSSファイルと、もとのファイルの行数・桁目を対応させるマッピングの仕組みです。詳しい仕組みはHTML5 Rocksなどの記事をご覧ください。

• Introduction to JavaScript Source Maps – HTML5 Rocks
• An Introduction to Source Maps | Nettuts+
• An Introduction to Source Maps – Treehouse Blog

CSSのSource Maps出力はSass, LESSといったCSSプリプロセッサのほか、CSSポストプロセッサのAutoprefixerなども対応しています。

Multi-line Flexboxがサポート

Multi-line Flexboxは、複数行にまたがるFlexboxです。FirefoxでのサポートはFirefox 22からですが、Multi-line Flexboxのサポートが行われない限定的なものでした。今回サポートされたことによりかなり使えるものになりました。

• The Holbert Report: Multi-line flexbox support in Nightly and Aurora 28

Flexboxでは、flexアイテムの幅・高さがflexコンテナのそれよりも大きくなってしまう場合、そのままではFlexコンテナの幅・高さが自動的に調整されたり、overflowを引き起こしたりします。しかしflex-wrapなどのプロパティを使えば、複数行にまたがります。

ふつうのFlexboxとMulti-line Flexboxの違い。Multi-line Flexboxはflexアイテムの幅に応じて行送りがなされる（jsdo.itで見てみる）

他のエンジンでは、Blink, Tridentで接頭辞なしのサポート、Safariでは接頭辞つきのサポートが行われています。Firefoxの実装も接頭辞なしですので、Safari以外では接頭辞なしで利用可能です。バージョンごとの対応状況は、caniuse.comのFlexbox対応状況をご覧ください。

Chrome, Opera ― Element.matches()、DevToolsのUI改善

12月のBlinkは一足早く冬休みモードだったのか、そこまでコミットもなくおとなしい感じでした。

Element.matches()が実装

DOM仕様では、要素が特定のセレクタにマッチしているかを確かめるElement.matches()というメソッドが定義されています。何に使うのかというと、イベントのデリゲーションに使えます。地味ですね。これがBlinkに導入されました。Chrome 34から利用できます。

• 23ee357 (@163442) – chromium/blink — Implement Element.matches(selectors)

とはいってもこのAPI、もともとSelectors API Level 2仕様でElement.matchesSelector()として定義されており、各ブラウザもベンダー接頭辞付きで実装しています。ただ標準のElement.matches()はこれまで実装されていませんでした。Blinkは実装しましたが他のエンジンではとくに動きはなさそうで、引き続きベンダー接頭辞に悩まされそうです。

（注：上記のパッチはその後取り下げられましたが、1月13日に再び導入されました。）

DevToolsのネットワークパネル、コンソールで改善

DevToolsのネットワークパネルで表示されるバーが、画像ではなくCSSでの表示になり、Retina Displayをはじめとする高密度なディスプレイでの見栄えがよくなりました。Chrome 34から導入されます。

• 65b0dbf (@164362) – chromium/blink — DevTools: network log bars use CSS instead of pre-rendered images.

DevToolsのネットワークパネルを拡大。アイコンなど画像はぼけているが、バーはくっきりと表示されている

また、async属性付きで読み込まれたJavaScriptファイル内でdocument.write()を使っている場合、そのdocument.write()は実行できませんが、今回コンソールにエラーが表示されるようになりました。Firefoxの開発者ツールに倣ったようです。

• eaecd0c (@164310) – chromium/blink — DevTools: added console warning when call to document.write() from async script is ignored

async属性で読み込まれたJavaScriptファイル内でdocument.write()がある場合エラーが出るように

そのほか

機能追加だけではなんですので、その他のブラウザ関連の話題も取り上げてみます。

Advent Calendar

技術系のAdvent Calendarが今年もたくさん作られました。CSSプロパティやFrontrend、HTML5などWeb開発に関するものはどれも面白かったです。矢倉もいくつか寄稿させていただきました。

• CSS Property Advent Calendar 2013 – Adventar
• Frontrend Advent Calendar 2013 – Adventar
• HTML5 Advent Calendar 2013 – Adventar
• その他Adventarに登録されているAdvent Calendar（技術系じゃないものも多いです）

さて、ブラウザ関連ではInternet ExplorerのAdvent Calendarが異彩を放っていました。IEに特化したAdvent Calendarなんと2つも立てられたのです。

• Internet Explorer Advent Calendar 2013 – Adventar
• Yet Another Internet Explorer Advent Calendar 2013 – Adventar

他にブラウザ関連のAdvent CalendarはFirefox OS Advent Calendar 2013しかなかったです。Chromeとかがあってもおかしくなさそうなのに、ちょっと意外でした。

Operaのへんてこプレスリリース

OperaのCoastというiPad専用のブラウザが新しくなったようなのですが、その「プレスリリース」が面白かったです。

• Coast by Opera, now updated – Opera Software

プレスリリース本文の上にスライダーがあり、それを動かすことで文章量が変化し「プレスリリース風」になります。また「Geek edition」を押すと変更履歴風になったり、「Go full Corp!」を押すとバズワードわんさかなプレスリリースになったりもします。スライダーを動かすと単語がフェードインで現れたり、なかなか手が込んでますし、文章も書くのは大変ではなかったかと思います。しかしこういったユーモラスなものが、なぜこのタイミングで紹介されたのかはわからないです。

斉藤祐也の海外WEBテク定点観測＜Issue.7: 2013/10/01-2013/10/31＞

今月の定点観測はW3CがEMEをなぜ標準化したのか、その動きに対する反対と賛成意見を紹介し、AppCacheが解決できなかったオフラインに対する問題を解決すべく立ち上がったServiceWorkerの解説、突如として現れたかに見えるレスポンシブ・イメージに対する解決であるRespImgなど、合計20件の記事や動画などを紹介します。

注目ニュースピックアップ

W3CによるEncrypted Media Extensionの標準化について

今年5月にEncrypted Media Extension(EME)という仕様がワーキング・ドラフトとなり公開されました。
この仕様はなぜW3Cによって標準化されるべきものだったのでしょうか。あるいはW3Cの勇み足だったのでしょうか。
この一ヶ月、MozillaのCTOであるBrendan Eichも氏の立場を明らかにしたりと多くの議論が展開されました。 10月の議論の火付けとなったと思われるAmelia Andersdotter氏の記事を含め、EMEに関する記事を集約したので参考にしてください:

• What is EME?
• DRM/EME in HTML5 – an American thing by Amelia Andersdotter
• A hitchhiker’s guide to the HTML5 + EME maze by No Such Weblog
• The Bridge of Khazad-DRM by Brendan Eich
• Perspectives on Encrypted Media Extension Reaching First Public Working Draft by W3C Blog
• The W3C is a restaurant by Long-term laziness –DRM in HTML5 is a victory for the open Web, not a defeat by Ars Technica

ServiceWorkerとは何か

原題: ServiceWorkers Explained

多くのデバイスが常時接続を保証されない状態になりうる状況の中、オフライン・ファーストという視点での開発が急務になりがらもHTML5 Application Cacheには多くの問題があることが明らかになってきています。そんな中、このドキュメントには次世代の仕様として模索されているServiceWorkersに関する詳細について紹介されています。

RespImgシンタックスの提案

原題: Proposal for RespImg Syntax

Apple社のRetinaディスプレイを始めとする、高解像度のディスプレイと旧来の標準的なディスプレイが混在する中、また様々なサイズのデバイスが利用者の好みによって選択できる世の中で、これまで”レスポンシブ・イメージ”に対する唯一の答えが提案されてこなかったのが現状だ。このRespImageシンタックスはこの問題に対する新しい視点による解決案となるかも知れません。John Mellor氏によるこちらのメーリングリストへの投稿もあわせて読んでおくとよいでしょう。

拡張可能なWebへ – Domenic Denicola

原題: The Extensible Web

Webがこれまでと同じように数ヶ月、あるいは数年にもわたるメーリングリストを使った標準化のプロセスのままでよいのか。そんな疑問から始まった#extendthewebforwardというムーブメントの共同エディタであるDomenic Denicola氏によるJS Conf EU 2013での発表The Extensible Web: JavaScript All the Way Downに関する本人による詳細の解説。

CSSセレクタの命名規則に関する私見 – Adactio

原題: Classy values

複雑化、巨大化の一途を突き進む”ウェブサイト”の中でボトルネックになりつつあるCSSの存在。Nicole Sullivan氏によるOOCSS、Jonathan Snook氏によるSMACSS、そしてYandex社の提唱するBEMとこの問題に対する解決への提案は数多くあります。そんな中、米Yahoo!で働くThierry Koblentz氏によりSmashing Magazineに寄稿されたChallenging CSS Best Practices、そしてその記事に真っ向から反対を表明するBen Darlow氏によるCargo Cult CSS。今回紹介する記事は、その2つの意見を踏まえてのJeremy Keith氏によるまとめ。CSSアーキテクチャに興味がある方はこの3本の記事と合わせて、Heydon Pickering氏によるThe Problem With CSS Classesも要チェック。

Viewportに関するリサーチ報告: heightと@viewportについて – QuirksBlog

原題: Viewport research addendum: height and @viewport

今さらViewportの何を調べる必要があるのか。誰もがそう思っている最中、Peter-Paul Koch氏が改めてViewportの指定が実機でどのような作用をするのかをリサーチした結果がこちらです。
彼のリサーチにミスがあったこと、それを訂正するリサーチ、そして、初期調査の結果とあわせて読むと氏の一連のプロセスが見えてくるのでおすすめです。

海外トレンドコラム

ブラウザがどのように画像をリサイズするか知っていますか？ – Jason Summers

原題: How web browsers resize images

Jason Summers氏が本人が作成したResampleScopeというツールを使って、モダンブラウザが画像をどんなアルゴリズムでリサイズしているかについての調査の報告しています。ブラウザ間で異なるアルゴリズムを使っていることはもちろん、バージョン間でも、拡大、縮小時にも異なるアルゴリズムが利用されているらしいことがここから分かります。

Animation-Proxy: JavaScriptによるアニメーション操作への問題解決

原題: JavaScript-Driven Accelerated Animations

JavaScriptを使ってのアニメーションは非常に柔軟であり、強力ですが、弱点があります。それはJavaScriptが基本的に1つのスレッドしか持たないため、常にアニメーションとは別の処理と競合してしまう可能性があることです。
Animation Proxyは、その弱点に対する解決としてWeb Workerをプロキシのように扱いJavaScriptからCSSのプロパティを操作することを可能にする提案です。

Yeomanを使ってPolymerでウェブアプリを最速構築する – HTML5 Rocks

原題: Building Web Apps With Yeoman And Polymer: Scaffold your webapps with modern tooling

Addy Osmani氏によるPolymerとYeomanを使ったウェブアプリの使い方指南。
Web Componentsはまだまだ実践で利用するには早すぎる存在ではあるかもしれませんが、試しておく価値のあるものです。Yeomanを使って事前の準備を素早く終わらせることができるので試してみてください。

IE11の開発者ツールを使ってガベージコレクションを減らす方法 – MSDN Blogs

原題: Reducing the pressure on the garbage collector by using the F12 developer bar of Internet Explorer 11

ウェブサイト制作におけるパフォーマンス解析といえば、Googleの開発ツールがよく知られていますが、Internet Explorer 11に搭載されているツールもまたかなり優れた機能を有するツールです。この記事ではWebGLを使ったサイトを実際にツールを使ってパフォーマンスのボトルネックの1つであるガベージコレクションを少なくする方法を紹介しています。

Translateプロパティはなぜアニメーションのパフォーマンスをよくするのか？

原題: Why is animating left paint more often than translateX?

アニメーションを高速化するために知っておきたいことの1つに、leftやtopなどのプロパティを操作するよりも、translateを利用するほうが高速であるというのがあります。それでは、それがなぜなのか。
簡単な解答は後者のほうがペイントプロセスが少ないからなのですが、この記事でより詳しく解説されている”なぜ”を知ることはより正確に最適化への道のりで役立つツールとなるでしょう。

“速さ”を演出するために知っておきたい4つのこと – Mobify

原題: A Beginner’s Guide to Perceived Performance: 4 Ways to Make Your Mobile Site Feel Like a Native App

一般的なデスク/ラップトップマシンと比べ、どうしても非力なモバイルデバイスにおけるパフォーマンスの最適化手法の1つとして欠かすことができないのが、”速さ”の演出です。英語では”Perceived Performance”と呼ばれることが多いこの領域において知っておきたい4つのことを紹介しています。

知ってますか？ section要素の正しい使い方 – The Paciello Group Blog

原題: Using the HTML5 section element

section要素の正しい使い方はもしかするとHTML5がもたらした最大の頭痛の種かもしれません。そんなsectionの正しい使いどころをThe Paciello Groupでアクセシビリティエンジニアとして働くLéonie Watson氏が解説。

クローズアップ“ビデオ/スライド/ツール/デモ”

よりよいCSSを作る為にデザイナに知っておいてほしいこと – Harry Roberts / CSSconf.eu 2013

原題: Normalising designs for better quality CSS

Harry Roberts氏によるCSSconf EUでのデザイナとフロントエンド開発者、特にUIレイヤに責任を持つ人間との関係について。巨大なメディアを預かっていた彼ならでは視点が多いが、中大規模でスケーラブルに開発を行うことがある場面で必ず役に立つアドバイスばかり。

Appurifyを使って実機のモバイル端末でデバッグ、最適化、そしてテストをする

原題: Seamless Debugging, Optimization and Testing on Real Devices with Sencha and Appurify

モバイルウェブ開発で大きな課題となっている実際のデバイスを使ったデバッグ、テスト、パフォーマンス解析を解決しようとしているAppurifyというサービスをSenchaチームが実際に利用し紹介しています。

Mozilla Brickでウェブアプリを構築してみよう

原題: Building web apps, one brick at a time! (with Mozilla Brick)

MozillaからのWeb Componentsに対するアプローチであるMozilla Brickを使ったウェブアプリの作り方に関するスライドです。豊富なコード例もしっかりあり、ありがたいことに例は公開されています。Brickのロードマップもあるので興味がある方はぜひ。

asm.js: Webにネイティブの速度を

原題: asm.js: Native Speed on the Web

ネイティブ VS ブラウザの戦いに終止符を打つべくしてMozillaが開発しているasm.js。その存在そのものについてはもうご存知のことでしょうが、このスライドでは、そもそもなぜJavaScriptが”遅い”のか、そしてasm.jsが何を解決するのかについてのオーバービューがまとまっています。
本スライドとは無関係ですが、Felix Dahlke氏によるWhy asm.js is a big deal for game developersもあわせて読んでみてはいかがでしょうか。

Grunt Boilerplate – Mark McDonnell

好き嫌いはあれど、Gruntはウェブ開発におけるビルドプロセスで大きな役割を持ってきはじめています。もはやデファクトスタンダードともいえるくらいの存在でしょう。そんなGruntをこれから使う方にも、もうすっかり使いこなしている方にもおすすめのソースコード。
作者であるMark McDonnell氏による本ツールに関するこちらの記事も一読ください。

Snap.svg

SVGに関するデファクトスタンダードとなっているライブラリであるRaphaëlをゼロから、Raphaëlの作者であるDmitry Baranovskiy氏本人が作成し、公開したのがこのSnap.svg。モダンブラウザのみをターゲットとすることで、より小さなコードベースでありながら、より豊富な機能を搭載し、SVGのjQueryとなるべくしてオープンソース化しています。
Adobe社のWeb Platform Teamブログの記事も合わせて要チェック。

実践! ARIAを使ってフォーム入力をサポート

原題: Practical ARIA Examples

ARIA(Accessible Rich Internet Applications)を使ったアクセシブルなウェブサイトの制作は見方によっては時間の無駄に思えるかも知れません。しかし、Heydon Pickering氏によって作られたこのデモページを見れば、ARIAが非常に実利的な問題解決を行う手法でもあることがわかると思います。

★次回の「斉藤祐也の海外WEBテク定点観測」は12月6日にお届け予定です。★