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

GitHub の FedCM の説明

Federated Credential Management(FedCM)は フェデレーション ID と呼ばれる、プライバシー重視でユーザー フレンドリーなユーザー登録 とログインの方法を提供する API です。たとえば、 Google でログイン やその他のソーシャル ログインに適用されます。

ブラウザ API を作成するには、まず公開ディスカッション用の提案を用意します。FedCM の提案は、GitHub で説明として公開されました。 explainer説明リポジトリで GitHub Issue を作成して、機能設計に関する質問やコメントを投稿できます。フィードバックには、デベロッパーによる追加のユースケースの説明、制約、改善案、サポートの誓約などが含まれます。

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

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

プロトタイプ作成のインテント

この時点で、Chromium エンジニアは機能の実装を開始できます。つまり、機能のプロトタイプ機能が、最初は Chrome Canary で、次に他のリリース チャンネルで、機能フラグの背後でデベロッパー テストに利用できるようになる可能性があります。ユーザーは chrome://flags ページでフラグを設定して、ブラウザで機能を有効にしてテストできます。

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

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

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

Chromium Issue Tracker で問題を報告します。

テストのインテント: 実環境でのテスト

Chrome エンジニアがオリジン トライアルの実行をリクエストする場合は、blink-dev にテストのインテントを投稿することが次のステップとなります(省略可)。

[Intent to Experiment for FedCM].

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

利用可能な Chrome オリジン トライアル の一覧です。

機能の実装に向けて進むには、Blink API オーナーがインテントに「looks good to me」( LGTM)と返信して承認する必要があります。

Blink API オーナーは、ウェブ プラットフォームとその API に精通し、Blink のミッションと価値観にコミットしている、Blink コミュニティから信頼されている少人数の Chromium コントリビューターです。API オーナーは、機能の実装を進めるかどうかを承認するだけでなく、Blink のインテント プロセス自体を監督します。

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

FedCM のテストのインテント投稿に対する LGTM。

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

デベロッパーは、機能のオリジン トライアルに登録して、実際のユーザーが使用する実環境で機能をテストできます。ユーザーが機能を有効にするための操作を行う必要はありません。デベロッパーはテストの結果を共有できます。これにより、機能の反復と進化に役立つ貴重な分析情報とデータが得られます。

リリース インテント: 最終マイルストーン

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

新機能のロールアウト

承認されると、機能は今後のリリースにマージされ、 Chrome のリリース チャンネルを通過します。 新機能のテストと実装は、多くの場合、特別な注意を払って行われます。 一部の機能は、ユーザーの割合を増やしながら段階的にロールアウトされます。 予期しない副作用が発生した場合は、機能をロールバックして再設計することもできます。

非推奨と削除の管理

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

  • 非推奨のインテント
  • 削除のインテント

少し悲しいかもしれませんが、これらは Blink の開発の成功に不可欠です。

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

削除のインテント は、コードをデフォルトで無効にする場合にエンジニアが投稿します。

blink.dev の非推奨のインテントに対する LGTM。

非推奨と削除の重要性

非推奨と削除は、ウェブ プラットフォームの健全性に不可欠です。 これにより、Chrome はエンドユーザーやウェブ デベロッパーにとって適切に機能しない機能を削除し、コードベースの複雑さを軽減できます。たとえば、 AppCache の設計上の問題 は、安定版ブラウザの本番環境サイトで使用された後に発見され、 最終的に API は削除されました。非推奨と削除は、潜在的な攻撃ベクトルを減らすことで、Chrome の安全性とセキュリティを維持するのにも役立ちます。

すべての Blink のインテントと同様に、Chrome チームは慎重に判断を下すよう努めています。続行する前に、機能の使用率やその他のデータを確認します。機能を削除するためのハードルは非常に高く、機能がごく一部のユーザーによって使用されていて、より優れた代替手段が利用可能な場合にのみ削除されます。

Chrome のステータスで機能の進捗状況を追跡できます。 ここでは、更新情報の登録、バグの報告、その他のリソースの検索ができます。

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

新機能を追跡するには、 Chromium ブログをフォローし、 blink-dev ディスカッション グループに参加してください。グループでは大量のメールが送信される可能性があるため、1 つのインテントに登録することをおすすめします。 Blink のインテントの スプレッドシートを表示できます。

Blink のインテントが本当に気に入った場合は、 自動化された Blink インテント トラッカー サービスを基盤に構築することもできます。

次のステップ

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