HTML5 Experts.jp 副編集長兼エキスパートの吉川です。今年1年のWeb業界を占うということで、エキスパート、ブラウザベンダーの方々に「Webの未来」について、がっつりお話しを聞いてきました。

HTML5 Experts.jp 編集長の白石が、Googleのデベロッパーアドボケイトのえーじさん、 Web標準ウォッチャーとして有名な矢倉さん、MicrosoftのWebエバンジェリスト物江さん、Mozillaの技術戦略マネージャ浅井さんをお迎えして、興味深いお話が盛りだくさんです。今後のWeb業界の動向を追いかける上で、重要な内容となっているので、ぜひ読んでみてください！

今、Web標準ってどうなってるの？ WHATWGとW3Cとか

白石 皆さん、よろしくお願いします。最初に、僕が個人的に思っていることとして、最近Webのビジョンが見えないな、と。これまでのWebの歴史を見ると、例えば1990年代だったらWebが急拡大して、いろいろなサイトが出てきてきてわくわくしました。2000年代前半になると、Servletとか書きまくったり、XHTMLとかXMLも出てきて面白かった。2000年代後半だとWeb2.0のブームがあって、そして2010年代前半には、HTML5のムーブメントがあった。

それに対して、今どこに向かっているかということを考えると、そんなに楽しいビジョンが見えるかというと、あまりそうは感じていなくて。例えば、モバイルアプリが使う時間がのびて、Webブラウザ使う時間が短くなったかなとか。各社のWebに関する戦略の変更もあるかなと思うんですが、Chrome Appsがサポート終了だとか、IEの開発が終了してEdgeに移行したりとか、Firefox OSも今年終了ということもあって、これまでイケイケでWebを拡大していこうっていうところから曲がり角に来てるのかなと僕は感じています。

今後のWebがどういう流れになっていくのか、というところも見え難くなっていると。今日はWebの未来について何かビジョンを描くとか、少しでもそういうことができると嬉しいなと思います。

さっそくですが最初にWeb標準について、ちょっとお聞きしたいと思います。現在、WHATWGとW3CといったWeb標準はどうなっているのか、そこらへんの現状とかを教えてほしいと思います。では、矢倉さんお願いできますか？

矢倉 正直、最近あんまり追いかけていないところもありますが、聞きたいのはWHATWG、W3Cだとか、HTMLの仕様がどうなっているのかというところだと思います。どこから話しましょうか。

白石 そうですね、仕様が分かれているというのはみんな知っていて、ただ詳しく仕様を追いかけていない僕ぐらいのレベルからすると、W3Cというのはスナップショットを取る団体に見えていると。W3CとWHATWGの仕様がちょっとぐらいズレがある、ぐらいは把握しているんですけど、まずそういう世の中の認識は正しいのか、みたいなところとか。現実の標準化の現場ではどうなのかというところが聞きたいですね。

矢倉 わかりました。まずW3CのHTML仕様というのは、10年前にスタートしましたが、その時点で既にあった2007年当時のWHATWGのWeb Applications 1.0という仕様をベースに進めたというのがW3Cの仕様です。WHATWGの仕様は、基本的にエディター（当時はIan Hickson）がフィードバックをMLから集めて、それを頭の中で考えてこねこねして書いたものが仕様に反映される。それをみんながレビューするという形です。それに対して、W3Cの策定プロセスは、とりあえず何か議題があったら、それについてみんなで話し合ってコンセンサスをまとめて、それから仕様に反映させるということをやってたので、やり方に相違があったと思います。

WHATWGのほうは、ソフトウェア開発的なモデルとして仕様も同じように作っていくべきという意識でずっとやっていて、だからバージョンというのもとくに切っていません。マーケティング的な要素で「HTML5」と一瞬名前を変えたときもありますが、べつにバージョンを切ったというわけではありません。コミットされるたびに更新されるので、W3Cの仕様にある日付がついた仕様のドラフトも（一瞬つけたものが出たりしたんですが）、特にやらずに進めています。最新版が常にベストみたいな感じですかね。

