Mozilla Japan ブログ

Mozilla、Firefox、Firefox OS、Thunderbird の最新情報をお伝えします

アーカイブ - デベロッパー

WebKit を念頭に作成されたサイトで起きるブラウザー互換性問題に対する Firefox の対応

[この記事は米国 Hacks ブログで公開された "Firefox 49 fixes sites designed with Webkit in mind, and more" の抄訳です]

最近 Hacks で公開したいくつかの記事で、 ブラウザー互換性を意識したウェブ制作の重要性 と、優れた開発者がブラウザー互換性を考慮してどのようにウェブを制作しているか について述べてきました。すべての人がウェブを利用できるかどうかは、開発者にかかっています。今日の時点で、多くの 互換性に関する機能 が Firefox のレンダリングエンジンである Gecko に搭載されています。これは WHATWG の定める最新の互換性標準 によるものです。

Firefox の今回行われた更新で、特筆すべき変更が加えられました。それはいくつかの -webkit- のついた属性と、WebKit に固有なインターフェイスのサポートです。いずれも標準化されていないブラウザーベンダー固有のものであるにも関わらず、多くのサイトで利用されているものです。

標準化されていない、つまり互換性の損なわれた CSS を利用するということは、標準にそって設計されたユーザーエージェントが正しく振る舞えなくなることを意味します。そんな技術を用いて作成されたサイトを、Firefox 48 以前に代表される -webkit- プレフィックスに対応していないブラウザーで閲覧すると、サイトが壊れているように見えるでしょう。この状況はサイト側の CSS が更新されるまで続きます。だからこそ、今回の更新で Firefox には以下の変更を加え、WebKit でのみ動作するコンテンツに対する配慮を行いました。

  • WebKitCSSMatrix() インターフェースへの対応
  • -webkit-gradient() への対応
  • -webkit- プレフィックスのついたものを、相当する標準的な機能へ適切に対応させる機能の追加
  • 古い -webkit- プレフィックスのついた flexbox のうち、いくつかを -moz- プレフィックスのついたものに対応させる機能の追加
  • 接頭辞のないものが定義されていない以下の CSS 属性への対応

よくある(?)質問

Q. 私にはどういう意味がある変更なのですか?

A. 利用者にとっては、モバイルサイトに良くある WebKit のためだけに作られたサイトの互換性が向上します

WebKit のためだけに作成されたサイトを WebKit とそれ以外とで表示させた図。非 WebKit のブラウザーでは表示崩れが起きています。

開発者にとっては、-webkit- だらけの CSS を作らなくても、それと相当する接頭辞のない属性も追加できることを意味します(過去に戻って追加したいと思う人もいるはずです)。これらの接頭辞は、(理論的には)いつの日かウェブプラットフォームから削除されます。

プロ向けの TIPS : 接頭辞なしの属性は、常に最後に書きましょう。

Q. 以前のバージョンでは、私の作ったサイトは壊れて表示されていたのですか?

A. そうではなかった、と期待しています。壊れていたかどうかは、以下の設定を変更することで確認できます。

about:config?filter=layout.css.prefixes.webkit

もし違いがある場合は、バグとして bugzilla.mozilla.orgmitaylor@mozilla.org を CC に入れてご報告ください。もしくは webcomapt.com へご報告いただいても結構です。

Q. -webkit- プレフィックスのついたものだけ使えば良いのですか?

A. いいえ。やる必要のないことですし、お勧めできるものでもありません。ウェブ標準を使い、複数のブラウザーでの動作を確認し続けてください。以前と比べてそうしなければならない理由は随分と少なくなっていますが、どうしても -webkit- プレフィックスのつく属性を CSS で利用する時には、必ずプレフィックスのついていない属性よりも上の行に書くようにしてください。

完全な情報公開のために : この記事を執筆した Mike は、WHATWG の互換性に関する標準を策定しています。しかし あなたが貢献できる余地 は十分にあります。

