雙模式 UI 的 breakpoint 是「物理空間預算的結果」、不是「設計選擇」。 把每個元件的固有尺寸與 gap 加總、得到「兩種模式各自能存活的最小 viewport」 — breakpoint 從這個數字往上取一個安全餘裕。憑感覺取（768、1024）會在中間過渡區看到元件擠壓、消失或溢出。

本篇焦點：breakpoint 數字怎麼推算。

• stateful UI 怎麼跨兩個 slot 共用同一份節點由 #54 跨 slot 同節點搬遷 pattern 處理（兩議題機制不同：本篇是數字計算、#54 是 state 一致性）

breakpoint 從元件預算推算

商業邏輯

Responsive UI 的本質是「同一份內容、在不同寬度有不同的呈現方式」。每種模式（mobile / tablet / desktop）對應一個 layout、每個 layout 有自己的最小可生存寬度 — 這是元件尺寸與 gap 的加總、不是任意選擇。

當 breakpoint 取得比實際所需大、模式切換點與「真正放得下」的點不一致、使用者在過渡區看到擠壓、溢出、或元件神秘消失。

預算推算的步驟

這次任務的實際預算

觀察

搜尋頁的 desktop layout 包含：

• main 內容欄寬度 = 70ch ≈ 720px（theme 預設）
• filter sidebar 寬度 = 400px（自訂）
• main 與 filter 之間 gap = 32px
• body 左右 padding 各 64px = 128px

判讀

把 filter 放在 main 左外側、main 維持置中時、所需最小 viewport：

1最小 viewport ≈ main + 2 × (filter + gap) + body padding
2             = 720 + 2 × (400 + 32) + 128
3             = 1712px

但這是「左右對稱都放下」的條件。若允許 filter 溢出 body padding（仍在 viewport 內可見）、條件放寬為：

1最小 viewport ≈ main + filter + gap + body padding
2             = 720 + 400 + 32 + 128
3             = 1280px

選 1280 為下限、加餘裕後取 1400px。

執行

1@media (min-width: 1400px) {
2  .search-filter-slot { display: block; /* 桌面寬模式 */ }
3}

下方寬度時 filter 顯示在 pagefind 原生位置（drawer 內、結果上方）、由 pagefind 自己處理。

設計取捨：餘裕的取法

預算算出最小 viewport 後、breakpoint 加多少餘裕？四種做法：

A：加 ~10% 餘裕（這個專案的預設）

• 機制：1280 + 120 ≈ 1400
• 選 A 的理由：避免邊界情況閃爍（使用者視窗剛好在 1280 像素時、輕微 resize 會反覆觸發切換）
• 適合：一般情境
• 代價：1280-1400 區間其實能放下、但 CSS 仍走 mobile 模式

B：取整到常見裝置寬度

• 機制：1280 → 1366（MacBook Pro 寬度）或 1440（外接螢幕常見）
• 跟 A 的取捨：B 對齊裝置生態、A 對齊計算結果；B 對「設計給特定裝置的網站」較合理
• B 比 A 好的情境：使用者群明確（公司內部工具、特定裝置網站）

C：完全等於最小值（無餘裕）

• 機制：breakpoint = 1280
• 跟 A 的取捨：C 把所有可放下的視窗都納入 desktop 模式、A 留空間給邊界閃爍
• C 才合理的情境：實作上有 debounce 處理閃爍、且裝置寬度集中在某個值附近

D：用 container query 取代 viewport breakpoint

• 機制：CSS Container Queries — 元件根據父容器寬度切換、跟 viewport 解耦
• 跟 A 的取捨：D 更精準（容器寬度才是元件真正可用的空間）、A 簡單（viewport 是全局觀念）
• D 比 A 好的情境：元件可能放在不同寬度的容器內（CMS 系統、可嵌入元件）

不該套用「物理空間預算」的情境

預算法有適用邊界：

核心判準：兩種模式之間有「明確的視覺結構切換」嗎？是 → 用預算法；否 → 用流體 layout 或動態量測。

跟其他原則的關係

判讀徵兆

順序：看到擠壓或消失先量空間、不要立刻調 breakpoint 數字。數字背後有計算才不會反覆試錯。

 1var mql = window.matchMedia('(min-width: 1400px)');
 2function place() {
 3  if (mql.matches) {
 4    desktopSlot.appendChild(filter);
 5  } else {
 6    drawer.insertBefore(filter, drawer.firstChild);
 7  }
 8}
 9mql.addEventListener('change', place);
10place();  // 初始化

同一個 DOM 節點在兩個 slot 之間搬移、不複製成兩份。

這個做法存在的價值

Stateful UI（內含 checkbox 勾選、表單值、scroll 位置等 state）跨兩個顯示位置切換時、複製兩份會造成 state 分歧 — 使用者在 desktop 勾的 filter、切到 mobile 看不到勾選狀態。

搬同一份節點 = state 永遠跟著節點走 = 切換無感。

適合的情境

核心特徵：UI 內含 state、兩個位置展示的是「同一個邏輯單位」、不是「兩個獨立元件」。