一方で、W3Cにはまず勧告プロセスがあり、勧告しなきゃいけない以上、どこかでフィーチャーフリーズしないといけない。なので結局スナップショットになってしまう。勧告が必要なのかというと、勧告されないと特許ポリシーが発効されないので、IPR（知的財産権）的に危うい状況になるんですね。そういうのがあって、仕様を固めないといけない。

W3Cのほうがだんだんと乖離してきた原因のひとつが、Web Applications 1.0でHTML 4.01から変わった箇所、特にマークアップやアクセシビリティの変更に対して、HTML WG内外からいろんな議論があって、それに対処しないといけなかった。W3C側は、HTML WGだけじゃなくて関連する他のグループとも仕様について調整しないといけないんですが、特にアクセシビリティ関連の機能で話がまとまらなかった。まあ生産的でない議論がずっと続いているというのがあって、それに対処していった結果少しずつ離れてしまっている部分がでた。で、Hixieなどはそれをよしとしないので、Web Applications 1.0に反映されない。そういうのが続いて、完全にコミュニケーションがこじれたので、今のよくわからない2つの仕様があるんですね。

風向きが少し変わったGitHubへの移行

矢倉 少しだけ風向きが変わったのが1〜2年前で、WHATWG HTMLがそれまでHixie(ヒクシー: Ian Hicksonの通称)がwhatwg.org上のリポジトリで個人でやってたものがGitHubに移行したんですね。そしたら、みんなPull Requestを投げたりとか、issueを作って議論するようになってきたりして、少しずつコミュニティみたいに、みんなで作る仕様みたいになってきた。そうしたら、W3C側からも仕様を一致させようという動きが少しあって、多少一致したところもあります。ただ、マークアップ絡みのところだとやっぱり、Hixieや彼の周りの人が入れた仕様が受け入れられずまたこじれたまま、どうにもいかないところもあります。いまHixieは完全に離れちゃったんですけどねえ。

例えば、アウトラインアルゴリズムでWHATWGのほうでは、セクションの見出しとしてh1をレベルに応じて使うんじゃなくて、全部h1でいいよっていうのがあったんですけど、W3Cの中ではそれが省かれちゃったんですね。というのもスクリーンリーダーがちゃんと対応していないからという理由です。実装状況とかも反映するのがWHATWGのやり方なんで、W3C側で省かれた変更を取り込もうというのもGitHubのほうでissueができたんですが、それが受け入れられずに放置されているとかいうのもあります。ひいてはコミュニケーション不足、解消するにしてもちょっとこじれすぎててどうしたらいいのかわからないっていう気がします。

白石 なるほど。Hixieはもう離れちゃったんですね。

矢倉 離れてますね。今はFlutterっていう、ちゃんと見てないんですが、アプリ版のUnity…つまりXamarinみたいなものですかね、それに関わってるようです。あと個人では、IoTみたいな感じのことやってるみたいです。

白石 あ、Googleもやめたんですか？

矢倉 Googleはやめてないですね。FlutterはGoogleでつくられてるので。あと、Flutterに関わってる人を見ると、以前Chromeをやってた人とDartをやってたひとが集結していたりもしてて、なんか不思議です。

W3Cがフォークになってしまってる状況はぼくもなんとかしてくれとは思うんですけど、結局、特許ポリシーまわりなのかなあと。特許ポリシーがないと、実装に特許的な問題がでたときに、どこからも守ってもらえなくなるじゃないですか。そうするとWebプラットフォーム自体の進化が止まってしまうので、大人の付き合いは必ずしないといけないんじゃないかなあと。まあ、それをどこまで一般のWeb開発者が認識しなければいけないというのはありますし、別の話ではあるんですが。