mitaylor について

Mike は Mozilla のウェブ互換性エンジニアです。テキサス州オースティン在住。

mitaylor によるその他の記事はこちら

Justin Crawford について

Justin Crawford は Mozilla のプロダクトエンジニアで、ディベロッパーマーケティングとグロースを担当しています。未来について考え、ものを作り、バイクに乗ることを好みます。

Justin Crawford によるその他の記事はこちら

Firefox のリリースチャンネルはご存じですか?

Firefox には、よく知られているものの他に、青いキツネのアイコンや、濃紺のものなどがあるのはご存じですか? これらを私たちはリリースチャンネルと呼んでいます。今回は、それぞれのリリースチャンネルの位置付けと特徴についてご紹介します。

まず、よく見かけるオレンジ色のアイコンの Firefox は、「リリース版」と呼ばれています。Firefox の新機能は、作成されてすぐリリース版に搭載されるわけではありません。新しい機能は、まず Nightly 版へと実装されます。そのあと各リリースチャンネルでさまざまな方に使っていただき、不具合の発見と修正が行われ、問題があらかた修正されるとリリース版へと組み込まれます。

firefox-release-channels@0.75x.pngそれぞれのリリースチャンネルは、テスト用という以外にも特徴があります。それらを順番にご紹介します。

Firefox Beta

公式リリースの前に次期バージョンをテストするためのチャンネルで、最も安定したテストビルドです。このバージョンをお使いいただくだけで、ベータテスターとして Firefox 開発に貢献でき、製品のクオリティ向上に役立ちます。
Firefox Beta のダウンロード

Firefox Developer Edition

ウェブ開発をされている方向けのバージョンで、開発に便利な最新の機能をいち早くお使いいただけるのが特徴です。JavaScript で開発をされるエンジニアの方はもちろん、ウェブデザイナーの方にとっても便利な機能が多く搭載されています。以前は Aurora という名前でベータ版ひとつ手前のバージョンという位置付けでした。2014 年からコンセプトを変更し、ウェブ開発者のためのブラウザーとして提供されています。
Firefox Developer Edition のダウンロード

Firefox Nightly

ブラウザーのプラットフォーム開発者を対象にしたビルドで、毎晩更新され、最先端の新機能をいち早くお試しいただけるバージョンです。ただし、完全に開発者向けのビルドですので安定性は低いものとなります。

Firefox Nightly のダウンロード

これら、リリース版を含めた 4 つのチャンネルは、現在、およそ 6 週間から 8 週間のサイクルで、各プロセスを経て安定版へと進んでいきます。ウェブ開発に携わる方には、Firefox Developer Edition は特におすすめですので、ご興味のある方はぜひお試しください。

なお、Firefox のリリース版を使いつつ、他のチャンネルも試したいという方は、プロファイルを分けて起動することをおすすめします。詳しくは Mozilla Support の記事 でご紹介しています。(Developer Edition に関しては、リリース版との併用を想定しており、自動的に Developer Edition 用のプロファイルが作成されます。)

すべての人が使えるウェブを開発しよう

[この記事は、米国 Mozilla HACKS ブログに投稿された記事 "Make the Web Work For Everyone" の抄訳です。]

数多くのウェブサイトがブラウザー互換性の問題を抱えたまま運営されています。特定のブラウザーでしか正しく動作しないという状況は、ユーザー体験を大きく損なう要因となります。そして、この問題はウェブ開発者のコミュニティが修正できるものなのです。

この 20 年でウェブは全く異なるものになりました。1996 年の時点でウェブサイト数は 100 万程度。これが今では 10 億を超える サイトが運営されています。そしてインターネットの利用者数も 5 千万人から、30 億人 へと膨れ上がっています。私たちはかつて想像されたよりも、はるかに膨大なコンテンツと接しています。それにアクセスする端末も、810 億台と膨大で、その種別は 24,000 以上と非常に多様になっています。

