Chrome Dev Insider: CSS と UI エディション

Chrome Dev Insider 第 2 弾へようこそ。このメールでは、コミュニティと Chrome の最新情報をお知らせします。今回は、Google の取り組み方に関する内部情報と、注目すべき重要な最新情報をご紹介します。

Chrome デベロッパー リレーションズ チームの Rachel Andrew と申します。web.devdeveloper.chrome.com のコンテンツ リードとして、オープンウェブ標準と CSS に重点を置いて 20 年以上ウェブに携わっており、CSS ワーキング グループのメンバーです。

2 か月前、Google I/O が終了しました。そこで、ユーザー情報の安全性とプライバシーを維持しながら、ウェブの速度と機能を向上させるためのデベロッパー支援について、最も重要な最新情報を共有しました。

特に注目すべき点のひとつは(コミュニティの皆様が注目してくださったことを嬉しく思います)、ウェブ上での CSS と UI の機能をさらにサポートするために、チームが膨大な作業を行っていることです。今回の Chrome Dev Insider では、この取り組みの背景、CSS デベロッパーと UI デベロッパーのサポートに向けた取り組み、今後の展望についてご紹介します。そのため、今回の Insider を担当させていただくことを大変嬉しく思います。

ニュース トピック

最初の Chrome Dev Insider では、ブラウザ ベンダーとエコシステムのプレーヤーが提携して、すべてのブラウザでサポートされるウェブ機能の拡充に取り組んでいる Compat 2021Interop 2022 のイニシアチブに関する最新情報をお伝えしました。ブラウザの非互換性は CSS デベロッパーにとって最大の課題の 1 つであるため、このイニシアチブでは CSS に重点を置いています。

ほとんどのユーザーにとっては新しい情報ではないかもしれませんが、さまざまなブラウザですでに進展していることは喜ばしいことです。

Chrome Dev 71、Firefox Nightly 74、Safari TP 73。
2022 年 3 月の試験運用版ブラウザのスコア。
Chrome Dev 77、Firefox Nightly 80、Safari TP 80。
2022 年 7 月の試験運用版ブラウザのスコア。最新のスコアを確認する

先月、Safari 16.0 ベータ版の大規模なリリースが発表されました。このリリースには、コンテナクエリサブグリッドフレックスボックス インスペクタなどの魅力的な機能が含まれています。Firefox と Chrome の最近のリリースには、多くの魅力的な機能と修正が含まれています。安定版とベータ版のブラウザの重要な点については、ウェブ プラットフォームの新機能に関するシリーズの投稿で毎月取り上げています。

内部情報: CSS デベロッパーと UI デベロッパーをサポートする

2022 年は CSS 機能にとってエキサイティングな年になりそうです。そこで、その舞台裏をご紹介します。ウェブ UI と Devtools のデベロッパー リレーションズ リードである Una Kravets 氏と、CSS と HTML API に重点を置くウェブ UI プロダクト マネージャーである Nicole Sullivan 氏に、Chrome が UI デベロッパーをサポートするまでの経緯について話を伺いました。

まずは、お客様についてお伺いします。

Nicole: Chrome のウェブ UI のプロダクト マネージャーです。特に、新しい CSS と HTML の API、UI を構築するデベロッパーとデザイナーを対象としています。コンテナクエリスコープ垂直リズムなど、非常に重要な API が登場し、今後も期待できる分野です。

Una: 私はウェブ UI と DevTools の DevRel チームをリードしています。Google は、ウェブ プラットフォームの UI エンジニアをサポートし、成功に必要なツールを用意することに重点を置いています。これには、CSS API と HTML コンポーネント、アクティブな変更とフィードバックを確認するための DevTools 機能が含まれます。

Chrome の UI デベロッパー向けのサポートは、ここ数年で急速に進歩しています。ここまで時間がかかったのはなぜだと思いますか?最大の課題は何でしたか?

Una: この作業の重要性と優先すべき理由を示すために、いくつかの作業が必要でした。まず、2019 年の MDN DNA アンケートから始めました。このアンケートでは、UI がプラットフォームの主要な問題点の 1 つとして特定されています。それ以降、MDN と Google 独自の社内向けデベロッパー満足度調査を通じて、データをガイドとして活用し続けています。その結果、リーダーシップからのより深い賛同を得ることができ、UI 領域で最もリクエストの多いデベロッパー機能のエンジニアリング作業を優先できました。これらの機能は、Compat 2021Interop 2022 などのイニシアチブの大部分を占めるものとなっています。

Nicole: リーダーシップの賛同を得るだけでなく、これらの API をデベロッパーに提供する適切な方法を見つける必要がありました。Chrome に初めて入社したとき、Layered APIs(LAPI)というプロジェクトでこのことを間違えました。LAPI は、デベロッパーがコンポーネントをドロップインできるエクスペリエンスを提供することを目的としていました。それでも、これは目指すべき素晴らしい結果だったと思います。しかし、多くのミスを犯しました。最初に、トースト通知仮想リストに重点を置きました。トーストはアクセス可能にすることはほぼ不可能で、仮想リストは正しく作成するのが最も難しいコンポーネントの一つです。意図は良かったものの、デベロッパーの役に立たなかったため、このプロジェクトは終了しました。失敗から学ぶのは難しいですが、間違いを犯すたびに、現在進行中の CSS と HTML の復興につながります。