ブラウザベンダーの人は、WHATWGの仕様を見ているんすよね。逐次アップデートされていくので、APIなんかの仕様はWHATWGのほうが安定度合いが高いと見ている。特許の部分てそこら辺に関わることが多いでしょうから、そこがちゃんと特許ポリシーで守られるべきだし、そうなるとW3C側の仕様でAPIの乖離が起こるのはよくない。そこはなんとかする仕組みがあればなあと思います。

で、API部分の乖離というのは、ただWHATWG HTMLのほうが更新されてるだけで、話がこじれたからというものってかなり少ないんじゃないかなと思うんですよね。ちゃんと調べたわけではないですが、大体マークアップのところに多いような気がします。マークアップのところでは、仕様を読む限りはW3Cのほうが筋がいいと感じるところも少なからずあって、例えばルビのマークアップとかでしょうか。WHATWGのやつだとあんまり嬉しくないようなものが確か残ったままだったような気がしています。

ただ、マークアップは、あっちの仕様でこう書いてあるけどこっちの仕様ではこう書いてあるからどっちを選ぶというのよりも、それも踏まえてどう使うかを自分で判断するってところが大事じゃないのかいと思うんですよね。結局、CSSとかJavaScript APIとかだって開発するときに「これはこのブラウザで対応してないからどうする」とか、ブラウザの対応状況を見て決めているわけじゃないですか。それと同じことをマークアップでやればいいんじゃないかなと思います。都合が悪い仕様ならそれは突っ込むべきなんですが、グループの政治的なところを、仕様を選ぶ理由にすべきじゃない。そんなのただただナンセンスなだけですよね。

普段Webを開発している人のフィードバックを得る仕組みが必要

白石 マークアップで問題になっているところって、rubyとかh1とか、hgroupとか。timeとかもいろいろ問題ありましたね。

矢倉 そうですね。あ、で、マークアップの仕様について言うと、まだ仕様がこなれてないんじゃないかと思うことがしばしばなんですよね。Hixieは基本的にかなり合理主義なところがあって、例えばブラウザのリバースエンジニアリングをして、その当時ブラウザが実装していたものを仕様に落とし込むってことをやっています。HTMLパーサなどが最たる例でしょうか。

でも、マークアップに関していうとかなり理想主義で、だいぶ厳格な考えを持つ人という印象があります。それがアウトラインアルゴリズムだったりとかに現れてるんですよね。HTML 4.01にはStrictという、タグセットを絞った厳格な定義がありますが、HTML5のはそれよりもさらに厳格なマークアップを要求しているように思います。もちろん、HTML5の策定当時にもそこらにあるHTMLのマークアップをまとめて、それをもとに要素を追加してたんですが、ちょっと理想が強すぎて、世の中のマークアップに対応できずに進んできたのかなあと。

で、HixieのHTMLがどれぐらい「Strict以上」かというと、ひとつの例としては、もう仕様からは10年前ぐらいに消えたんですけどpredefined classsesっていって、class名の値を特定の値だけに限定してそれ以外のclassを使ったらnon-conformingにするっていう仕様があったぐらいなんですよね。さすがに消えましたけど、それくらいドラスティックな変更を仕様に盛り込んだりしてたんです。rel属性の値とか、メタタグの名前も似たように限定してて、それは今でも残ってたりはしますね。

もちろんこれも、あとから解釈を広げた結果ふんわりしすぎちゃったってことにならないようにという意図があったとは思うんですが、フィードバックがなかったから使いづらい仕様のままになってしまってるケースってあるような気がするんですよね。

ブラウザの実装に係わるアルゴリズムやAPIの部分に関しては、数多くフィードバックが寄せられたので今のいい仕様があるわけですけど、マークアップのところはそういう仕様のフィードバックサイクルがまわらなかったのかなと。これは、普段WebサイトやWebアプリを開発している人のフィードバックが少なかったていうのもひとつあると思うんですよね。フィードバックを送って、それを適切に処理して反映させるっていうことができないと、作られるWebサイトやアプリのマークアップまわりがちょっと窮屈になって、結果としてユーザーの不利益になるかもしれない。もう起こってるかもしれないので、それを避けるように動かないといけないのかなあと。