webcompat_blog_graphics_600x800-01.jpg

インターネットの爆発的な成長により、1996 年の時点と比較して、ブラウザー互換性の問題はより本質的な問題となりました。Stack Overflow には "cross-browser" という文字列を含む質問が 55,000 件程度 あり、「なんとかっていうブラウザーならうまく動くんですが」という質問は 10 万件単位で寄せられています。特定のブラウザーで、特定のサイトをうまく使えないことへの質問は、潜在的にブラウザー互換性に関する質問です。

webcompat_blog_graphics_600x800-02.jpg

以上の状況から、ブラウザー間での互換性維持は、いまだに重要な問題であると言えます。この問題は Mozilla にとっての問題であるだけでなく、ウェブを作成する一人一人が考えなくてはならない問題でもあります。なぜウェブ開発者が、この問題について考えなくてはならないのでしょうか。それはこの問題が 「あなたのサイトを利用する人は、あなたと同じブラウザーを利用していない」 から、そして「利用者の能力は均一ではなく、その目的も同じものではない」 からであり、「あなたのサイトを利用できないという理由では、利用者は使うブラウザーを決して変えたりしない」 からです。裏を返せば、利用者が快適に利用できるサイトを作成できるということは、あなたの腕の良さの証明 なのです。そしてツールを適切に利用する ことで、より簡単にそのようなサイトを作成できます。

ブラウザー間での互換性に問題が起きるのはなぜでしょうか。その理由はいささか複雑ですが、主要なものをあげると次のようになるでしょう :

  • ベンダープレフィックス付きの機能のような、特定のブラウザーが提供する機能だけを使ってサイトを実装してしまい、代替機能やポリフィルを使うといった、その機能を持たないブラウザーへの対策がとられていないため
  • 開発者が必要とする機能を、ブラウザーベンダーが標準化を待たずに実装してしまうため
  • ブラウザーベンダーによる標準仕様の実装や、バグの修正に時間がかかるため
  • サイトがユーザーエージェントの値によって、異なるコンテンツを配信しているため
  • 開発者がひとつのツールに、特に 1 種類のブラウザーでしか安定して動作しないようなツール、に頼り切ってしまって、ブラウザー互換性に関する問題を見逃してしまうため
  • 業界の成長によって新しい開発者の需要が増大した結果、平均的な開発者の経験が、数年前のそれよりも劣ってしまっているため
webcompat_blog_graphics_600x800-03.jpg

上記に挙げた問題のいくつかは、ウェブの初期から存在しています。しかし現在のウェブ開発は、その時と比べて大きな進歩を遂げています。ベストプラクティスと、最新のツールによって、すべてのブラウザー上での多様な体験の実現は当時よりも簡単に行えるようになりました。

そこでこの記事では、開発者の皆さんに向けて、次に作るサイトをすべての人が快適に利用できるようにするための心がけを、いくつか紹介します。


自分が思っているものとは違うブラウザーを使っている人は、思ったよりも多い

自分の使っているブラウザーを他の人もみんな使っていると固く信じているウェブ開発者はたくさんいます。その結果、彼らの作るサイトは、彼らの使っているブラウザーのためだけに作られてしまいます。ある調査によれば、70 % のウェブ開発者はデスクトップ環境で Chrome を使用しているそうです。Chrome の使用人口は、すべての端末の種類を足しても、全体の 57 % でしかありません。デスクトップで Chrome を使用しているのは、全体の 45 % です。つまり Chrome だけで開発と検証を行うということは、全ユーザーのうちの半数 を無視することを意味するのです。

