Chrome 開發人員行家:CSS 和 UI 版本

瑞秋.安德魯 (Rachel Andrew)
Rachel Andrew

歡迎使用 Chrome Dev Insider 第二版,我們將分享社群和 Chrome 令人興奮的最新動態。本集新節目將介紹 Google 處理工作的方式,並簡要介紹幾則值得留意的重大最新消息。

我是 Chrome 開發人員關係團隊的 web.devdeveloper.chrome.com 內容主管 Rachel Andrew。我在網路上工作超過 20 年,主要著重於開放網路標準和 CSS,也是 CSS 工作小組的成員。

兩個月前,我們已在 Google I/O 大會上公開進展,其中介紹了一些最重要的更新,說明我們如何協助開發人員提升網路速度與效能,同時確保使用者資訊安全和隱私。

我們很高興的其中一個問題,也很高興社群曾注意到!團隊已投入大量心力支援網路上的更多 CSS 和 UI 功能。在本期的 Chrome Dev Insider 中,我們會介紹幕後的幕後作業人員,並說明 Google 如何支援 CSS 和 UI 開發人員,以及未來的發展方向。因此我非常高興能舉辦這本《行家》系列課程。

話題地點

在首屆 Chrome Dev Insider 活動中,我們分享了關於 Compat 2021Interop 2022 計畫的最新動態,瀏覽器供應商和生態系統的玩家一直在攜手為網路推出更多可支援所有瀏覽器的功能。這項計畫十分重視 CSS,因為 瀏覽器不相容是 CSS 開發人員面臨的最大挑戰之一

雖然這對大部分人來說還不夠,但還是令人興奮能查看他們的進步幅度。

Chrome 開發人員版 71,Firefox 74 夜間版本,Safari TP (73)。
2022 年 3 月實驗性瀏覽器得分。
Chrome 開發人員版 77,Firefox 版本 80 晚上 80,Safari TP (80)。
2022 年 7 月來自實驗瀏覽器的分數。查看最新分數

我們在上個月稍早發現 Safari 16.0 Beta 版宣布推出串場廣告,其中包含容器查詢子網格Flexbox 檢查器等令人期待的功能。我們在近期發布的 Firefox 和 Chrome 版本包含許多令人期待的功能和修正程式。我們每個月都會在網路平台新功能系列文章中,介紹穩定版和 Beta 版瀏覽器的重要功能。

行家窺探:支援 CSS 和 UI 開發人員

隨著 2022 年 CSS 功能問世,我們想帶你一探究竟。我訪問了 Una Kravets、Web UI 和開發人員工具的 DevRel 主管,以及專精網路使用者介面產品經理 Nicole Sullivan,談談 Chrome 為使用者介面開發人員提供支援的旅程。

我們先從兩個開始著手。可以請您進一步說明嗎?

Nicole:我是 Chrome 網頁版 UI 的產品經理,我特別著重於新的 CSS 和 HTML API,以及建構使用者介面的開發人員和設計人員。相當令人興奮,還有容器查詢範圍垂直節奏等真正重要的 API。

Una:我負責領導網頁 UI 和開發人員工具開發團隊。我們主要負責支援網路平台上的 UI 工程師,並確保他們具備成功所需的工具。其中包含 CSS API 和 HTML 元件,以及開發人員工具功能,可供查看進行中的變更和意見回饋。

過去幾年來,Chrome 對使用者介面開發人員提供的支援速度相當快,你覺得為什麼到達此處這麼長?最大的挑戰是什麼?

Una:我們需要投入一些作業,才能示範這項工作有多重要,以及應優先處理的理由。我們從 2019 年開始實施的 MDN DNA 問卷調查,指出使用者介面是平台上問題最嚴重的例子。此後,我們持續根據 MDN 和內部開發人員滿意度問卷調查,持續使用相關資料。這一切的成果讓我們能更深入的主管階層的支持,並優先處理 UI 空間中最需要的開發人員功能,這些作業也是 Compat 2021Interop 2022 等計畫的主軸。