Microsoftはどちらの仕様を参照するか、というよりもデファクトを重視

白石 それでは、さきほどの話を踏まえて、じゃあそれに対してブラウザベンダーの方々がどう標準を考えているのかみたいなところも聞きないとなと思います。そもそもブラウザベンダーの方々がみんなWHATWGのほうを参照しているっていうのは本当なんですか？

物江 うち（Microsoft）の最近の流れだと、相互運用性を非常に重視しているので、WHATWGにあるかどうかわからないことでも他のブラウザがやるのであれば対応しようっていうのがあります。結局のところWHATWGかW3Cかっていうよりは、デファクトがどうかっていうところですね。

白石 なるほど。デファクトという話だと、パターンとしては2つあって、みんなで一緒に始めるか、それとも誰かに始めてもらってそのあとを続くかになりますね。

矢倉 デファクトが重要というのは確かにそうですね。能動的であるか、受動的であるか、残念ながらやるみたいな。MozillaとかOperaとかはそういうポジションになってるんじゃないですか（一同笑）。

物江 例えば、WebRTCだと、最初WebRTCを包括するORTCという仕様を提案して進めていたんですが、結局相互運用性の問題で従来のWebRTC 1.0を後から実装する形になりました。突っ張っちゃったけど、しょうがないねっていう（笑）。

白石 例えばWebAssemblyなんかはみんなで一緒にやりましょうって始まって、すごくいい感じになってますね。

矢倉 デファクトっていうと、XMLHttpRequestとかも元々IEが持っていたものをMozillaが組み込んで、Geckoがたしか最初だと思うんですけど、確かその後WebKitが追従したんじゃないかなと思います、そういうプロプラエタリなものでも、取り込んでいく。

浅井 サービス側での利用が広がっちゃうとそれはもうしょうがないですね。そういう意味ではMozillaも例えば、WebKitのプリフィックスがついた機能をFirefoxでもサポートするということもやっています。

矢倉 そうですね、仕方なしにやるのか、便利だからやろうっていうのはわからないですが、そういうことをやってるというのはあんまり昔と変わっていないのかなと。WebKitプリフィックスの話だと、その上にっていう名前がついちゃってプロプラエタリ感が満載だから心理的な抵抗があるってだけで、やってることに関してはたしかに同じですね。

浅井 プロプラエタリ感が満載っていうよりも、せっかく標準化されたのに古い構文が残っていて、それを捨てられずにいるってのは、やっぱりもう一つの抵抗の理由だと思う。でも残念ながらサイトが対応してくれない状況が続くんだったら、まぁしょうがないよねっていう。

物江 ベンダープリフィックスって、Mozillaが一回はずしたんですけど、またサポートしたんですよね。

浅井 そうですね。-moz-プレフィックスは外している一方で-webkit-プレフィックスのサポートを追加した状況です。

Mozillaが日本のトップモバイルサイト100を調査して、修正依頼？

浅井 実は、MozillaがWebKitプリフィックスをサポートする判断をした背景には日本市場の影響も結構あります。MozillaにはWeb Compatibilityチームという、Firefoxに限らずWebサイトが誰にでも使えるようにするために取り組む部隊がいて、どのプレフィックスがどの程度ユーザの多いサイトで使われているかをこのチームで広く調査した上で、FirefoxでのWebKitプレフィックスの一部サポートを決断しました。

最初、中国とかアジアのサイトを見 ると酷かった。標準準拠コードを書いていないから、全然動かない。北米とかは最新標準仕様のコードを書くサイトが多いんですけど、中国のサイトはあまりにもひどいかった。