地域によっても、ブラウザーの使用状況は変化します。Chrome、Firefox、そして IE / Edge は多くの地域で、最もよく使われています。しかしその分布は地域によって異なるのです。例えばドイツでは Chrome よりも Firefox の方が多く使用されています。日本では IE はとても多くの人に使用されています。またオーストラリアで Safari を使用している人はごく少数です。ベトナムでは 5 人に 1 人以上の人が、Chromium から派生した Cốc Cốc と呼ばれるブラウザーを使用しています。ひとつのブラウザーだけで開発と検証を行うと、このような市場ごとの差異も無視してしまうことにもなります。

自分のブラウザーで利用できる機能が、他のブラウザーでは利用できないこともあります。各ブラウザーベンダーは、それぞれ異なるスケジュールで機能実装を行っています。そのため、自分が利用しているブラウザーでは使えるイケてる機能は、他の多くの人が使っているブラウザーでは使えない、ということは十分に起こりえます。

上記の要素は予期しない形で組み合わされてしまうことがあります。例えばこのようなシナリオで : すべてのブラウザーで実装されていない API を利用して機能を実装し、一つのブラウザーでだけ動作の検証を行われたサイトを、そのブラウザーが支配的な地位にいない市場でサービスインしてしまいます。その結果として、潜在的な顧客の半数以上を除外してしまい、彼らから得られるはずの利益を逃してしまいました。少しの労力でこのような状況を避けられるなら、それは惜しくない労力ではないでしょうか。


ブラウザー互換性をあげることで、アクセシビリティも向上する

複数のブラウザーで正しく動作するウェブサイトを作るためには、その動作環境に何の仮定もせず、可能なかぎり最大の人々が利用できるように、デザインして、コードを書く必要があります。そしてその利用者の中には、当然障害を持つ人々も含まれます。しかも、あなたの想定を超える障害を持つ人々が。すべてのブラウザーで快適に利用できたとしても、スクリーンリーダーを使用していると利用できないのなら、それは大きな機会損失です。

障害を持つ人たちのマーケットシェアは巨大です。アメリカだけをとっても、カナダ全体のインターネット人口よりも多くの視覚に障害を持つ人々がインターネットを利用しています。モダンなウェブブラウザーは彼らのニーズの実現に取り組んでいます。ウェブ開発者は、それを実装するだけで良いのです。

アクセシビリティを考慮して実装することは、障害を持つ人だけではなく、次の例のように持たない人に取っても有益です。

  • スクリーンリーダーで使いやすいサイトは、検索エンジンにとっても処理しやいサイトとなります。画像へ代替テキストを付与し、リンクに対しても解説文をつける。また CSS によって意味の追加を行わなず、HTML5 の文章構造を表すタグを利用する。こういった単純なテクニックを利用するだけでも、ページの SEO が大きく向上します。
  • 動画に字幕をつけると、聴覚に障害を持つ人だけでなく、例えば帯域が狭く動画をダウンロードできないような場合や、騒音がひどく音声を聞き取りづらい場合でも動画の内容を理解できるようになります。また字幕からもキーワードを拾うことができるため、SEO の面でも有効です。

利用者はブラウザーを変えません。そのサイトを使うのをやめます

あなたのサイトの利用者は、あなたのサイトを見るためにブラウザーを切り替えてくれると考えるかもしれません。しかし多くの場合、そのようなことはありません。

利用しようとするものが動作しない状態に、利用者は耐えられません。そして競合する他のサイトへ移動するでしょう。重要な場面でうまくいかないと、潜在的な利用者を永久に逃してしまいます。Akamai によると

  • サイトの利用に問題のあった利用者が、そのサイトで取引をする確率は、そうでない場合と比べて 32 % 少なくなります。
  • 35 % は、その運営会社に対して悪いイメージを抱きます。
  • あなたのサイトに再びアクセスする確率は、トラブルのなかった人たちと比べて 45 % 少なくなります。
  • 5 人に 1 人以上 (22 %) は、二度とアクセスしなくなります。

多くの人は、新しいブラウザーのインストール方法を知りません。ブラウザーとは何かすら知らず、ブラウザーと検索エンジンとウェブサイトとの違いがわからないという人も多く存在します。

