Open UI 倡議在瀏覽器原生元件方面取得進展

長期以來，Web 開發社群一直在努力應對原生 HTML 表單控制元件的侷限性，經常求助於 JavaScript 重型框架來建立現代使用者介面。Open UI 倡議作為 W3C 社群組織，旨在透過標準化常見的 UI 模式，使開發者能夠對內建 Web 元件進行樣式設計和擴充套件。

已在瀏覽器中落地的成熟提案

Open UI 倡議中的幾個元件已經進入現代瀏覽器。Popover API、獨佔手風琴（使用帶有 name 屬性的 details 元素）以及呼叫者命令（使用 commandfor 屬性）現已在 Chrome 和其他瀏覽器中得到不同程度的支援。可自定義的 select 元素也已在 Chrome 中落地，解決了 Web 上最常被重新實現的元件之一的問題。

這些實現代表瞭解決 Web 開發中一個永續性問題的重大進展。正如一位社群成員所指出的：

「列出的大多數常用元件應該在某個時候成為標準。主要問題仍然是 Web 最初是為文件而設計的，而非應用程式。當前的混亂部分是由於作業系統供應商未能就標準的跨平臺 GUI API 達成一致，所以這些功能是透過 Web 實現的。」

已畢業的 Open UI 提案

• 互斥手風琴

  • 實現方式：HTML <details> 元素搭配 name 屬性
  • 瀏覽器支援：https://caniuse.com/mdn-html_elements_details_name

• 呼叫者命令

  • 實現方式：按鈕上的 commandfor 屬性
  • 瀏覽器支援：https://caniuse.com/mdn-html_elements_button_commandfor

• 彈出層 API

  • 實現方式：HTML 元素上的 popover 屬性
  • 瀏覽器支援：https://caniuse.com/mdn-api_htmlelement_popover

• 彈出提示

  • 實現方式：popover="hint" 屬性值
  • 瀏覽器支援：https://caniuse.com/mdn-api_htmlelement_popover_hint

• 可定製選擇框

  • 狀態：僅在 Chrome 中實現
  • 參考：https://open-ui.org/components/customizableselect/

解決框架依賴問題

許多開發者目前轉向 React、Angular 或其他 JavaScript 框架，主要是因為他們需要 HTML 本身不提供的 UI 元件。多選器、可搜尋的下拉選單、具有高階功能的日曆選擇器以及其他常見模式迫使開發者要麼構建自定義解決方案，要麼匯入重型庫。

這種對框架的依賴已經形成了一個迴圈，新開發者學習特定框架的方法而非 Web 標準。結果往往是臃腫、可訪問性較差的網站，消耗更多電力並引入潛在的安全漏洞。透過在瀏覽器級別標準化這些常見模式，Open UI 旨在減少這種依賴，同時提高效能和可訪問性。

平衡標準化與定製化

Open UI 倡議面臨的一個關鍵挑戰是平衡標準化與視覺定製需求。許多企業要求 UI 元件反映其品牌形象，這在歷史上推動他們遠離原生元素，轉向自定義實現。

該倡議特別透過專注於使原生元素更具樣式可定製性來解決這一問題。Open UI 的目標不是強制開發者在可訪問性和品牌之間做出選擇，而是提供可視覺定製的元件，同時保持原生實現的可訪問性和效能優勢。

一些社群成員對企業是否會採用標準化元件表示懷疑，指出差異化是核心業務戰略。然而，其他人則認為，透過 UI 元件實現差異化幾乎沒有價值，使用者實際上更喜歡熟悉的介面。

未來方向和社群反應

雖然 Open UI 倡議已取得進展，但一些社群成員批評了該專案本身的文件和展示方式。該網站缺乏清晰的示例和互動式演示，這些本可以幫助開發者理解所提議的元件。

該倡議專注於研究驅動的開發——在提出標準之前記錄流行框架中的模式——表明了一種可能需要時間才能完全實現的方法論方法。然而，已畢業的提案表明這項工作已經結出了果實。

隨著瀏覽器繼續實施這些標準，我們可能會看到迴歸更輕量級、更易訪問的網站，這些網站不需要龐大的 JavaScript 框架來實現基本的 UI 功能。這可能特別有利於低功率裝置或較慢連線的使用者，因為重型 JavaScript 可能會顯著影響效能。

參考：Open UI 章程