Microsoft Edge Japan

Microsoft Edge と Internet Explorer に関する情報をお届けします。

Microsoft Edge と Web コンポーネント

前回に引き続き、マイクロソフト米国本社の Edge 開発チームのブログから、Edge のWeb Components に関する記事をピックアップし翻訳したものをお送りします。
公開される順番は、より情報量が多いものからとさせていただきますので、時系列順ではありませんのでご了承くださいませ。

この記事はマイクロソフト米国本社の Edge 開発チームのブログ Microsoft Edge Dev blog の記事、「Microsoft Edge and Web Components」 (2015/7/15) の記事の抄訳です。

 

Microsoft Edge と Web コンポーネント

Editor’s note: これは Microsoft Edge エンジニアの Travis LeitheadArron Eicholz による、Web コンポーネントについての 2 部構成の記事の第 2 回目です。Microsoft の見解と Web コンポーネントの背景について詳しくは、「コンポーネント化を Web の世界に: Web コンポーネントの概要」をご覧ください。

昨日の投稿では、Web コンポーネントの展望について、Microsoft の考えをお伝えしました。この投稿では、Microsoft の実装のロードマップや、他のプラットフォームの取り組みと関連して、現在 Web コンポーネントの優先順位はどうなっているのかなど、Web コンポーネントについて繰り返し聞かれる質問のいくつかにお答えします。Microsoft では Web コンポーネントの可能性に大いに期待を寄せており、本日ここに、開発者の皆様から寄せられたUserVoice リクエスト #3 (英語) と中核の Web Components テクノロジの 1 つである HTML Template 要素の開発を開始 (英語) することを発表いたします

 

Microsoft は Web コンポーネントについてどのように考えていますか。

大勢の方から、「Microsoft は Web コンポーネントについてどのように考えているか」と聞かれます。Web コンポーネントには、Web コミュニティに提供できるものが多くあります。Web コンポーネントによって、大規模な Web 開発が劇的にシンプルになるだけでなく、既に HTML でおなじみの便利な宣言型のパターンも強化できるものと大いに期待しています。Microsoft は標準化にも携わっていますが、Web コンポーネントは、コミュニティでの実験を促し、将来の標準化の方向性を知るうえで非常に有効な手段になるとも考えています。

Microsoft では、特定の Web コンポーネントの技術的な問題に関して、現在のディスカッションが進む傾向がある方向性を頼もしく感じています。ブラウザーベンダーや他の参加者から的を得た質問と難しい問題 (英語) が挙げられ、討議されています。Mozilla の Wilson Page 氏は、他のベンダーとの会合で最近討議していた (英語) 技術的な問題のいくつかについて全体像がよくわかる記事 (英語) を公開しています。これらの問題の一部 (Custom Elements 関連) については、今月開催される会合の議題となっていて、解決できればと考えています。初期の仕様は最初の草案であり、Web Components に至るまでの長い歴史があります。クロス ブラウザーについてのコンセンサスは、準拠すべきクロス ブラウザーの相互運用性の形でようやくまとまり始めました。

 

Microsoft が Web Components をまだ実装していないのはなぜですか。

2 番目によく聞かれる質問は、「Microsoft が Web Components をまだ実装していないのはなぜか」です。

よくあることですが、Web Components は、単一の機能ではないことを説明する必要があります。”Web Components 機能群” という名前の方が適しているかもしれません。Web Components には、連携する多数の独立したテクノロジが含まれています。これが Web Components の潜在能力の秘密です (詳細については、昨日の「コンポーネント化を Web の世界に: Web コンポーネントの概要」をご覧ください)。この機能群に含まれるテクノロジは Shadow DOMCustom ElementsTemplatesImports などがありますが、CSS Custom Properties も Web コンポーネントの一部であると考えることができます。CSS Houdini の取り組み (英語) の対象範囲を知るにつれて、特定のカスタム要素タグ名とは切り離されたコンポーネントのスタイル設定を開発するうえで、CSS Houdini が関連する役割を果たす可能性にも気付いています。Web Components の仕様は確定していなく、検討、優先順位付け、解決すべきことが山ほどあります。既に Google Chrome の現在の実装は、最近の仕様の変更との互換性がない状態です。前述のとおり、Microsoft は、Google、Apple、Mozilla の他、いくつか投資先の JavaScript ライブラリと協力しながら、標準化プロセスへの積極的な参加を続けています。

もう 1 つの理由は、エンジニアリング リソースをどこに集中させているかに関係します。EdgeHTML エンジンの分離 (英語) の一環として (実際はさらにその少し前から)、20 年前に導入された DOM 実装をアップグレードすべき時期であることに気付いていました。IE のレガシの内部データ構造の上に Shadow DOM などのコア機能を構築すると、実装に少なくとも 2 倍の時間とコストがかかり、不具合も多発していたでしょう。Microsoft の Web Components へのエンジニアリングの投資は、実質的には DOM をアップグレードする壮大な取り組みによって実質的には始まっています。DOM をアップグレードすることで、将来の Web コンポーネント テクノロジの内部の拡張性が高まるだけでなく、Microsoft Edge の DOM の次世代のパフォーマンスの基礎が築かれます。

現在、DOM アーキテクチャのオーバーホールは、かなり進んでいます。この作業は、今月の Microsoft Edge のローンチ後も続く見込みです。Microsoft Edge のローンチ時点で DOM のアップグレードの詳細と、Web Components のロードマップの最新情報をお知らせする予定です。

 

Microsoft Edge に Web Components が実装されるのはいつごろでしょうか。

新しい DOM のゴールが近付いてきたら、Web 開発者にとっての不足機能を埋めるために、現在実現できることを検討します。お客様やパートナー企業からのフィードバックを踏まえると、未対応のブラウザーでの Web Components によるポリフィルで最も難しいのは、Template 要素の動作であると理解しています。Template 要素を使うと、DOM ツリー自体からテンプレートのコンテンツを分離しつつ、コンテンツの複製と置換を効率よく実行できます。本日ここに、Microsoft Edge に HTML Template 要素のサポートを追加する開発を始めることを発表いたします。これは、Microsoft の Web Components の旅の始まりに過ぎません。

Template のサポートの次は、DOM の刷新が完了後に、Shadow DOM の実装が目標です。Shadow DOM は Custom Elements の次にポリフィルが難しい機能です。その後、第 1 世代の Web Components の仕様の残りを評価する計画です。当然ながら、仕様は進化し続けています。その他の Web コンポーネント関連のテクノロジの重要性が高くなれば、途中で優先順位を変えることもあります。いつものことながら、最新のステータス ページを定期的にご覧ください。

引き続き Web Components に関心をお持ちいただき、ご支援いただけますと幸いです。@MSEdgeDev にフィードバックをどしどしお寄せください。よろしくお願いいたします。

– Microsoft Edge、プログラム マネージャー、Travis Leithead
– Microsoft Edge、プログラム マネージャー、Arron Eicholz