2018年のWeb標準

@1000chこと泉水翔吾です。新春企画2018年のWeb標準ということで、2017年に続いて、2018年のHTMLやCSSなどのWeb標準技術を中心としたWebの動向予測を寄稿します。

W3CによるHTML5.2の勧告とWHATWGの標準化プロセスの整備

2017年12月14日にHTML 5.2が勧告されましたが、ほぼ同時期にWHATWGがFurther working mode changesという記事を公開しました。この記事ではWHATWGが行なっている標準化プロセスの整備について述べられています。

現在W3CとWHATWGという2つの団体がHTMLの仕様を標準化しています。2017年の記事にあるHTML 5.1およびHTML 5.2 - HTML Living Standardとの乖離でも触れられていますが、これにはバージョニングし勧告を発行したいW3Cと、Living Standardとして更新し続けたいWHATWGとで、スタンスの違いから標準化プロセスが分離したという経緯があります。しかし、W3Cが公開しているドキュメントはWHATWGのものをフォークし、整合性を無視して変更を加えているだけというのが実情で、ブラウザを開発するベンダーもWHATWGがメンテナンスしている“⁠生きた仕様⁠”を元に実装しています（仕様策定に関するW3CとWHATWGの違いや経緯については、momdoさんの記事が詳しいです⁠）⁠。

WHATWGはブラウザベンダーの人間が集まって形成されている組織であり、W3Cのように法人格があるわけではありません。また、公開しているドキュメントのロイヤリティについても、W3Cのようにパテントポリシーが存在しません。Further working mode changesでは、こうした状況を踏まえて作業プロセスを整備していくことが宣言されています。中でもIPRポリシーの導入が最も大きなところでしょうか。

WHATWGが導入したIPRポリシーにはロイヤリティフリーが明言されており、今後WHATWGが公開するドキュメントもこれに沿うことになります。これにより、W3Cが公開するものより唯一劣っていたとも言える特許問題はクリアになり、技術文書としての信頼性は担保されていくことになるでしょう。フォークを続けてきたW3Cの動向にも注目したいところです。

Web Components普及への期待

仕様が何転もしたりブラウザ実装が揃わなかったりと、数年前までは悲観的な見方も多かったWeb Componentsですが、状況はここ数年で大きく変わりました。ブラウザベンダーの合意がとれず、仕様の策定とブラウザ実装に至らなかった“⁠v0⁠”の仕様を経て、現在では次の仕様がWeb Components周辺の技術として安定化しています。

Shadow DOM: DOMツリーにスコープを形成する仕様
Custom Elements: ライフサイクルを持つ新たなHTML要素を定義する仕様
ES Modules: ES2015のimport/export構文をブラウザで解決する<script type="module">の仕様

ブラウザの実装も進んでおり、EdgeがES Modulesを実装済でShadow DOMとCustom Elementsを検討中、Firefoxがそれぞれを開発中、ChromeとSafariではすべてを実装済というステータスです。

	Chrome	Safari	Firefox	Edge	Internet Explorer
Shadow DOM	✅	✅	🚧	🤔	❌
Custom Elements	✅	✅	🚧	🤔	❌
ES Modules	✅	✅	✅🚩	✅	❌

🚩 about:configにてdom.moduleScripts.enabledを有効した時のみ。

デスクトップ環境については、開発が終了しているIE11を含め、EdgeとFirefoxがサポートしていないので、しばらくはポリフィルであるwebcomponents/webcomponentsjsの利用が前提になるでしょう。一方で、モバイル環境についてはAndroidとiOSにおいてほぼすべてを占めるChromeとSafariがこれらの仕様をサポートしており、既にモバイルWebにおいてはWeb Componentsを充分に利用できる状況にあると言えます。モバイルWebをターゲットとしているサービスであれば積極的に導入していけるのはもちろんのこと、ターゲットブラウザを限定しているWebアプリケーションなどでも試してみる価値はあります。

React、Angular、Vueといったライブラリによって、Web開発におけるコンポーネントの設計や思想は広く普及してきました。npmなどのエコシステムを通じて再利用可能なコンポーネントの配布も増えてきましたが、それらのコンポーネントは先に挙げたReactなどのライブラリなどに依存しているものも多いでしょう。Web Componentsであればそうしたライブラリに依存しない形でコンポーネント化し、どのライブラリとも共存していけます。エコスシステムが普及しブラウザなどのサポートが進みつつある今こそ、Web Componentsのメリットを見直すタイミングではないでしょうか。