ブラウザーのインストール方法を知っていて、インストールしたいと思っている場合でも、インストールできない場合というのも多くあります。例えば会社によって使用するブラウザーが決められている場合や、図書館のような公共の場所にあるコンピューターを利用している場合などが、該当します。

例えば Microsoft は 2016 年 1 月 12 日を期限に、新バージョンへの切り替えを推し進めました。しかし 3 月の時点でも、IE ユーザーの 3 分の 1 以上はセキュリテイ更新がなされない古い IE を利用しています。過去 1 年間の統計 によると、全インターネットユーザーのうち 2.07 % は Microsoft もセキュリティ更新を停止した IE8 を利用しつづけており、1.59 % を占める IE9 ユーザーのうち 4 分の 3 は、そのまま IE9 を利用し続けています。同じく全 IE ユーザーの 10.95 % に当たる人々が、IE10 を利用しています (付記 : これらの使用率は 3 月から大きく下がっています)

正しく動作しないウェブサイトからは、利用者が離れます。利用者の半数が異なるブラウザーを利用していて、彼らを利用者として止めておきたいなら、それらのブラウザーでの動作検証は必須となります。

webcompat_blog_graphics_600x800-04.jpg

互換性が保たれていること == 腕の良さ

ウェブコンテンツの作成は、決して単純労働ではありません。熟練した技術を必要とする専門的な分野です。誇りを持ち、腕を磨いて、自分のスキルを見せつけたいと開発者なら思うでしょう。

  • 最先端の技術、フレームワーク、技法を駆使する
  • ブラウザー間や、プラットフォーム間での互換性を注意深く検証し、機能が足りないブラウザー向けの回避策を用意する。この体験は許せますよね?
  • 障害をもつ人でもコンテンツを利用できるよう検証を行う
  • 製作物のビジュアルや体験が、魅力的で、開発者自身やクライアントのブランドにあっていることを確認する

ウェブ開発者にとって、開発したサイトは履歴書の代わりです。質の高い体験は、そのサイトの利用者、顧客にとって重要なだけなく、開発者自身の現在と未来の上司にとっても重要です。

しかしながら、時間とビジネスの制約によって思い通りにいかないことも多々あります。必ず守らなくてはならない締め切りや、持っている iPad で動けばいいと思っていてアクセシビリティなんて注意を払うつもりのない上司、修正する時間が残されていない IE のバグ。ほとんどの時間はやりたいことよりも、できることをこなすのに費やされます。

ブラウザーの互換性やチェックは諦めてしまおう。きっとフレームワークがどうにかしてくれるさ。締め切りが迫ってきたら、そう思いたくなる時もあるでしょう。しかし作っているサイトは、完全にフレームワークだけでできているわけではありません。その部分を含んだ全体に対して、開発者は責任を持たなくてはならないのです。自分の書いたコードがブラウザーが変わっても正しく動くことを保証するためのテストは、なんとしてでも守らなくてはならない作業です。

時を超えても生き残るコード、欲しい人になら誰にでも届けられる情報、すべての人が利用できるようなリッチな機能。こういったものは優れたウェブ開発者にとっての崇高な目標です。


ツールを使って効率のよい開発を

