CSS 倒圓角 Tab Bar 實作：用量測與 transform 移動凹槽

倒圓角凹槽的畫法不只兩種#

網路上的作法大致可以整理成以下幾類。這張表比較的是「如何產生凹槽形狀」，還沒有處理選中項目的位置。

除了原本兩個範例，我另外找到 Temani Afif 的 Inverted border-radius using CSS mask。它用 radial-gradient()、conic-gradient() 與 CSS 變數控制內凹半徑，證明不用 SVG 也能做出真正透明的倒圓角。mask-image 與 mask-composite 已有跨主要瀏覽器的 Baseline 支援，但複合順序和漸層停駐點仍需要實機測試。

較新的 shape() 則補上 path() 不容易響應式縮放的問題。MDN 的比較指出，path() 的座標固定為像素，而且 path 字串不能使用 var()；shape() 可以使用百分比與 CSS 變數。不過這篇原型優先保留支援成熟、設計調整直接的 SVG path。

corner-shape: scoop 也確實能產生原生凹角，但它控制的是盒子四角；這次要移動的是 Tab Bar 上緣中央的一整段曲線，所以仍需要獨立形狀層。更自由的 border-shape 目前仍屬實驗功能，適合列入後續觀察，不適合取代正式版本。

無論最後用 mask、SVG 或新的 CSS shape，形狀層都不應自己猜目前是第幾欄。接下來兩個 CodePen 真正值得比較的，是它們如何算出形狀應該移到哪裡。

兩個 CodePen 真正的差異在定位方式#

alinjfz 的核心計算可整理成三步：

1. 取得選中按鈕相對於 viewport 的矩形。
2. 扣掉 Tab Bar 的左側位置，再補上按鈕與凹槽寬度差的一半。
3. 將結果交給 translate3d()。

這樣算出來的不是「第幾格」，而是選中按鈕在當下版面中的真實中心。來源範例也會在視窗縮放時再次執行同一個計算。

sanchodelniglo 的 JavaScript 則直接使用這個關係：

1
const left = index * 120 + 60 - 45;

120 是每個項目的固定寬度，60 是項目中心，45 是 90px 指示器的一半。這個算式在原範例成立，因為 CSS 同時把連結寫死為 width: 120px。只要改成平均分欄、變更項目寬度或加入不同長度的文案，JavaScript 與 CSS 的隱含契約就會失效。

注意：alinjfz 適合借用的是架構，不是整份程式碼直接複製。它的編譯後 CSS 有多段重複的 .menu_color_2 選擇器，而且色彩、尺寸與 SVG 路徑都綁著原設計，實際專案仍應拆開整理。

倒圓角形狀與移動邏輯要分開#

原型把曲線放在獨立的 .tabbar__notch。這裡沿用 Bucardo 範例的連續曲線輪廓，但把高度壓到 24px，只讓圓形按鈕約三分之一露出導覽列；中央維持圓潤低凸，左右則用同一條 path 形成連續的倒圓弧，不用偽元素拼接。形狀本身不需要知道目前選中第幾項。

1
<nav class="tabbar" aria-label="主要導覽列">
2
  <div class="tabbar__notch" aria-hidden="true">
3
    <svg viewBox="0 0 202.9 45.5" preserveAspectRatio="none">
4
      <path
5
        fill="currentColor"
6
        d="M6.7 45.5c5.7.1 14.1-.4 23.3-4 5.7-2.3 9.9-5 18.1-10.5 10.7-7.1 11.8-9.2 20.6-14.3 5-2.9 9.2-5.2 15.2-7 7.1-2.1 13.3-2.3 17.6-2.1 4.2-.2 10.5.1 17.6 2.1 6.1 1.8 10.2 4.1 15.2 7 8.8 5 9.9 7.1 20.6 14.3 8.3 5.5 12.4 8.2 18.1 10.5 9.2 3.6 17.6 4.2 23.3 4H6.7Z"
7
      />
8
    </svg>
9
  </div>
10

11
  <button class="tabbar__item" aria-selected="true">首頁</button>
12
  <button class="tabbar__item" aria-selected="false">作品與研究</button>
13
  <button class="tabbar__item" aria-selected="false">最新消息</button>
14
  <button class="tabbar__item" aria-selected="false">關於我</button>
15
</nav>

凹槽使用絕對定位，平常只改 transform。will-change 不要套在整頁，只標記確定會移動的凹槽即可。

1
.tabbar {
2
  --notch-width: 108px;
3
  --notch-rise: 24px;
4
  position: relative;
5
  display: grid;
6
  grid-template-columns: repeat(4, minmax(0, 1fr));
7
}
8

9
.tabbar__notch {
10
  position: absolute;
11
  top: calc(var(--notch-rise) * -1);
12
  left: 0;
13
  width: var(--notch-width);
14
  height: var(--notch-rise);
15
  color: #1c2533;
16
  transform: translate3d(0, 0, 0);
17
  transition: transform 420ms cubic-bezier(0.22, 1, 0.36, 1);
18
  will-change: transform;
19
}
20

21
.tabbar__notch svg {
22
  display: block;
23
  width: 100%;
24
  height: 100%;
25
}
26

27
@media (prefers-reduced-motion: reduce) {
28
  .tabbar__notch {
29
    transition: none;
30
  }
31
}