日本についても、日本のトップモバイルサイト100以上を片っ端から調査しました。動かないサイトがあったら原因が何かって徹底追求して、動かない原因と直すべきコードも全て調べた上で、各社にメールや電話をしまくり、Webのフォームやコンタクト先がなければ知り合いを通じて教えてもらうなどしてWeb担当者にFirefoxはもちろんIEなどでも意図通り動くコードへの修正をお願いしました。

その結果例えば、日経新聞とか、サントリーさんとか、ガールズチャンネルさんとかは直してくれたんですね。反応が面白かったのは、ガールズチャンネルさんなど、直し方わからなかったんです、ありがとうございますって即座に直してました（笑）。

矢倉 こうやったら直るっていうのまで伝えたんですね。

浅井 そうです。コードも全部、こうするだけで終わりですってところまで教えるんですね。例えば、ミクシィさんともこんな感じで直していただけますかって打ち合わせをしたのですが、彼らの場合 5万行以上のCSSファイルがあったりするので、なかなかすぐには難しいとお断りされました。いや、こういうツールを使うとプレフィックスがあるコードを自動変換できるやつもあるんですよってご紹介などもしたのですが、マネージャーレベルでは対応いただけなかったのです。

でもしばらくして、その打ち合わせに参加してくれていた現場のエンジニアの方が、次に携わるサービスでは提案してくれたツールを導入して対応しますとこっそり教えてくれました。その後それがmixi全体に広がりましたが、現場から変えてくれた彼には感謝しています。 最初から全体は直せなくても少しずつ直したりツールを用意したり教育をしたり、息の長い取り組みをしています。ただ、あまりにも日本やアジアのサイトはダメなところが多く、修正も時間がかかることが多くてユーザが不利益を被ってしまうため、非標準の標準化をしようっていったのがあの仕様 (Compatibility Standard)になります。

意外に思うかも知れませんが、日本のトップのIT企業が対応してくれないことが結構ありました。 社名は伏せさせてください(笑) 。当初は中国の特定サイトだけとか、日本の特定サイトだけブラックリストに入れて対応する案もあったのですが(実装もしていました)、トップ企業でも対応してくれない事例が多くあり、全サイトを対象とすることになりました。

ちなみに、他にも日本での調査を機に互換性対応で実装を変えた問題として、UA (UserAgent 名)があります。Mozillaとしては、ユーザのプライバシー確保とトラッキング対策のため、ユーザの絞り込みに繋がる情報は最小限とする方針であるため、主要ブラウザでも最もシンプルなUAとしており、AndroidのOSバージョンも含めていませんでした。

でも、日本のモバイルトップサイトを確認するとAndroidバージョンを入れると壊れるサイトと、入れないと壊れるサイトの両方があり、Androidバージョンを入れたときのほうが直るサイトの割合が遙かに高かったです。それである意味仕方なく、OSバージョンを入れることになりました。この話なんかもWeb標準仕様と同じように、実態に合わせつつ、あるいは他のブラウザの挙動に合わせつつ実装をしていっている事例の一つでしょう。

白石 ちなみに、その非標準の標準化っていうのは本当に標準化するんですか、つまりW3Cのプロセスにのせたりとかするつもりがあるということですか？

浅井 WHATWGでは[Compatibility Standard]（https://compat.spec.whatwg.org/）という仕様として書いていますが、W3Cでやるかっていうとそれはわからないですね。あんまそういう動きはないと思います。

矢倉 あ、でも一部の機能はCompat Standardみたいなパッチではなくて、標準仕様にとりこまれてます。たとえば、Element.matches()という、ある要素が特定のCSSセレクタにマッチしてるか判別する仕様があるんですけど、それが昔の仕様だとmatchesSelector()という名前で、それがWebKitではwebkitMatchesSelector()として実装されていたんですね。で、互換性のために仕様で定義しようって話になったときに、それはもうCompatibility Standardじゃなくて、DOMの仕様の中で定義したんですよね。そういうのもあります。

