Blink インテントとは

エンジニアが Blink レンダリング エンジンに変更を加える場合は、blink-dev メーリング リストに投稿して、続行の承認を得ます。これらのメーリング リスト投稿は、Blink インテントと呼ばれます。

Chromium ベースのウェブブラウザは、Blink レンダリング エンジンを使用して、コードとリソースを表示および操作可能なウェブページに変換します。

blink-dev メーリング リスト

Blink インテントの仕組み、重要性、Blink に新機能が導入される仕組みについて説明します。

Chromium は、Chrome やその他のブラウザやフレームワークが構築されているオープンソース ブラウザ プロジェクトです。Blink は、Chromium で使用されるレンダリング エンジンです。

新しい機能を Blink に実装するには、Chromium プロジェクトのオープンな開発プロセスを経る必要があります。「新機能」とは、ブラウザのコードまたはアーキテクチャの変更または追加を指します。たとえば、新しい JavaScript API、Blink コードのパフォーマンスの大幅な向上、ブラウザの外観や機能に関するその他の変更などです。

オープンでコラボレーション重視のプロセス

Chromium は、数千人のコントリビューターが参加する巨大で複雑なプロジェクトです。Chromium に変更がある場合は、各マイルストーンで、幅広いウェブ エコシステムに設計と実装についてコメントを求める機会となります。

可能な限り、新しい機能はウェブ プラットフォーム全体で相互運用可能にする必要があります。1 つのブラウザにのみ実装しないでください。ウェブ デベロッパーは、ブラウザが想定どおりに動作しなかったり、ブラウザやプラットフォームごとに異なるコードを記述しなければならないような予期せぬ事態を避けたいと考えています。Blink インテントは、変更プロセスを構造化して規制し、変更をより予測可能にし、予期しない変更を減らすのに役立ちます。これはウェブ デベロッパーにとって有益です。

ユーザーにとって、ブラウザ ベンダーは変更によってウェブサイトが機能しなくなることのないように注意する必要があります。サイト所有者がウェブサイトのメンテナンスを取りやめるケースは非常によくあります。一部のサイトは数十年も更新されていません。ブラウザ ベンダーは、破損につながる可能性がある変更を行う際に、この点を考慮する必要があります。

アイデアから提案書まで

ウェブ プラットフォームの変更や更新に関する提案は、ユーザー、企業、ブラウザ エンジニア、ウェブ デベロッパーなどの関係者とのコンサルトや調査から得られます。この調査により、Chrome チームはプラットフォームに不足している機能や変更が必要な機能を把握できます。ウェブ プラットフォームの変更や新機能の提案は、最初はページ上の単なる文章です。エンジニアはドキュメントを共有し、同僚からのフィードバックや議論を得ます。

例: FedCM

Federated Credential Management(FedCM)は、ユーザーの登録とログインを管理するプラットフォームに、連携 ID と呼ばれる新しい優れたメカニズムを提供する API です(「Google でログイン」や「GitHub でログイン」を選択する場合など)。

FedCM などの提案が公開討論の準備が整うと、GitHub に説明として公開されます。この時点で、GitHub の説明リポジトリで Issue を作成することで、誰でも機能の設計について質問やコメントを送信できます。フィードバックには、追加のユースケースや制約の説明、改善案の提示、サポートの表明などが含まれます。

GitHub の FedCM の説明

提案がW3C などの標準化団体によって承認されると、関係者はW3C ワーキング グループなどのウェブ標準グループのディスカッションに参加したり、プレゼンテーションを視聴したりできます。

エンジニアが新しい機能や Blink レンダリング エンジンの変更に取り組んでいるマイルストーンに応じて、blink-dev ディスカッション グループに投稿し、機能の実装に向けて次のフェーズに移行する予定であることを説明します。このような投稿は「インテント」と呼ばれます。誰でも blink-dev グループに登録して、Blink の新機能の進捗状況に関する通知を受け取ることができます。また、個々の機能に登録して最新情報を受け取ることもできます。

プロトタイプ作成の意向: 最初のチェックポイント

この時点で、Chromium エンジニアは機能の実装を開始できます。つまり、この機能のプロトタイプ機能は、機能フラグを有効にして、まず Chrome Canary で、その後他のリリース チャンネルで、デベロッパー向けテストに提供される可能性があります。すべてのユーザーは chrome://flags ページでフラグを設定して、ブラウザで機能を有効にしてテストできます。

ただし、chrome://flags ページから設定できるフラグは限られています。よりきめ細かい制御を行うには、コマンドライン フラグを使用してターミナルから Chrome を実行します。一部の新機能は、Chrome Canary でテスト用にリリースされるまで利用できません(ただし、これはまれなケースです)。一部の機能には独自のフラグはありませんが、experimental-web-platform-features フラグが有効になっている場合は利用できます。これは、実装に 3 ~ 6 か月以内しかかからない「小さな」機能に一般的に当てはまります。