LAPI についてもう少し詳しく説明します。どうしてですか?

Nicole: LAPI の場合、ウェブにはネイティブ UI の構築に近い、ドロップイン コンポーネントのデベロッパー エクスペリエンスが必要であることがわかりました。自転車の再発明がデベロッパーの足かせになっていることは明らかでした。これまでに作成したタブの数は数え切れません。そのため、JavaScript をブラウザに同梱することで解決しようとしましたが、これは非常に困難でした。これまで、ブラウザで JavaScript をリリースした人は誰もいませんでした。また、ブラウザのレンダリング エンジンを動かす C++ コードと JavaScript をどのように連携させるべきか明確ではありませんでした。他のブラウザ ベンダー(Mozilla 様、ありがとうございます)の意見を参考に、そのアプローチを止め、Open UI でより優れた方法を見つけることができました。HTML と CSS を活用することで、柔軟で宣言的なソリューションを実現できます。宣言型であるため、JavaScript では簡単にできなかった方法で、ユーザー補助機能を組み込むことができます。今後の展開にご期待ください。必須の UI デザイン パターンである selectmenu、ポップアップ、ツールチップ、ナビゲーション、アコーディオン、タブ、カルーセル、切り替えのサポートに取り組んでいます。

これまでに多くのことを学びました。また、CSS Houdini など、この分野で他の取り組みもあったと聞いています。ストーリーとは

Una: そうです。CSS Houdini もコミュニティから学んだものです。Houdini には便利な機能がたくさんありますが、その多くは低レベルすぎて、広く採用され、サポートされていません。低レベルの API を実装しても、必ずしもデベロッパーの負担が軽減されるとは限らないことがわかりました。代わりに、より上位レベルのソリューションとニーズに焦点を当てることで、エコシステムの改善に必要なクロスブラウザ サポートとランディングを獲得できました。進捗状況のトラッキング用シート: https://ishoudinireadyyet.com/

クロスブラウザ サポートについて言えば、Interop 2022 や Open UI などのイニシアチブは、コミュニティに大きな成果をもたらしているようです。デベロッパーからどのような意見が寄せられていますか?

Una: デベロッパーの皆様からよく寄せられる問題点のひとつは、「ブラウザ間でデザインを同じように動作させる」ことです。Google は、他のブラウザ ベンダーと連携して、リクエストの多いデベロッパー向け機能を優先してリリースすることで、この問題に対処しています。コミュニティから寄せられたフィードバックは、圧倒的に好評です。さらに、RenderingNG と呼ばれる大規模なアーキテクチャの再設計により、これらの機能の一部を大幅に高パフォーマンスでリリースできるようになりました。デベロッパーは、長年要望していた機能がようやく開発され、クロスブラウザでリリースされることを喜んでいます。

Nicole: コミュニティの期待の高まりは明らかです。Twitter でご覧いただけます。:)

前のパラグラフで説明したツイート。

エコシステムとの連携は、開発者の負担を軽減するうえで重要な要素であることが実証されています。お客様のチームがこの件に多くの作業を費やしていることは承知しております。詳細をお知らせいただけますか?

Nicole: まず、デベロッパーがウェブ上で構築するプロジェクトにはいつも感心しています。デベロッパーは、小さなライブラリから完全なフレームワークまで、素晴らしいものを構築しています。素晴らしいクリエイター コミュニティです。Chrome では、これらのプロジェクトとの連携を強化するためのさまざまな取り組みを行っています。

たとえば、数年前に Google は React や Angular などの JavaScript フレームワークの使用を開始しました。メタフレームワーク(Next、Nuxt、Gatsby など)。昨年、Google は Sass、Bootstrap、Material などの UI ツールとフレームワークでも同様の取り組みを開始しました。来年は、デベロッパーの作業を楽にする GreenSock などのツールと連携できることを願っています。Smashing Conference で GreenSock の Cassie Evans さんの講演を拝見し、アニメーション分野の皆さんと協力できることを心から楽しみにしています。

では、ウェブ UI エコシステムの最大の機会はどこにあるのでしょうか?

Una: 大きな機会という点では、カスタマイズ可能なウェブ エクスペリエンスの可能性はまだほんの一部にすぎません。コンテナクエリや CSS のユーザー設定メディア機能などの新しい API により、デベロッパーがレスポンシブ デザインを捉える方法が再定義されています。また、デベロッパーとデザイナーがウェブサイトにアクセスするユーザーと連携して作業できるコラボレーション デザイン エクスペリエンスにも期待しています。

ニコール様、チームの今後のロードマップについて教えてください。