如果設計稿需要更銳利或更深的凹槽，只要修改 path。若改用 CSS mask，也只替換這一層；getBoundingClientRect() 與 translate3d() 的定位程式不需要重寫。CSS masking 可以接受漸層或 SVG mask，但是否值得改用 mask，應依背景透明需求與目標瀏覽器測試結果決定。

用實際中心計算 transform 位移#

以下是這次實測使用的核心函式：

1
const tabbar = document.querySelector('.tabbar');
2
const notch = tabbar.querySelector('.tabbar__notch');
3

4
function moveNotchTo(item) {
5
  const barRect = tabbar.getBoundingClientRect();
6
  const itemRect = item.getBoundingClientRect();
7
  const notchWidth = notch.offsetWidth;
8

9
  const x =
10
    itemRect.left -
11
    barRect.left +
12
    itemRect.width / 2 -
13
    notchWidth / 2;
14

15
  notch.style.transform = `translate3d(${x}px, 0, 0)`;
16
}

公式的目的只有一個：讓「按鈕中心」等於「凹槽中心」。它不需要知道欄數，也不假設每格都是 120px。

1
按鈕中心 = item.left - bar.left + item.width / 2
2
凹槽左側 = 按鈕中心 - notch.width / 2

這份原型的 Tab Bar 沒有 border。如果實際元件有 border，絕對定位的 containing block 與 getBoundingClientRect() 的 border box 會差一個邊框寬度，計算時要再扣掉 tabbar.clientLeft。

這個作法與 FLIP 並不完全相同，但都把動畫位移交給 transform。若要繼續整理版面量測與 transform 的關係，可以搭配站內的 FLIP 動畫優化技術 一起看；不要因此延伸成「所有 transform 都不會觸發繪製」這種過度簡化的結論。

ResizeObserver 比只聽 window resize 更完整#

原 CodePen 在 window.resize 時重新定位，已經比完全不處理尺寸變化可靠。不過元件寬度還可能因側欄開合、父層 grid 改變、字型載入或文案更新而變動，這些情況不一定伴隨 window resize。

原型改用 ResizeObserver 觀察 Tab Bar 與項目，再以 requestAnimationFrame() 合併同一幀的更新：

1
let activeItem = tabbar.querySelector('[aria-selected="true"]');
2
let frame = 0;
3

4
function scheduleMove() {
5
  cancelAnimationFrame(frame);
6
  frame = requestAnimationFrame(() => moveNotchTo(activeItem));
7
}
8

9
const resizeObserver = new ResizeObserver(scheduleMove);
10
resizeObserver.observe(tabbar);
11

12
tabbar.querySelectorAll('.tabbar__item').forEach((item) => {
13
  resizeObserver.observe(item);
14

15
  item.addEventListener('click', () => {
16
    activeItem.setAttribute('aria-selected', 'false');
17
    item.setAttribute('aria-selected', 'true');
18
    activeItem = item;
19
    moveNotchTo(activeItem);
20
  });
21
});
22

23
document.fonts?.ready.then(scheduleMove);

這段 callback 只修改 transform，不會改變被觀察元素的寬高。若 callback 內同時修改尺寸，就要避免 ResizeObserver 反覆觸發自身。

實測結果：四個項目與窄版都能對齊#

測試日期為 2026-07-21，環境為 macOS 的 Chrome。驗證不是只看綠色 PASS，而是在 420ms transition 結束後，分別讀取按鈕與凹槽的 getBoundingClientRect()，比較兩者中心位置。

測試過程也發現第一版雖然凹槽對得準，程式碼區塊的 intrinsic width 卻會把窄版卡片撐出 viewport。替外層與程式碼容器補上 min-width: 0，並讓程式碼區塊自行橫向捲動後，Tab Bar 才真正縮到 316px。這個問題與凹槽公式無關，但如果只點按鈕、不檢查整體寬度，很容易漏掉。

桌面版依序切換四個項目後，畫面與量測值如下：

窄版選擇較長的「作品與研究」文案後，凹槽仍以實際中心重新定位：

瀏覽器 Console 沒有錯誤。實際專案的自動化測試仍建議使用 0.5px 左右的容許值，避免不同 device pixel ratio 與次像素取整造成不必要的失敗。

實際套進專案前還要補的部分#

這份原型證明定位與響應式計算可以成立，但正式元件仍有幾件事要依產品語意處理：

• 如果它是頁面導覽，應使用 <a> 與 aria-current="page"，不要為了造型硬套 tab 語意。
• 如果它真的是 tab，除了 role="tab" 與 aria-selected，還要補左右方向鍵、焦點管理與對應的 tabpanel。
• 初次定位應先關閉 transition，量測完成後再加入動畫 class，避免頁面載入時凹槽從最左側滑進來。
• 切換期間不要用當下的 transform 矩形判定失敗；測試要等待 transitionend，或比較計算出的目標中心。
• 形狀、定位與選中狀態分三層處理，之後換 SVG path 或 CSS mask 才不會連互動程式一起改。

最後保留的一句話是：倒圓角的畫法可以換，但移動式凹槽要以「實際量測 + transform」為骨架，避開把欄寬藏在索引公式裡。

常見問題#