Service WorkerがもたらすWebの変化

2017年の末日に、Web開発者にとって嬉しいニュースが立て続けに飛び込んできました。それは、最新のWindows Insider Buildに含まれるEdgeとSafari Technology Preview 46のそれぞれでService Workerをサポートしたというニュースです。

Service Workerは、ブラウザで発生するネットワークリクエストのハンドリングや、サーバーからのプッシュデータの受信など、Webに長らく求められてきた機能を実現する強力な仕様です。これまでは実装しているブラウザがChromeとFirefoxのみという状況で充分とは言えないサポート状況でした。しかしEdgeとSafariに実装されることでモダンブラウザによるサポートが揃い、大きく好転するのは間違いありません。

Cache APIを使ったネットワーク通信のキャッシュによるページロードの高速化やオフライン対応、サーバープッシュの受信によるユーザーエンゲージメントの向上など、Progressive Web Appsの文脈においてもService Workerがもたらす影響はWebアプリケーションにとって大きなものです。特に、Safariでのサポートがそう遠くない未来に来ることを考えると、デバイスの性能やネットワーク環境の面で劣るモバイルWebを大きく前進させる年になるでしょう。

クレジットカードのセキュリティとWeb Payments

クレジットカードは非常に便利ですが、オンラインで利用するにはいささか危険が伴います。カード番号と有効期限などが照合できれば決済できてしまうため、カード情報を保持するサービスのデータベースから漏洩するリスクが常に付きまとうからです。

こうした背景から、オンラインサービスにはPCI DSSというカード情報を取り扱うためのセキュリティの世界基準が存在します。アメリカではカード決済を伴うオンライン事業PCI DSS対応の温度感は高く、日本においてもクレジットカード取引におけるセキュリティ対策の強化に向けた実行計画という対応を強める動きもあります。対応方法としては、PCI DSSに準拠してカード情報を扱えるようにするか、カード情報を全く扱わないことです。

カード情報をやりとりせずに決済する手段としては、クレジットカード会社が発行するトークンをPayment Appを通じて取得し、やりとりする方法です。発行されたトークンのみを使ってユーザー、マーチャント、PSP、クレジットカード会社間でトランザクションを実行するので、その過程でカード情報が漏れる等のリスクが小さく済みます。そして、このPayment Appの仕組みをWebで使えるようにするのがPayment Request APIです。

Payment Request APIは決済に必要なインターフェースをブラウザネイティブで提供します。クレジッドカード情報の入力やPayment Appとの連携を担い、それ自身には決済の機能を持ちません。既存のクレジットカード入力フォームを置き換えるとともに、Webにおける決済をより便利でセキュアなものにしてくれます。今後はこのクレジットカード会社が発行するトークンを提供するPayment Appが充実し、Webにおける決済周りの実装はPayment Request APIを使ったものが中心になっていくでしょう。

HTTPS化の更なる浸透

セキュアなWebもここ数年でだいぶ普及しました。Googleが公開している透明性レポートの世界各国におけるChromeでのHTTPSの使用状況を見てみると、2015年には25%程度でしたが2017年の終わりには60%程になっています。

2017年はYahoo!、アメブロ、楽天、Cookpadといった大規模なWebサービスがHTTPSへ移行しました。既にHTTPで提供しているWebサービスをHTTPS化するのは、WebサービスをHTTPSで実装するより遥かに難しいことです。

この背景には、Googleが検索アルゴリズムにおいてHTTPSを優遇していたり、主要ブラウザによるWebページへHTTPでアクセスしている場合の警告表示など、GoogleやMozillaを中心としたWebプラットフォーム従事者の取り組みが後押ししています。

Web標準として新たに策定されているブラウザAPIの利用がHTTPS環境下のみに制限されていることも、開発者を含めたWebアプリケーションの提供者にとっては大きいでしょう。先に取り上げたService Worker、Payment Request APIだけでなく、位置情報を取得するGeolocation APIやカメラにアクセスするgetUserMediaなど、よりユーザーの機密情報に触れるAPIへのアクセスはセキュアな環境においてのみ実行できます。HTTPの新たなバージョンとして定められたHTTP/2もそうです。

HTTPSは既にこれからのWebの前提になっていると言っても過言ではありません。