上一篇做的 eyebrow 區塊很陽春，只能改文字、粗體、斜體等功能，但實務上會想讓它能置中、換顏色、調整上下間距，傳統做法要自己寫一堆設定 UI，然後把值套進 CSS。今天要講的 supports，讓你一行宣告換內建的控制項，而且完全不用自己寫。

supports 是什麼：跟核心借功能

supports 是 block.json 裡的一個欄位，用來宣告「這個區塊要開哪些核心內建的能力」。WordPress 核心已經幫你寫好了對齊、顏色、間距、字體這些控制項的 UI 和背後的 CSS 產生邏輯，你只要在 supports 裡打開開關，這些控制項就自動出現在區塊的側邊欄，改動也會自動套用。

概念上這很像傳統主題的 add_theme_support()。以前你在 functions.php 寫 add_theme_support('align-wide') 開啟寬版對齊；現在是在區塊層級，用 supports 精準地決定「這個區塊」要開哪些。

一段宣告，看它換來什麼

把 eyebrow 的 block.json 加上 supports：

{
  "supports": {
    "align": [ "left", "center", "right" ],
    "color": {
      "text": true,
      "background": true
    },
    "spacing": {
      "margin": true,
      "padding": true
    },
    "typography": {
      "fontSize": true,
      "lineHeight": true
    }
  }
}

存檔、重新載入編輯器，你會發現這個區塊的右側欄突然多出來：

這些 WP 核心內建的，而且它們自動綁定 theme.json：顏色選擇器裡出現的就是你在 theme.json 定義的那組色；間距滑桿的刻度，就是你設定的 spacing scale，supports 讓設計系統的預設就能維持一致性。

為什麼這件事對 Block Theme 特別重要

回想第二部我們反覆強調的「單一來源」，supports 是這個理念的執行者之一：它讓區塊的顏色、間距不可寫死成某個 hex 或 px，因為使用者是從 theme.json 提供的選項裡挑。這代表當你日後改 theme.json 的主色，所有用了 color support 的區塊顏色一起換，就不用一個一個改。

傳統佈景主題如果沒有系統性的規劃樣式，顏色、間距散落在無數 CSS 檔和 inline style 裡，改一個配色會很麻煩，supports + theme.json 從結構上根除了這個問題。

Supports 的缺點

supports 不是開越多越好，你替一個「只該置中的標語」開了 align 的全部選項，使用者就可能把它靠左進而破壞原本的版面設計。原則是只開這個區塊「應該」被調整的維度。像我請 AI 做的 service-card，就刻意把 align 設成 false，因為它的定位是排在 grid 裡的卡片，不該被單獨對齊。

跟 AI 協作時這點很好用：你可以直接說「這個區塊只給改文字色和上下間距，其他別開」，它就會把 supports 精準地設成那樣。你在做的其實是「設計決策」，把實作交給 AI。

WordPress 7.1：連互動狀態也能宣告

這種「宣告一下就白拿控制項」的思路，WordPress 7.1 又往前推了一步：連 :hover、:focus、:focus-visible、:active 這些互動狀態，現在都能在全域樣式裡宣告式地設定，不用自己手寫 CSS。目前先開放在 Button 和 Navigation Link 這兩個區塊，之後會擴增到其他區塊上。

以前非得手寫 CSS 才做得到的 hover 變色、focus 外框，正一項項長和到「宣告就有」的控制項裡。這也代表你替自訂區塊思考「該開哪些 supports」時，可調整的維度只會越來越多。

跟這件事同步的還有自訂斷點（settings.viewport）、文字陰影、背景漸層等一批 7.1 新增的宣告式能力，全都是同一個走向：把過去要寫死在 CSS 的東西，變成 theme.json 和 supports 裡一個可宣告的選項。

到這裡，我們的區塊已經能使用 theme.json 的設計元素了，但它還是「靜態」的，也就是內容寫死在文章裡。下一篇我們探討動態區塊，讓內容改由 PHP 在載入時渲染，並且比較兩條路：用 ACF 欄位還是用原生的 attributes。

文章目錄：https://oberonlai.blog/category/2026-ithome/