2020年10月23日

#4 「HTMLの新たなAPI Portals」

今回は比較的新しいAPIであるPortalsについて、その概要と現状、iframe要素との違いなどについてお話ししました。

名前は聞いたことあるけどよく知らない、気になってる！というかたはぜひ聴いてみてください！

※ オフラインのため、音声ファイルを再生できません。ネットワーク状況をご確認の上、再度アクセスしてください。

加藤: こんにちは！
板垣: こんにちは。
加藤: ミツエーテックラジオは株式会社ミツエーリンクスのスタッフがWebデザイン、WebフロントエンドなどのWeb技術に関するニュースやツールをシェアしたりするためのPodcastです。本日の司会は設計チームの加藤が務めさせていただきます！今日のゲストは板垣君です！よろしくお願いします！
板垣: よろしくお願いします。
加藤: 早速ですが今回はWeb標準の中では比較的新しい仕組みである「Portals」をテーマに、そのPortalsの構成要素だったり、仕組みだったり、その効果的な使い方について話していきたいなと思っています。板垣君は去年のミツエーリンクスのアドベントカレンダーでも、portal要素についての記事を書いてましたよね。
板垣: はい、そうですね。
加藤: じゃあ、まず始めにそのPortalsの概要、どんなものなのかってところを説明してもらってもいいですか？
板垣: えーPortalsというのはですねWICGによって提案されているページ間の遷移をシームレスにすることができる仕組み及び仕様の総称を指しています。このPortalsの中にはHTMLの新要素であるportal要素だとかportal要素のAPIなどの仕様が含まれていまして、それらを組み合わせることによってページ遷移のシームレス化を実現します。ちなみにここで言うページ遷移のシームレス化というのはですね、ページ遷移のリクエスト時に発生する画面のちらつきをなくして、あたかも超高速で遷移先のリソースを読み込んでいるかのように見せることを指しています。実際にはportal要素によって読み込まれるページというのはですね、読み込まれたタイミングで必要なリソースが先読みされているのでストレスのない画面遷移が実現できて、結果的にはUXの向上につながってるというわけですね。
加藤: ありがとうございます。そのページ遷移のシームレス化って、これまではそのシングルページアプリケーションでしかこう再現できないSPAの専売特許感みたいなものがあったと思うんですけど、それがそのPortalsを使うと通常のWebサイトでもある程度を実現できるようになるって感じですかね。
板垣: そうですね。ただPortalsは、まだ提案段階なんですね。現時点で実装してるブラウザもGoogle Chromeのみなんですよ。またChromeであってもExperiments（chrome://flags/）からですね、Portalsの項目を有効にしないと使用できないので、現実的に考えて実案件レベルでの使用っていうのは慎重に行ってもらう必要があるのかなと考えてます。
加藤: 確かにそのGitHubの仕様をこうさらっと見てみたりとかしたんですけど、そこにも「TODO」って書いてあったりとか、まだ討論段階の議題が多いなーっていう印象でしたね。
板垣: そうですよね。
加藤: ちなみに、さっきの説明の中でportal要素だけじゃなくてAPIについても触れられていたんですけど、portal要素とそのAPIっていうのはそれぞれどういう役割を持ってるんですか？
板垣: そうですね、それで言うとまず前提としてシームレスなページ遷移をするためにはですね、portal要素単体だと実現はできなくてですね。JavaScriptのAPIを一緒に使用する必要があります。役割では言えば、シームレスなページ遷移をするためのものなんですけれども、その中でもこう重要なactivateメソッド軸に話を進めていきますと、portal要素のsrc属性に遷移先のURLを指定してあげると、要素内にですねこう指定したページを表示できるんですね。これって言うのはこうiframe要素に似てるとは思うんですけど、iframe要素とは違ってportal要素では要素内に表示されたページのコンテンツを操作することができないといった制約があります。
加藤: ってことはそのよくSNSのシェアボタンとかがプラグインでiframe要素として提供されている場合が結構あると思うんですけど、そういう使い方はできないってことですね。
板垣: そうですね。ただそのコンテンツに対してインタラクションができない代わりに、portal要素は、要素それ自体がですねbutton要素だとかa要素と同じようにフォーカス可能な要素となっていますので、そのportal要素を起点としたイベントを付与することが可能となっているんですね。これを利用してportal要素をクリックしたときに、その要素の幅と高さをビューポートと同じになるようなアニメーションをさせて、そのアニメーションが終わったと同時に先ほど述べたactivateメソッドを実行してあげれば、シームレスな画面遷移をユーザーに提供できるというわけです。
加藤: なるほど。activateメソッドを実行したタイミングで初めて、URLが切り替わるって感じですよね。
板垣: そうですね。
加藤: 今の話だと、そのシームレスな遷移を実現するためにはJSでactivateメソッド実行しないといけないってことだったんですけど、例えばJSオフ時とか、そのportal要素単体の場合はどういう機能になるんですか。
板垣: そうですね、現状だとただ外部サイトを一部映し出すフレームと化してしまいます。で、もちろんJSオフ時とかだと、映し出されてる外部サイトもJSオフ時の見た目になっちゃったりしますね。
加藤: 「Portal」っていうのの翻訳かけてみたんですけど、日本語で言うと「玄関」っていう意味があるらしくてHTML要素単体としては他のページへの玄関とその先を見せるって言う役割を持ってて、そのドアの先に行くためにはJSが必要っていう感じですよね。
板垣: そうですね、イメージとしてはそう思います。
加藤: ありがとうございます。なんとなくこう概要は見えてきました。ところでそもそもの話なんですけど、このPortalsっていう概念が生まれた経緯というか、モチベーション的なところはどういうとこにあったんですかね？
板垣: そうですね…これまで話したことって実はもともとiframe要素でそれっぽく実現することができていたようなんですよ。ただ、そうではなくてDOMを再構築させずに、実際にページ遷移する機能をiframe要素に実装するのはどうだろうかという提案がですねWICGのディスコースに投稿されたのが発端のようです。
加藤: ってことは発端もそのシームレスなページ遷移をしたいっていう要望があって、議論が始まったっていう感じなんですね。
板垣: そうですね。
加藤: 画面遷移の他にPortalsが使えるとか、画面遷移以外に解決できることとかっていうのはあったりするんですか？
板垣: そうですね、あのPortalsはその機能上iframe要素の代わりに使用することができると言っても過言ではないんですよね。しかもiframe要素に比べるといくつか制約があったりするので、その制約があることでiframe要素が潜在的に抱えているセキュリティ問題だとか、パフォーマンスに悪影響を与えるような問題を回避できると言われています。もちろん完全に代替できるわけではないんですけれども、Web広告だとか静的な外部コンテンツなど、そういったものに関してはiframe要素からportal要素に置き換えて使うのが今後のスタンダードになっていくんじゃないかな、と予想されてます。
加藤: そうなんですね…！
板垣: はい。
加藤: やっぱりその、機能が似ているっていう点でiframeとの違いってところに目がいってしまうんですけど、他にiframeとの違いってあったりするんですか？
板垣: そうですね…こうportal要素は別ウィンドウに開けない、だとかそういった細かな違いはあるんですけども、特定のページを別のページから読み込むことができるのかみたいな設定、要はオプトイン・オプトアウトの仕方もiframe要素とは少し異なっています。 iframe要素だとX-Frame Optionsヘッダーを利用すると思うんですけれども、Portalsのオプトイン・オプトアウトはSupports Loading Modeというヘッダーを利用して制御を行う、そういった提案がされてます。
加藤: X-Frame Optionsというのはレスポンスヘッダーの1つで、iframe要素のsrc属性として指定されても、このページを読み込めないよっていう指定をするためのヘッダーですよね。
板垣: はい、そうですね。
加藤: Supports Loading Modeもレスポンスヘッダーのひとつかなにかですか？
板垣: そうですね。このSupports Loading Modeもまだ提案段階のものなんですけれども、Portalsとは別にですね、Alternate Loading Modeというものが提案されておりまして、これはですね、ページ自体がログインなどの資格情報なしで、プリフェッチ・プリレンダーできるかどうかを示すものになっています。で、これをレスポンスヘッダーに加えるか、HTMLのmeta要素として定義することでこのページはportal要素から読み込めるコンテンツですよー、と定義することができるんですよ。逆を言えばiframe要素はオプトアウトしかできないんですけれども、portal要素では明示的にオプトインする必要があるというのは大きな違いなんじゃないかなと思います。
加藤: これmeta要素でも指定できるのは地味に便利ですね。
板垣: わかります…！
加藤: 最後にその各ブラウザベンダーの実装状況とか最新の動向ってどんな感じになってるか教えてもらえますか？
板垣: わかりました。あのPortalsのGitHubリポジトリのステークホルダーフィードバックセクションにそれらしい記述があったので確認してみたんですけれども、ブラウザベンダーで言うとフィードバックを返しているのはですね、Firefoxのみでして、そのFirefoxもですね、今年の5月にPortalsの追加を延期決定していることからですね、クロスブラウザでPortalsを使用するっていうのはもう少し時間がかかるのかなぁといった印象を持っています。ただ、これは主観ではあるんですけれども世間的に見るとPortalsについては肯定的な意見が多数を占めている印象があるのでこれからが期待できるんじゃないかなと思っております。
加藤: なんかそのChrome Dev Summitで毎年Portalsのセクションが設けられてるけど、なかなかこう…他のブラウザには実装されないという現状はありますよね。
板垣: そうですね。
加藤: 個人的にはこのPortalsって名前がすごいかっこいいというか、いいなと思っていて、使いたいなぁっていう気持ちはありますね。現状では、対応してるブラウザではリッチな体験ができるといったように活用していくのはありかもしれないって感じですかね。
板垣: そうですね！
加藤: はい、ありがとうございます！というわけで今回のミツエーテックラジオではPortalsについての概要、現状についてお話ししてきました。 PortalsのGitHubにも書いてあったんですけども、機能が似ている点でiframeと比較されることが多いのでそちらに目が行きがちになってしまうんですけど、ユーザー目線で見るとこう役割的にはa要素に近い役割もあるのでPortalsの有効な使い方のヒントというのは、その辺にあるのかもしれません。今後も可能性を探っていきたいと思っています！
加藤: 最後にミツエーリンクスではスマートなコミュニケーションをデザインしたいUI デザイナー、UI 開発者を募集しています。採用サイトではオンライン説明会やオンライン面接なども行っていますのでぜひチェックしてみてください。またこのポッドキャストはApple Podcast、Google Podcast、Spotifyで配信していますので、お好みのプラットフォームでフォローをいただけると、最新のエピソードをすぐ視聴できます。こちらもぜひご活用ください。
加藤: それでは、今日はこの辺で！ありがとうございました！
板垣: ありがとうございました！

2020年の記事一覧に戻る