Nicole: すべての調査が製品につながるわけではありませんが、現在、非常に期待しているものがたくさんあります。

最初の点について、Una が触れましたが、レスポンシブでコンポーネントベースのデザインが可能になります。カラーシステムを設計するためのツールが含まれているため、デザイナーはダークモードなどのユーザー設定に対応できます。たとえば、OKLCH 色空間では、色相にかかわらず明るさが一定に保たれます。デザイナーは、色の選択から色の関係の設計に移行できます。色が濁ったパレットにならずに済みます。

また、コンテナ クエリカスケード レイヤ、親セレクタ(:has)、スコープ付きスタイルネストなど、最もリクエストの多い API にも取り組んでいます。デベロッパーは、再利用可能なコンポーネントが豊富な柔軟な設計システムを構築するために、これらのツールを必要としています。

スクロール リンクされたアニメーションも楽しい機能です。Steve Gardner のデモがとても気に入っています。スクロールが非常にスムーズで、スクロール時に飛行機のクールなアニメーションがトリガーされます。楽しい機能ですが、特にユーザー補助を考慮すると、正しく実装するのは難しい場合があります。そのため、現在、この機能のユーザー補助機能のユーザーテストを実施しています。

個人的に最も期待しているのは、組み込みのウェブ UI コントロールです。デベロッパーは同じタブセットを何度も作成しています。ブラウザが役に立つと思います。Open UI では、selectmenu、ポップアップ、ツールチップ、タブ、ナビ、アコーディオン、切り替えなどのコンポーネントに取り組んでいます。ウェブがデフォルトでアクセス可能になるよう、これらのブラウザ プリミティブにユーザー補助機能を組み込む方法を検討しています。デベロッパーは、タブの操作方法などの基本的な問題をブラウザに任せ、より複雑で微妙な問題に集中できます。これは別の投稿が必要になると思われるため、ここでは割愛します。

最後に、Google はブラウザ間の相互運用性に引き続き投資していきます。WebKit と Gecko の皆さんと協力して、デベロッパー エクスペリエンスの一貫性を実現できたことを嬉しく思います。開発者の皆様から、この機能が欲しいというご要望を多数いただいておりました。

まだ確認していない方は、シームレス ウェブ チームの Shared Element Transitions API がウェブの設計方法を変える可能性があります。デザイナーが物理空間でデザインを向きを変えられるような、微妙な遷移が、可能になるだけでなく、簡単にできるようになります。Jake Archibald の優れたデモがあります。

標準化がうまくいけば、今年は縦型リズムにも対応する予定です。LayoutNG をベースに構築できるため、さまざまな機能を利用できます。

お手数をおかけしますが、私たちと同じように、コミュニティ全体が、Web UI の改善と機能の追加が加速されることを心待ちにしていることでしょう。まだ学ぶべきことがたくさんあります。どこから始めればいいですか?

Una: I/O の ウェブ プラットフォームの最新情報セッションでは、今年リリースされる多くの機能のハイライトについて説明しています。Adam Argyle は、新しい CSS と今後予定されている CSS のすべてのランディング ページに関する優れた記事も執筆しています。今後は、まずは安定版のリリースに注力し、パイプラインで進行中の他の作業に注意を払うようにしてください。ウェブ プラットフォームの最新情報シリーズは、その点でも参考になります。web.dev のニュースレターに登録すると、このコンテンツがデベロッパーの受信トレイに届きます。これらの取り組みに参加し、貢献したいとお考えのデベロッパーは、Open UI に参加することをおすすめします。これは、この取り組みをサポートする最善の方法の一つです。

今後の主な更新内容

ウェブ エクスペリエンスの構築時に考慮すべき、今後の変更についてお知らせいたします。

Cookie の max-age を 400 日に制限する

  • 更新内容: 明示的な Expires/Max-Age 属性で Cookie が設定される場合、値は 400 日以内に制限されます。以前は制限がなく、何千年も先に期限切れになる Cookie もありました。この上限の目的は、一般的な使用パターンとユーザーのプライバシー保護のバランスを取ることです。400 日より頻繁にアクセスされるサイトでは、Cookie を更新してサービスの継続性を確保できます。ユーザーは、Cookie が何千年もブラウザに残り続ける心配をする必要はありません。
  • 推定タイムライン: Chrome 104 でリリース(2022 年 8 月 2 日 Stable)。
  • デベロッパー向けの行動を促すフレーズ: デベロッパーは、ユーザーがウェブサイトにアクセスしたときに、以前よりも頻繁に Cookie を事前に更新する必要があります。設定しない場合、Cookie が最初に設定されてから 400 日後にユーザーがログアウトされる可能性があります。

今回の Chrome Dev Insider をお読みいただきありがとうございました。前回の記事はこちらです。今後も、より多くの情報をお届けできるよう努めてまいります。

次回まで、今回の Chrome Dev Insider について、また改善点について、ご意見をお寄せください。

今回の Chrome Dev Insider について、どう思われましたか?フィードバックをお寄せください