Chrome 提案 rangegroup 元素，多滑塊 range 原生免手刻
Chrome Platform Status · 2026-09-17
多滑塊的 range 滑桿（例如價格區間篩選器）一直得靠開發者自己刻：兩個獨立的 <input type="range"> 疊在一起、自製共用軌道的 div、手動處理鍵盤 focus 順序與 ARIA 語意。新提案的 <rangegroup> 元素打算把這整套邏輯搬進原生 HTML，讓真正的 <input type="range"> 子元素在同一條軌道上協同運作，同時保留各自的 label、value、鍵盤行為與表單參與。
這項提案由 Microsoft 工程師 Anssi Ollanketo（ansollan@microsoft.com）等四人具名列為 owner，2026 年 9 月 17 日建立於 Chrome Platform Status（feature 5199707839266816），Chrome 端狀態標示為「Proposed」，尚未進入 Origin Trial；Firefox 與 Safari 目前都是「No signal」。
背景
原生 <input type="range"> 只支援單一滑塊。想做雙滑塊或多滑塊介面，團隊得各自重造一套鍵盤與表單邏輯，還要模擬原生 slider 的填色與 focus 樣式。Chrome Platform Status 的動機說明直接點出這個缺口：HTML 沒有宣告式的方法可以把多個 range 輸入組成單一共用軌道的控制項，開發者只能用自製 JavaScript、pointer 事件處理、鍵盤互動與無障礙語意來湊出一個多滑塊控制項。
這個缺口也不是新問題。Open UI 的 explainer 提案最早在 2025 年 3 月由 brechtDR 送出、gregwhitworth 審閱，當時的討論就已經聚焦在「究竟該用純 CSS 偽元素模擬多滑塊，還是乾脆做一個新元素」；gregwhitworth 認為某些互動需求（例如區段拖曳）光靠偽元素做不到，這也是 <rangegroup> 最後選擇成為獨立元素、而非單純擴充 ::slider-* 偽元素集合的原因。
規格細節
<rangegroup> 的模型接近 <fieldset>：外層元素本身不會被表單送出，只有內部每個 <input type="range"> 的 name/value 會出現在表單資料裡。Open UI explainer 給出的最小結構如下：
<rangegroup name="price-range" min="0" max="1000">
<legend>Price Range</legend>
<label>Minimum Price
<input type="range" name="price-min" value="250">
</label>
<label>Maximum Price
<input type="range" name="price-max" value="750">
</label>
</rangegroup>
群組層級新增的屬性包括：
min/max：整條共用軌道的邊界，取代逐一設定每個子 input 的邊界。list：連到<datalist>，在軌道上畫出刻度。stepbetween：限制相鄰兩個滑塊之間的最小距離，避免兩個滑塊互相穿越。interaction：決定點擊軌道空白處時的行為（移動端點或整段平移），explainer 註明命名還沒定案。disabled：停用整組滑塊，語意比照<fieldset disabled>；也可以只disabled單一子 input 鎖住個別滑塊。
鍵盤行為也是原生化的重點：Tab / Shift+Tab 在滑塊之間移動 focus，方向鍵、Page Up/Down、Home/End 調整目前滑塊的值；當群組帶有 list 指到的 <datalist> 時，方向鍵會直接跳到相鄰的刻度值，這是 explainer 提出的新行為，目前還在 Open UI 討論串（issue #1460）裡。樣式端則規劃了 ::slider-track、::slider-segment(n)、::slider-thumb 等偽元素，取代目前各瀏覽器不一致的 vendor-prefix 寫法。
影響範圍
直接受影響的是手刻雙滑塊/多滑塊元件的團隊：電商價格篩選器、日期區間選擇器、圖表刷選控制項，這些目前多半是自製 div + pointer event 拼出來的，未來有機會換成原生 <rangegroup> 並拿掉整套鍵盤與 ARIA 補丁程式碼。設計系統（design system）團隊的滑桿元件庫也該留意這個提案，避免現在花力氣重寫的多 thumb slider 邏輯很快就被原生行為取代。
但目前還不到動手遷移的時機：Chrome 狀態只是「Proposed」，沒有 flag、沒有 Origin Trial，Firefox 與 Safari 都尚未表態，explainer 本身也還列著多個未解問題，包括 interaction 屬性命名、滑塊碰撞處理、垂直方向支援與非線性刻度（例如對數座標）該怎麼對應。想追進度的工程師可以關注 Chromium bug 562900379 的實作狀態，以及 Open UI 上與 CSS Forms Level 1 草案的整合討論——PR 討論裡 gregwhitworth 已指出兩邊工作有明顯重疊，值得一併追蹤而不是只看 Chrome 這一側的提案頁。
值得留意的是，這次的四位 owner 全部掛 Microsoft 信箱，proposal 本身也是由 Edge 團隊主導送進 Chromium 的 feature 追蹤系統，屬於瀏覽器廠商之間先在 Open UI 社群搓出共識、再各自推進實作的典型路徑。這也代表規格細節仍可能隨著多方意見調整，現在能做的準備是先盤點自家程式庫裡有哪些手刻的多滑塊 slider，記下它們目前處理鍵盤與表單送出的方式，等 <rangegroup> 進入 Origin Trial 階段時能快速比對差異。
原始來源：Chrome Platform Status: <rangegroup> element、Open UI Enhanced Range Input explainer、Open UI PR #1173