プロトタイプに関するフィードバックの収集

新しい機能のプロトタイピングが開始されると、Chromium エンジニアはディスカッションと初期テストを開始します。この時点でのフィードバックは、提案の検証と反復処理に不可欠です。Chrome の実装についてコメントするには、Chromium のバグに投稿してください。

Chromium Issue Tracker で問題を作成します。

テストの意図: 実世界でのテスト

Chrome エンジニアがオリジン トライアルの実施をリクエストする場合は、blink-dev で試験運用の投稿を行うこともできます。

FedCM のテスト目的

オリジン トライアルは、新しいウェブ プラットフォーム機能や試験運用版の機能をテストする方法です。機能のオリジン トライアルに登録して、トライアルのトークンを取得します。この機能は、トークンを提供するすべてのページで有効になります。

利用可能な Chrome オリジン トライアルのリスト。

機能の実装を進めるには、Blink API オーナーが、Intent に「looks good to me」(LGTM)という投稿を返信して承認する必要があります。

Blink API オーナーは、ウェブ プラットフォームとその API に精通した Chromium コントリビューターの小規模なグループです。Blink コミュニティによって、Blink の使命と価値観にコミットし、良好な状態にあると認められています。API オーナーは、実装に向けて機能を承認する(または承認しない)だけでなく、Blink インテントのプロセス自体を監督します。

テストの開始には、API オーナーから少なくとも 1 件の LGTM が必要です。

FedCM のテストに関する投稿に対する LGTM

オリジン トライアルの価値

デベロッパーは、機能のオリジン トライアルに登録し、実際の環境で本番環境で機能をテストできます。この場合、ユーザーが機能を有効にするための操作を行う必要はありません。デベロッパーはテストの結果を共有できます。これにより、フィーチャーのイテレーションを重ねて進化させるうえで役立つ分析情報とデータを得ることができます。

発送の意向: 最後のマイルストーン

リリースの意向は、機能が完成し、フラグやトライアル トークンを必要とせずに、Chrome Stable のすべてのユーザーを対象に一般提供として実装する準備が整ったことを示します。実装を進めるには、リリースの意向について API オーナーから 3 件の LGTM を得る必要があります。

新機能のリリース

承認されると、機能は今後のリリースに統合され、Chrome リリース チャンネルに進みます。新機能のテストと実装は、多くの場合特別な注意を払って行われます。一部の機能は、段階的に、より多くのユーザーに公開されます。予期しない副作用がある場合は、機能をロールバックして再作成することもできます。

機能のライフサイクルの管理: 非推奨と削除

Blink インテントには、他に次の 2 種類があります。

  • 廃止の意向
  • 削除の意向

悲しい話に思えるかもしれませんが、実際には Blink 開発の成功に不可欠です。

エンジニアは、機能の非推奨が予定されていることをデベロッパーに警告する際に、非推奨にする意向を投稿します。たとえば、Chrome DevTools コンソールで非推奨に関するサポートと情報を提供します。

エンジニアがコードをデフォルトで無効にすることを意図している場合、削除の意向が投稿されます。

blink.dev での非推奨化の意思に関する LGTM。

非推奨と削除の重要性

非推奨と削除はどちらも、ウェブ プラットフォームの健全性にとって重要です。エンドユーザーやウェブ デベロッパーにとってうまく機能しない機能を Chrome から削除し、コードベースの複雑さを軽減できます。たとえば、安定したブラウザの製品サイトで AppCache が使用されたときに、AppCache の設計に関する問題が見つかり、最終的に API は削除されました。非推奨化と削除は、潜在的な攻撃ベクトルを減らすことで、Chrome の安全性とセキュリティを維持することにも役立ちます。

すべての Blink インテントと同様に、Chrome チームは慎重に判断を下すよう努めています。チームは、機能の使用率などのデータを確認してから、削除を進めます。実際には、機能を削除するためのハードルは非常に高く、ごく少数のユーザーしか使用しておらず、より優れた代替手段が利用可能な場合にのみ、機能が削除されます。

機能の進捗状況は Chrome のステータスで確認できます。ここでは、最新情報の配信登録、バグの報告、その他のリソースの確認も行えます。

chromestatus.com の Chrome 機能ロードマップ

新機能の最新情報については、Chromium のブログをご覧ください。すべての Blink インテントを把握するには、blink-dev ディスカッション グループに参加してください。そのため、大量のメールが届く可能性があります。または、単一のインテントにサブスクライブすることもできます。Blink インテントのスプレッドシートは、bit.ly/blinkintents で確認できます。ブリンク インテントに本当に興味がある場合は、自動ブリンク インテント トラッカー サービスを基盤に構築することもできます。

次のステップ

Chrome のリリース チャンネルとは何ですか?をご覧ください。