浅井 innerTextとかもそうですね。標準のtextContentしかサポートしないって僕らは言い張ってたんですけど、僕らだけサポートしないっていってても日本などのサイトは直らないから仕方がないということでinnerTextでも動くようになりました。標準にも反映されています。

新しい取り組みである「Origin Trial」とは？

えーじ ベンダープリフィックスの問題って結構長くあって、それを解決する方法として、Chromeでは基本的にExperimentalな機能をStableに入れないっていうのを始めたんですよね。もうその機能は、Betaまでのバージョンまでしか動きませんっていう状態で、まずは実装をはじめて、最終的にそれをStableにのせるために必ずコンセンサスをとらないといけない。

なのでMLにIntent to Shipっていうメールを出すんですが、それで合意が得られて、実装が2つ以上存在している場合にのみStableにのせるという段階を踏むようになりました。なので、新しい機能については基本的にはある程度、成熟した仕様であり、かつ実装も問題ないという合意が得られたうえでshipしますというような状態になっています。

最近始めたOrigin Trialというのがあって、それは新しい機能をStableにのせるけど、あらかじめ使いたいと手を挙げたサイトでのみが使えるというもの。それをやるためには、フォームで申請をして、そのトークンをサイトに載せることによってブラウザがホワイトリストでその機能を動かす、そうすると我々としてもどのサイトがそれを実装してるかわかるし、もし仮にそれにひどい変更が入りますってときにもコンタクトをとることができると。

矢倉 あと、Origin Trialは、一定期間過ぎたら終了するっていうのもありますね。

浅井 Origin Trialは、面白いなと思って見ています。その機能が大規模に使われると、サイトのドメインの数が少なくても例えばfacebook.comで使われてしまうと後戻りできなくなるので、ユーザーの数が一定以上を超えたら無効になるっていう仕組みがある。そういうのをちゃんと考えているのが面白いなと思う。

今後、全面的にOrigin Trialになっていくのかどうかとか、例えばBLE（Bluetooth Low Energy）は、Origin Trialに入れながらやって、この時期には標準にするよって宣言しながら実装されてます。それが宣言された時期までに他のブラウザが実装しているかどうかというのは、本当にshipする基準にするのか、それとももう宣言してしまったから実装がなくてもshipするのか、どっちなのかなという点を気にしながら見ています。

矢倉 Origin Trialは、もともとマイクロソフトの人が提案してたんですよね。EdgeチームのJacob RossiがW3CのTPACで提案してて、そこにChromeチームのAlex Russellものっかっていて、もしかしたら二人のアイディアなのかもしれないですけど、最終的にChromeだけでやってはいますけどね。

Origin Trialは、APIのローンチカスタマーを作る意味でも結構良いのかもしれないですね。手厚くフィードバックも得られるし、カジュアルに試して見たよっていうよりもこういう業界的なニーズがあるから使いたいということでOrigin Trialに申請するといったら、ChromeのDevRelのひとも反応しやくすくなるのかなっていう気がします。

白石 たしかに。ニーズがあるかわからない機能が入ってくるとかもありますしね。

矢倉 そして不幸になるっていうのはHTML5でいくつか経験してますからね。

浅井 Extensible Webのときからそうだというイメージありますが、やっぱりブラウザベンダーと標準化団体だけで作っていたらもうダメだっていうのがよくわかっていて、いかにデベロッパーの声を集めて標準化に反映するかが大事です。Origin Trialはそれを実現する手段を具体化した手段の一つだと思うので、非常に面白いと思って見ています。

GoogleはWebが目指すべきところに必要な機能があればどんどん進めていく

白石 ちょっとえーじさんに聞いてみたいなと思ったのは、さっきEdgeはデファクトを追いかけますって話だったので、だとすると、まず最初に実装するベンダーとかが必要になってくるじゃないですか、デファクトを作る人たちが必要なので。それって、ここでいうとGoogleとか、Mozillaとか動きが早そうだなと。そうすると、どの仕様を実装するかを決めるのってどういう基準でやってるのかなというところを聞きたいなと。