Nicole:除了獲得主管的認可外,我們還應找出將 API 提供給開發人員的正確方式。我初次加入 Chrome 時,我在名為「Layered API」 (簡稱為 LAPI) 的專案中誤解了這一點。LAPI 的用意是讓開發人員直接享有元件體驗。我仍然認為這是拍片不錯的成果,但也犯了許多錯誤。我們先著重於浮動式訊息通知虛擬清單。浮動式訊息幾乎是不可能的任務,而虛擬清單是最困難的構成要素之一。我們達成的意圖相當良好,但並非幫助開發人員,因此我們已終止這項專案。很難學習,但每個錯誤都是為了推動 CSS 和 HTML 的進步。

接著來談談 LAPI。這是怎麼一回事?

Nicole:對於 LAPI,我們知道網路需要更接近建構原生使用者介面的內建元件開發人員體驗。事實證明,重新定義工作模式有阻礙開發人員的發展。我無法計算在職涯中建立的分頁數量!不過,我們試著透過瀏覽器提供 JavaScript 來解決這個問題。之前沒有人在瀏覽器中置入 JavaScript,也不清楚瀏覽器如何與支援瀏覽器轉譯引擎的 C++ 程式碼互動。我們聽取了其他瀏覽器廠商 (感謝 Mozilla!) 的成果,並透過這種方式提供後盾,讓我們透過開放式使用者介面找到更好的做法。我們仰賴 HTML 和 CSS 來建立靈活的宣告式解決方案。由於這是宣告式,我們採用不像 JavaScript 那麼簡單的方式,內建無障礙功能。我真的很期待看到這項技術的發展。我們正在努力支援選取選單、彈出式視窗、工具提示、導覽、摺疊、分頁、輪轉介面,以及切換這些是真正重要的 UI 設計模式。

我們從中學到了許多,我知道這個領域還有其他計畫,例如 CSS Houdini。該怎麼說故事?

Una:我們從社群中學到的 CSS Houdini 也是不錯的選擇。應用程式有許多實用的 Houdini 功能,但許多功能都過低,所以無法擴大採用範圍和支援。我們瞭解導入低階 API 並不一定能減少開發人員的不便。然而,我們轉而專注於更高階的解決方案和需求,進而提供跨瀏覽器的支援,以及推動生態系統發展所需的一切基礎。我們目前正在追蹤進度:https://ishoudinireadyyet.com/。

說到跨瀏覽器支援,「 Interop 2022」和「Open UI」等計畫似乎能為社群帶來顯著的正面成果。各位開發人員有什麼想法?

Una:我們聽到開發人員最常聽到的其中一個問題就是「為不同瀏覽器設計相同的設計。」為了因應這個情況,我們已與其他瀏覽器供應商合作,決定優先開發及提供熱門開發人員功能。而社群成員收到的意見回饋都讓我們非常正面。此外,我們藉由 RenderingNG 重新架構大規模的重新架構,大幅提高其中部分功能的運作效能。這些令人期待的長久功能一直在跨瀏覽器上努力,終於迎合開發人員期待。

Nicole:社群的興奮感是可以接受的。你可以前往 Twitter 查看。:)

上一段提及的推文。

事實證明,與這個生態系統合作是幫助開發人員輕鬆運作的成功關鍵。我知道您的團隊在這方面投入大量心力。願意分享一些詳細資訊嗎?

Nicole:首先,我一直關注開發人員在網路上建構的專案。從最小的程式庫到全面掌握架構,開發人員不斷在建構精彩作品。也是很棒的開發者社群此外,Chrome 也採取了許多步驟,進一步強化與這些專案間的連結關係。

舉例來說,幾年前我們開始使用如 React 和 Angular 等 JavaScript 架構。以及元架構,例如 Next、Nuxt 和 Gatsby。去年,我們開始以相同的 UI 工具和架構,例如 Sass、Bootstrap 和 Material。希望今年我們能與 GreenSock 和其他工具合作,讓開發人員的生活更加便利。我剛剛看到 GreenSock 的 Cassie Evans 在 Smashing conf 大會上演講,發現和動畫界的夥伴合作後,我真的很開心。

那麼,我們觀察到網路 UI 生態系統的最大商機是什麼?

Una (Una):就龐大的商機而言,我只是想探索一下可自訂網路體驗的潛力。容器查詢和 CSS 使用者偏好媒體功能等新的 API 都會重新定義開發人員檢視回應式設計的方式。令人期待的協同設計體驗讓開發人員和設計人員能夠與造訪網站的使用者共同協作。

Nicole:雖然並非所有探索行為都會變成可運送的事物,但現在有很多我非常期待的事:

我們首先要介紹的是以元件為核心的回應式設計。其中包含設計色彩系統的工具,方便設計人員回應深色模式等使用者偏好。舉例來說,OKLCH 色域可讓不同色調的亮度保持一致。設計師可以從選擇顏色,到設計不同顏色間的關係,而不會產生混亂的調色盤!

另外,我們也會開發最常要求的 API,例如容器查詢分層層、父項選取器 (:has)、範圍樣式巢狀結構。因為開發人員必須利用這些屬性,建構充滿可重複使用的元件的靈活設計系統。

捲動連結的動畫是另一個有趣的區域。我非常喜歡 Steve Gardner 的示範。他擁有流暢的捲動體驗,且捲動時觸發酷炫的飛機動畫。雖然這些很有趣,但要找到正確答案有時並不容易,尤其在考量無障礙時更是如此。因此,我們正在針對這項功能進行使用者測試。

我最期待的是內建的網頁 UI 控制項,開發人員不斷反覆地建立相同的分頁,我認為瀏覽器可以提供協助。在「開啟使用者介面」部分,我們正在開發選取選單、彈出式視窗、工具提示、分頁、導覽、摺疊和切換等元件。我們正在研究如何將無障礙程度納入瀏覽器基本功能中,讓使用者即使長時間存取網路,仍能輕鬆存取網路。這樣一來,開發人員就能專心處理更複雜且細微的問題,瀏覽器則可支援基本功能分頁 (例如分頁功能的運作方式)。這可能需要獨立的文章,所以我會先停止分享!

最後,我們將繼續投資瀏覽器之間的互通性。我們很榮幸與 WebKit 和 Gecko 的人士合作,致力維持一致的開發人員體驗。我們清楚知道開發人員會希望這項工具能滿足他們的需求!

如果你還沒看過,Shemless Web 團隊的 Shared Element Transitions API 將會改變使用者對網路設計的方式。這些細微的轉場效果能讓設計人員在實體空間中調整設計內容,而這不只是可能,而且操作起來相當簡單。Jake Archibald 有絕佳示範內容

如果我們今年的標準表現良好,甚至要看看今年的直向節奏,就更棒了!我們可以以 LayoutNG 為基礎打造應用程式,進而解鎖許多功能。

感謝彼此的配合。我相信像我們這樣的整個社群,都很期待看到網路使用者介面世界將這次的改良和功能不斷更新。目前仍有許多困難,你該如何從哪裡著手?

Una:我們在 I/O 大會上發表的「網路平台最新消息」講座介紹了今年推出的許多實用功能。Adam Argyle 也針對所有即將推出和即將推出的 CSS 平台撰寫了一篇精彩文章。目前我會將重點放在穩定版,注意管道的其他後續工作。令人驚豔的「新手網路平台」系列影片,也很適合用來追蹤這些主題。訂閱 web.dev 電子報也會將這項內容傳送到開發人員的收件匣。如果開發人員想要參與並取得協助,最好的方法就是加入開放式 UI

即將推出的重要更新

我們將延續傳統,讓您提前瞭解即將到來的改變,在打造網路體驗時請務必牢記這一點。

將 Cookie 效期上限設為 400 天

  • 更新:如果以明確的 Expires/Max-Age 屬性設定 Cookie,系統現在會將該值限制為在未來 400 天內。先前沒有限制,Cookie 可能會於日後有多個千禧世代到期。這項限制的目標是在常見使用模式之間取得平衡,同時尊重使用者隱私。使用者每 400 天多次瀏覽網站,只要重新整理 Cookie,即可確保服務不中斷,使用者也可以放心,Cookie 也不會因此拖慢千禧世代的 Cookie 瀏覽瀏覽器。
  • 預計時程:Chrome 104 中的運送資訊 (穩定版為 2022 年 8 月 2 日)。
  • 開發人員行動號召:開發人員可能需要比以前更頻繁地主動重新整理 Cookie。否則,系統可能會在 Cookie 首次設定後 400 天,將使用者登出。

希望您喜歡閱讀這份的 Chrome Dev Insider 文章。錯過了第一項。我們期盼在下一季為您提供更多協助。

在此之前,請和我們分享你對這個版本的 Chrome Dev Insider 的意見,以及我們該如何改進。

您對這個版本的 Chrome Dev Insider 有什麼看法?歡迎提供寶貴意見