不適合的情境

設計細節

appendChild 是搬遷、不是複製

1parentA.appendChild(node);  // node 從原位置消失、出現在 parentA

DOM API 的 appendChild / insertBefore 是 move、不是 copy — 同一個節點不能同時存在於多個位置。這個特性正是搬遷 pattern 的基礎。

初始放在哪

1<!-- 預設位置（mobile / fallback）-->
2<div class="pagefind-ui">
3  <div class="drawer">
4    <div class="filter-panel">...</div>  <!-- 初始在這 -->
5  </div>
6</div>
7
8<!-- 桌面 slot（空、等待搬入）-->
9<aside class="desktop-filter-slot"></aside>

預設放在 fallback 位置 — 當 JS 失敗時仍可見。

跨 slot 切換的時機

matchMedia event 是 viewport 跨過 breakpoint 的瞬間：

1var mql = window.matchMedia('(min-width: 1400px)');
2mql.addEventListener('change', place);
3place();  // 初始也跑一次

不要用 resize event — 太頻繁、會在 breakpoint 邊界震盪。matchMedia 只在 cross 的瞬間觸發。

搬遷時 framework 的 reactivity

如果搬遷的節點是 framework 管的（如 Pagefind 的 svelte 元件）— 整節點搬通常安全、framework 在下次 patch 時看到節點還在、繼續更新內部。

詳細安全規則由 #13 JS 操作 framework 元件：邊界辨識與安全規則 處理。

Focus 跟著搬

搬遷可能讓鍵盤 focus 暫時失去（視瀏覽器）— 加 save/restore：

1function place() {
2  var activeBefore = document.activeElement;
3  if (mql.matches) desktopSlot.appendChild(filter);
4  else drawer.insertBefore(filter, drawer.firstChild);
5  if (activeBefore && filter.contains(activeBefore)) {
6    activeBefore.focus();
7  }
8}

詳細處理由 #37 動態 DOM 移動時的 focus 管理 處理。

設計取捨：兩個 slot 的 stateful UI 共用

四種做法、各自機會成本不同。預設選 A（搬同節點）、其他做法在特定情境合理。

A：搬同一節點（這個專案的預設）

• 機制：matchMedia + appendChild 在兩 slot 間搬同一份節點
• 選 A 的理由：state 跟著節點、切換無感、不需要 sync 邏輯
• 適合：stateful UI、需要在兩個位置展示同樣內容
• 代價：搬遷 callback 在 viewport 跨 breakpoint 時觸發、需要處理 focus / 動畫
• 詳細：本卡片

B：CSS-only 雙顯示 + display 切換

• 機制：兩個位置都放同一份節點 (寫兩遍 HTML)、用 @media + display: none 切換顯示
• 跟 A 的取捨：B 純 CSS 簡單、A 需要 JS；但 B 對 stateful UI 失敗（兩份 state 各自獨立）
• B 比 A 好的情境：UI 純 stateless（純圖示）、純 CSS 解就夠

C：CSS-only + JS 同步 state

• 機制：兩份節點 + JS 監聽 state 變動同步
• 跟 A 的取捨：C 比 B 解 state 問題、但同步邏輯複雜（雙向更新、避免循環）
• C 比 A 好的情境：兩個位置的 UI 視覺需要差異（不只是位置不同）

D：JS 完全重建 UI

• 機制：viewport 變動時拆掉舊 UI、在新位置重建一份
• 成本特別高的原因：state 在重建時遺失、UI 閃爍、輸入中斷
• D 才合理的情境：UI 是 stateless 的、且重建成本低

跟其他 pattern 的關係

#14 Selector 精準度 的「起點」維度有四種做法、本卡片是「跨 slot 搬遷」這個專門情境的補充：

應用範例：跨 viewport filter 切換

 1function setupResponsiveFilter(shell, breakpoint) {
 2  var filter = shell.querySelector('.pagefind-ui__filter-panel');
 3  var drawer = shell.querySelector('.pagefind-ui__drawer');
 4  var desktopSlot = document.querySelector('.search-filter-slot');
 5
 6  if (!filter || !drawer || !desktopSlot) return;
 7
 8  var mql = window.matchMedia('(min-width: ' + breakpoint + 'px)');
 9
10  function place() {
11    var activeBefore = document.activeElement;
12
13    if (mql.matches) {
14      desktopSlot.appendChild(filter);
15    } else {
16      drawer.insertBefore(filter, drawer.firstChild);
17    }
18
19    if (activeBefore && filter.contains(activeBefore)) {
20      activeBefore.focus();
21    }
22  }
23
24  place();
25  mql.addEventListener('change', place);
26}

完整 pattern：取元件根 + matchMedia + 搬遷 + focus 處理。

判讀徵兆

核心原則：Stateful UI 的兩個展示位置共用同一份節點、state 自然跟著走 — 比「兩份節點 + sync 邏輯」乾淨。複製兩份是「state 來源從一變二」的隱形多源（違反 #44 SSoT）。