ここまで、ブラウザー互換性を保つ理由を述べてきました。でもそれは、どのように達成すればいいのでしょうか?

  • まず他の人の開発したサイトに互換性上の問題を発見したら、webcompat.com にバグとして登録しましょう。自分のサイトを修正する場合の方法は以降で説明します。
  • 異なるブラウザーを使って、利用者がするようにサイトを閲覧しましょう。エラーがあれば開発ツールのコンソールに表示されます。ほとんどのモダンなデスクトップ用ブラウザーには、デスクトップサイトだけでなくモバイルサイトのデバッグに有用な機能を備えた開発ツールが組み込まれています。
  • サイト内に問題がない場合、ブラウザーがバグの原因かもしれません。その場合は、ブラウザーベンダーにバグ報告をしてください。ブラウザーの開発者なら、その問題を解決できます。
  • クロスブラザーテストを行うツールを、開発プロセスに組み込みましょう。そうすれば、ブラウザー互換性のテストを自動化できます。
  • API やブラウザーの機能をサイトの実装に利用する前に、各ブラウザーでの実装状況を把握しておきましょう
    • Caniuse
    • MDNのブラウザー実装状況表
    • Kangax's ECMAScript compatibility tables
  • ブラウザー互換性の向上に役立つツールを探しましょう
    • Autoprefixer, CSSNext, Oldie に代表される PostCSS プラグインを利用すると、古いブラウザーへの対応を気にすることなく最新の CSS を利用できます。
    • Modernizr を利用すると、ブラウザーごとの実装の違いの判定と処理が簡単になります。ユーザーエージェントによる判定や振り分けを行うのではなく、こちらを利用しましょう。
    • @supports は、プログレッシブエンハンスメント に関する情報を提供しています。こちらの情報を利用すれば、機能の多いブラウザーに対しては、よりリッチな体験を提供できるようになります。
  • 機能や、振る舞いの違いなどを多く学びましょう。深く知れば、それだけ愛着を持ってその機能を使えるようになります。

ウェブ本来の使命を果たすために

どんな人でも、使用しているブラウザーや、使用している端末が異なっていても、コンテンツにアクセスできる、というのがウェブ本来の使命です。自己決定、自由、教育、そして発見。これら人間性を構成するいくつかの重要な要素が、この使命には織り込まれています。ブラウザーが変わっても使えるように設計することで、開発したサイトは最大限の利用者と市場に向けてのものになります。そして開発者としての腕も大いに磨かれ、素晴らしいものを作れるようになるでしょう。

最近のデバイスや、ブラウザーによって生じる多くの困難がある一方で、それらの問題を解決するツールも多く存在します。ウェブの利用者は 30 億を超えます。その彼らが、あなたの作ったサイトを見るのです。その準備はよいですか?

Mozilla が牽引する "ゲームプラットフォームとしての Web"、いよいよ新たな段階へ

[ この記事は、米国 Mozilla Blog に投稿された "Mozilla Pushes the Web to New Levels as a Platform for Games" の抄訳です ]

Web は、ゲーム開発のプラットフォームでもあります。それを実際にご覧いただくため、Mozilla は今年もサンフランシスコで行われる Game Developers Conference に出展します。 Web は、ますますパワフルに進化し、 Web ゲームの技術が成熟するにつれ、開発者とゲームプレイヤー両者の注目を集めています。

  • Mozilla が先駆けとなって開発した WebGL、WebVR、asm.js といった技術も勢いを増しています。
  • 次世代 asm.js の WebAssembly は、本日より、Firefox の Nightly 版で、テスト用の実験的機能としてお試しいただけます
  • GDC にて今週公開する Open Web Games は、開発者やブラウザメーカー向けのサイトで、最新の Web ゲーム技術の紹介やブラウザでストレステストを実行するための機能、Web games stack の安定と発展に向けた相互協力を醸成するための場を提供するもので、実際のゲームやデモが数多く用意されています。
  • WebGL 2、SIMD.js、Shared Array Buffer のような次世代 Web 技術も、 Firefox の Nightly 版でどなたでもお試しいただけます。
  • WebVR 推進のために、 Mozilla では最近、WebVR API プロポーザルのバージョン 1.0 を公開しました。
  • Mozilla では Mozilla Developer Network (MDN) や直接の技術的サポートを通じてプラグインベースのゲームタイトルを Web 技術に移植する開発者を支援しています。