えーじ 社内的にはやっぱり、Webが目指すべきものっていうのをざっくり持っていて、その中でじゃあそのピースを埋めるために必要なのはどの機能なのかっていう判断をして、なければ作るしっていう感じで進めちゃいますね。他がやるのを待ってるっていうスタンスではないです。

白石 なるほど。具体的いうと、例えばService Workerとかなんですかね？

えーじ そうですね。ひとことで言っちゃえばProgressive Web Appsっていう話になるかと思います。以前より一言ですむんでだいぶ言いやすくなりましたね（笑）。今までは、一生懸命Service WorkerとAdd to Homescreenと〜、とか説明しなきゃいけなかったのが一言で済むので個人的にはありがたいですけど。所詮マーケティング用語みたい感じの部分もあって、結構揶揄されたりしますが、一言で表せるという意味ではモバイルに対するWebの回答と考えるとわかりやすくて良いのかなと思います。

ここ最近は、Webが割と盛り返してきた感じを受けてるんですけど、去年までの2〜3年ぐらいの間ってやっぱり日本の各社もWebチーム解散してAndroidにリソース注ぎ込むとか、ざらにあったりとかしてWebがだいぶ負けてきているっていうのはすごく思っていたんですけど、Service WorkerとかPWAの流れがでてきて、だいぶ盛り返してきた感じがあります。

Progressive Web AppsはモバイルWebをいかによくするかのムーブメント

えーじ PWAに対する反応もすごくいいんですよね。なので、そういう意味ではモバイルでのWebをいかによくしていくかっていうムーブメントとして僕はPWAを捉えている。技術的には細かい話はいっぱいありますけど、そのピースをどう組み合わせていくかっていうのは各ブラウザベンダーの判断もあるでしょうし、思惑もあるでしょうが、最近は足並みが揃ってるという感じがしています。

物江 EdgeでもPWA周りの仕様は、開発中のステータスになっているので、近いうちにEdgeでも使えるようになる可能性がありますね。

矢倉 EdgeチームのJacob RossiがMediumに投稿していて、WindowsでPWAを考えるとブラウザの中だけにとどめておくってことはしないで、WindowsストアだとかBingの検索結果に乗せるだとか、PWAをインストールしたら、それがスタートメニューやランチャーに乗るとかも検討しているらしいですね。

物江 Chrome Appsみたいになるらしいです（笑）。

えーじ 話をややこしくした（笑）。

白石 Chrome Appsは、サポート終了するのに（笑）。

えーじ ある意味それは正しくて、Chrome Appsを終了する理由って、Webの標準を盛り上げていかないといけないのにChrome Appsというプロプラエタリなものに注力し続けるよりは、Webの標準からネイティブ的なアプリが作れるようになるべきであるという感じです。

白石 じゃあ、Chrome Appsに実装されていたBluetooth APIやUSB API、Socket APIとかは。

矢倉 USB APIはOrigin Trialになってますね。

えーじ Socket APIは、入っていないですね。それをやるかどうかも決まっていないと思います。要望があれば受け付けますというフォームもあるので、その辺はデベロッパーのユースケース次第という感じですかね。

白石 なるほど。少なくてもそれらを標準化にのせていこうという意図は、持っているということですかね？

えーじ モチベーションがある人がいればやるって感じですね。社内でそれを是非やりたいという人がいれば仕様も書くだろうし、実装もすると思います。いい例でいえば、PaymentRequest APIとかCredential Management APIとか、最近はここら辺を担当しているんですが、やっぱり担当のチームがきちんとあります。Paymentsに関してはMozillaさんやMicrosoftさんと並行して実装も進めていると思います。

物江 Paymentsは、Edgeでも開発中なので、近いうちに。

（後編へ続く）