歡迎閱讀 Chrome Dev Insider 第二版，我們將分享社群和 Chrome 的最新動態。這是最新一集的行家故事，帶您一探我們的工作方式，並快速一覽一些您應注意的重要更新。
我是 web.dev 和 developer.chrome.com 的內容主管 Rachel Andrew，他是 Chrome 開發人員關係團隊的成員。我在網路工作已有二十多年時間，不但專注於開放網路標準和 CSS，而且是 CSS Working Group 的一員，
我們在兩個月前舉辦了 Google I/O 大會，在此宣布幾項重要更新，包括 Google 如何協助開發人員提升網路速度和功能，同時確保使用者資訊安全和隱私。
這個團隊特別注意到了 (而且我們很高興社群遭到通知！) 這個團隊投入了大量心力，試圖支援更多的 CSS 和 UI 功能網頁版。在這期的 Chrome Dev Insider 中，我們將帶您一窺這個工作的幕後主場、我們如何支持 CSS 和 UI 開發人員，以及未來的發展。這就是我很期待舉辦《行家》刊物的原因。
話題地點
在首屆 Chrome Dev Insider 中，分享了關於 Compat 2021 和 Interop 2022 計劃的更新資訊，這些計劃中的瀏覽器廠商和生態系統播放器都攜手，為網路提供更多可支援所有瀏覽器的功能。這項計畫非常聚焦於 CSS，因為 CSS 開發人員將解決瀏覽器不相容的問題。
這可能不是大部分新訊，但見證我們在各個瀏覽器上取得的進展相當令人興奮。
上個月我們宣布推出 Safari 16.0 Beta 版串場廣告，其中包含容器查詢、subgrid 及 flexbox 檢查器等令人期待的功能。最近推出的 Firefox 和 Chrome 版本新增了許多令人期待的功能和修正程式，我們每個月都會在網路平台新功能系列文章中，介紹穩定版和 Beta 版瀏覽器的重要功能。
內部專家：支援 CSS 和 UI 開發人員
2022 年是 CSS 功能在今年掀起熱潮的一年，我們想藉此機會帶大家一窺幕後的點點滴滴。這次談到網頁版使用者介面和開發工具開發主管 Una Kravets，以及我們的網路使用者介面產品經理 Nicole Sullivan，討論 Chrome 支援使用者介面開發人員的旅程。
讓我們一起來看看這兩種做法。能否進一步介紹你自己？
Nicole：我是 Chrome 網頁版使用者介面的產品經理。我特別著重於新的 CSS 和 HTML API，以及負責建立 UI 的開發人員與設計人員。這個領域是一個令人振奮的空間，提供多種真正重要的 API，例如容器查詢、範圍和垂直節奏。
Una：負責帶領網頁版 UI 和開發人員工具開發人員工具中的 DevRel 團隊。我們主要是為網路平台的 UI 工程師提供支援，並確保他們具備邁向成功所需的工具。這包括 CSS API、HTML 元件，以及開發人員工具功能，可讓您查看現行的變更和意見回饋。
過去幾年，Chrome 為 UI 開發人員提供的支援成長速度相當快。你覺得為什麼要花這麼久的時間？最大的挑戰為何？
Una (違規)：我們需要經過一些工作，以便展示這項工作的重要性，以及為何應優先執行這項工作。我們一開始是在 2019 年發布的 MDN DNA 問卷調查，發現使用者介面是 YouTube 平台一大痛點。此後，我們就繼續透過資料，在 MDN 和內部開發人員滿意度問卷調查中持續運用相關資料。獲得上述成果的成果，我們得以進一步支持主管階層支持，並決定在 UI 空間中優先處理大多數要求最熱烈的開發人員功能，同時也是 Compat 2021 和 Interop 2022 等計畫的重點。
Nicole：除了獲得主管支持外，我們也必須找到向開發人員取得這些 API 的正確方式。首次加入 Chrome 時，我在名為分層 API (簡稱 LAPI) 的專案中會造成這種情況。LAPI 旨在為開發人員提供直接的元件體驗。我還是認為這次的拍攝成果非常棒，不過我們犯了很多錯誤！我們首先將重點放在浮動式訊息通知和虛擬清單。浮動式訊息幾乎是不可能的任務，而虛擬清單是最難以正確放置的元件之一。我們的立意良善，但對開發人員沒有幫助，因此我們停用了這項專案。要想辦法確實做到這個過程並不容易，但每一種錯誤都是為了振興不斷改進的 CSS 和 HTML。
接著來進一步討論 LAPI。這是怎麼一回事？
Nicole：就 LAPIs 而言，我們瞭解網站需要一個更接近建構原生使用者介面的置入式元件開發人員體驗。而我們顯然有了重新發明的輪廓，開發人員顯得很辛苦了。我不能算是我在職涯中建造的分頁數量了！儘管如此，我們試著透過傳送 JavaScript 的瀏覽器來解決這個問題，但這個做法非常困難。之前沒有人在瀏覽器中發布 JavaScript，也可能不清楚如何與支援瀏覽器算繪引擎的 C++ 程式碼互動。我們傾聽其他瀏覽器供應商 (謝謝 Mozilla！) 的回饋，也因此獨立開發了這個解決方案。因此，我們終於有了 Open UI，能找到更好的東西。透過 HTML 和 CSS，我們決定採用靈活的宣告式解決方案。由於這是宣告式，我們能夠以比 JavaScript 更簡單的方式導入無障礙功能。我很期待未來發展我們正努力支援真正重要的 UI 設計模式選取選單、彈出式視窗、工具提示、導覽、摺疊、分頁、輪轉介面和切換功能。
我們學到很多，我知道這個領域還有其他計畫，例如 CSS Houdini。故事內容為何？
Una：是的 CSS Houdini 是我們從社群得到的另一個地方。Houdini 功能有很多實用的功能，但太多功能太低，無法擴大採用範圍，也無法提供支援。我們發現，導入低階 API 不一定能減少開發人員的不便。相反地，他們將心力放在更高階的解決方案和需求上，幫助獲得各種跨瀏覽器支援，並找到在生態系統中推動創新所需的到達平台。我們正在追蹤進度：https://ishoudinireadyyet.com/。
談到跨瀏覽器方面的支援，跨平台 2022 和 Open UI 等計畫似乎為社群帶來重大的成果。想知道開發人員有什麼想法？
Una：開發人員最常遇到的問題之一是「設計在不同瀏覽器上都能以相同方式運作」。為瞭解決這個問題，我們與其他瀏覽器廠商合作，共同優先開發並推出一些最受歡迎的開發人員功能。我們從社群中收到的意見回饋也相當正面此外，透過名為 RenderingNG 的大型重新架構計畫，其中一些功能可能會更有效率。開發人員多年來一直期待這些歷久彌新的功能，如今已有許多大家期待我們開發並推出跨瀏覽器的功能，對於開發人員感到興奮不已。
Nicole：社區的興奮感，你可以透過 Twitter 查看。:)
事實證明，與生態系統合作是開發人員達成出色成果的關鍵。讓生活更加便利我知道貴團隊付出了許多心力，方便分享一些細節嗎？
Nicole：首先，我一直在許多開發人員在網路上建立專案，從最精細的程式庫到全套架構，開發人員都能打造令人驚豔的成果。是個很棒的創作者社群Chrome 執行許多步驟，讓它們更貼近這些專案。
舉例來說，我們在幾年前開始使用 React 和 Angular 等 JavaScript 架構，還有許多元架構，例如 Next、Nuxt 和 Gatsby。去年，我們開始在 Sass、Bootstrap 和 Material 等 UI 工具和架構中採取相同的做法。希望今年能與 GreenSock 合作，讓生活更加便利我剛剛看到 GreenSock 的 Cassie Evans 在 Smashing Conference 的演講，也非常期待與動畫界合作。
我們在哪裡發現了網頁版 UI 生態系統的最大機會？
Una：就大商機而言，我認為我們只是大略說明可自訂網路體驗的用途，容器查詢和 CSS 使用者偏好媒體功能等新的 API 會重新定義開發人員查看回應式設計的方式。我也非常期待這樣的協作設計體驗，可讓開發人員和設計人員與網站訪客互動。
Nicole，貴團隊的發展藍圖呢？
Nicole：並非所有探索都會變成可出貨的產品，但我目前非常期待看到許多東西：
但首先來龍去脈，我們會推出採用回應式的元件設計。此外，還提供顏色系統設計工具，讓設計人員能根據使用者偏好 (例如深色模式) 做出回應。舉例來說，OKLCH 色域可在不同色調間保持一致的亮度。設計師可以從選擇顏色到設計不同顏色之間的關係，且不會產生泥色的模樣！
我們也開發了幾個最常要求的 API，例如容器查詢、階層式圖層、父項選取器 (:has)、範圍樣式和巢狀。開發人員必須取得這些資訊，才能打造內含可重複使用元件的彈性設計系統。
捲動連結動畫是另一個有趣區域。我很喜歡 Steve Gardner 的示範。此外，他還擁有流暢流暢的捲動體驗，並在捲動時觸發酷炫的飛機動畫。雖然這些過程很有趣，但要正確完成所有步驟可能並不容易，在考量到無障礙設計的情況下更是難上加難。因此我們要針對這項功能進行使用者測試。
我最滿意的部分是內建的網頁 UI 控制項。開發人員不斷重複建立相同的分頁組，我認為瀏覽器可以提供協助。在「開啟的 UI」上，我們正在開發元件，例如選取選單、彈出式視窗、工具提示、分頁、導覽、摺疊，以及切換鈕。我們正在研究如何讓這些瀏覽器基元中融入無障礙功能，進而讓網路日後可以預設使用。開發人員可以專心處理更複雜且複雜的問題，而瀏覽器也能支援分頁分頁等基本功能。這可能需要自己的貼文，所以我暫時先停下來！
最後，我們將繼續努力開發瀏覽器之間的互通性。我們很擅長與 WebKit 和 Gecko 團隊合作，將開發人員體驗保持一致。我們聽說開發人員都很願意這樣做！
對了，如果您尚未一探究竟，Seless Web 團隊的 Shared Element Transitions API 將改變使用者設計網路的方式。為了讓設計人員能在實體空間中調整設計方向，但這些細微的轉場效果其實不容易，但也非常簡單。Jake Archibald 就提供了精彩的示範。
如果標準不錯，我們可能還會注意今年的垂直節奏！這一點以 LayoutNG 為基礎，解鎖許多功能。
雙管齊下，我相信像我們一樣，所有和我們一樣的社群都很期待，網頁 UI 世界將迅速推出改良與功能。還有很多東西可以確定，這時該從哪裡著手呢？
Una：我們在 I/O 大會的「網路平台新功能」講座中介紹了今年登陸的所有功能，並介紹這些功能。Adam Argyle 也撰寫了一篇精彩文章，介紹所有全新和即將推出的 CSS 到達網頁。目前我只會著重使用穩定版，目前其他工作會下線，請特別留意。你的優質「網路平台新手」系列影片就是幫助你深入瞭解這系列作品的好方法。訂閱 web.dev 電子報後，開發人員也會看到這些內容。而對於有意親身相助的開發人員，瞭解上述所有事項並協助開發人員進行相關作業，加入開放式 UI 是支援這項工作的最佳方法之一。
重要近期更新
我們的目標是持續追蹤我們的傳統，在為您提供網路體驗時，應該特別留意即將實施的異動。
將 Cookie 上限設為 400 天
- 更新：現在如果使用明確
Expires/Max-Age屬性設定 Cookie，未來將限制為最多 400 天。以往沒有限制，Cookie 在未來可能會失效。這項限制旨在在常見使用模式和尊重使用者隱私之間取得平衡。任何超過 400 天造訪率的網站都可以重新整理 Cookie，以確保持續提供服務；使用者無須擔心 Cookie 會留在瀏覽器上，不會因為千禧世代使用而停滯。 - 預計時程：在 Chrome 104 版中預計提供這項功能 (2022 年 8 月 2 日穩定版)。
- 開發人員行動號召：開發人員可能需在使用者造訪網站時更頻繁地更新 Cookie。否則，使用者可能會在 Cookie 首次設定後 400 天登出。
希望您喜歡這個版本的 Chrome Dev Insider。你可能會錯過第一則。期待在下一季中為您帶來更多獎勵。
在那之前，歡迎針對這個版本的 Chrome Dev Insider 提供意見，告訴我們你的想法，協助我們改善服務品質。
你對這個版本的 Chrome Dev Insider 有什麼看法？歡迎提供意見。