ここ一年で、業界各社の Open Web 技術への関心も高まっています:

  • 業界最大でかつ最良とされるゲームエンジン Unity は、先日、これまで「プレビュー版」としていた WebGL や asm.js を使った出力機能 WebGL exporter を正式にサポートされたビルドターゲットに昇格するとの発表を行い、 Web スタック の有用性を後押ししました。
  • 3D デザインとアニメーションツールのリーダー的存在である Autodesk が、ゲームエンジ Autodesk Stingray に Web 出力機能を技術プレビューとして追加しました。
  • EVERYDAYiPLAY のような若いモバイル開発会社も、Heros of Paragon のようなゲームを Web 版に移植することで収益を成長させています。 EVERYDAYiPLAY 社のレポートによると、 Web 版の一日当たり一人当たりの売上高 (Daily Average Revenue per user: DAPRU) は、Android の Play Store での売上よりもずっと高く、 iOS 版にも追いつく勢いです。
EVERYDAYiPLAY-DARPU.png

Web ゲームが前進するために必要な API がメジャーブラウザによって次々と採用されています。ゲーム業界のトップブランド各社も続々と Web への対応を押し進めており、 Web プラットフォーム向けの開発がしやすい環境がますます整いつつあります。これにより、 Web プラットフォームでの成功も、開発者の手に届くものとなりました。

timeline.jpg

詳細情報

  • GDC にお越しの方は、南ホールの Lower Level 、ブース 936 の Mozilla ブースまでお立ち寄りください。
  • プレスによる取材や質問に関しては、 press@mozilla.com までお願いします。
  • Mozilla の GDC での活動や、 開発者よる最新記事、また、この取り組みへの参加方法などについては、 games.mozilla.org をご覧ください。

Mozilla の A-Frame がアムネスティ・インターナショナルの新しいバーチャルリアリティのサイト #360Syria に採用されました

[この記事は米国 Mozilla ブログに投稿された "Mozilla A-Frame Powers New Amnesty International Virtual Reality Website #360Syria" の抄訳です]

アムネスティ・インターナショナルは、本日、新しい #360Syria というサイトを作成したことをアナウンスしました。こちらのサイトでは、シリア政府によってアレッポ周辺の都市へ投下された樽爆弾による破壊の様子を、仮想的なツアーによって閲覧できます。この "Fear of the Skey" (www.360Syria.com) というサイトは、Mozilla の作成したライブラリ A-Frame を利用して作成されています。

アレッポ周辺のサイトへの仮想的なツアーを体験できる #360Syria のようなサイトは、WebVR の新しい有用なユースケースです。テクノロジによって、このような表現が可能になりました。新しいレベルの可視化と、実世界の状況に対する共感が可能になりました。

#360Syria は、特別に作成された全天周写真、ナレーション、音声、3D グラフィック、そしてアムネスティによって訓練されたシリアのメディア活動家によって収集された動画によって構成されています。このサイトはサンフランシスコのデザイン・テクノロジーカンパニーである Junior (www.junior.io) によって製作されました。

A-Frame はオープンソースの WebVR 用フレームワークで、Mozilla の仮想現実に関する研究グループである MozVR によって設計およびメンテナンスされいます。HTML によって簡単に WeVR コンテンツを作成でき、その構成要素は拡張可能で、組み合わせ方に制限がないため、高いレベルで自由にコンテンツを作成できます。VR 技術に不慣れ開発者であっても簡単に利用できるため、より熟練した開発者になるための間の学習にも最適です。

ハイパフォーマンスで、レスポンシブな VR 技術をオープン Web に実現することは、Mozilla のゴールの一つです。Mozilla の開発したオープンソースライブラリ A-Frame を利用することによって、WebGL のような複雑な 3D プログラミングをすることなく、VR 体験ができる Web サイトを作成できます。

A-Frame によって WebVR 開発ツールが豊かになり、それによって VR を作成する Web 開発者と、彼らによって作成される WebVR 体験が増えることを願っています。

関連情報:

以前の記事