範本範例
content-sass

content-custom-font

CSS 能力
在哪裡參考 CSS
manifest.json(content_scripts[].css)- HTML 檔案(
<link rel="stylesheet" href="...">) - Script 中的 import(
import "./styles.css",啟用時也包含 Sass/Less)
CSS 支援
Manifest 中的 CSS 進入點:範例:manifest.json 中的 CSS
範例:在擴充功能頁面 script 中引用 CSS
內容腳本中的網頁字型
把介面渲染到 shadow root 的內容腳本,無法只靠 CSS 載入網頁字型。有兩條平台規則會擋住它,而且都是靜默的。 shadow root 內部的@font-face 永遠不會生效。 字型(font face)解析的是文件的字型集,而不是 shadow 樹,所以 Chrome 會忽略該規則並靜默回退。修正前在 content-custom-font 範本上實測:document.fonts 為空,沒有發出任何字型請求,以 "Momo Signature", cursive 排版的文字寬度與純 cursive 完全相同。
注入樣式表中的根絕對 url() 會相對宿主頁面解析。 注入到 example.com 的樣式表中的 url(/fonts/Momo.woff2) 請求的是 https://example.com/fonts/Momo.woff2,而不是擴充功能自己的那份檔案。
改為把字型註冊到頁面自身的字型集上,URL 指向擴充功能,並在內容腳本卸載時移除它:
web_accessible_resources 中宣告:
document.fonts,shadow 樹就可以在一般的 font-family 規則裡以名稱使用它。可運行的版本見 content-custom-font。
依情境的輸出行為
Extension.js 會依照哪一個進入點 import 該 CSS 自動拆分情境。
開發行為
- Content script 的 CSS import 會參與 content script 的 HMR/重新掛載流程。
- Extension.js 會為純 CSS 的 content script 進入點加上開發輔助 script,讓更新可以傳播。
- 頁面 CSS 會走標準的頁面 HMR 流程。
- 結構性 manifest/content script 變更仍可能需要重新載入或重新啟動整個擴充功能。
模組與預處理器
- CSS modules 在擴充功能頁面情境中運作得最好。
- 當你安裝相關相依套件時,Extension.js 會啟用 Sass/Less 支援。
- 如果專案引用了
.scss/.less檔案但沒有安裝預處理器,建置不會失敗,而是發出警告並把原始檔原封不動地複製過去(不編譯)。瀏覽器會把這份未編譯的原始碼當成壞掉的 CSS,那些畫面就會完全沒有樣式,所以請安裝預處理器以取得真正的編譯。 - 當 Extension.js 偵測到專案中的 PostCSS 設定、或你明確設定時,會自動執行 PostCSS。
最佳實務
- 刻意限制 content script 樣式範圍,降低與主機頁面的衝突。
- 為擴充功能頁面 UI 優先採用元件本地的 module 樣式。
- 明確保留預處理器與 PostCSS 設定,避免建置設定隨時間意外改變。
- 在持續整合(CI)中驗證被 manifest 欄位參考的 CSS 路徑。
後續步驟
- 在 dev 更新行為中了解更新結果。
- 進一步了解 CSS modules。
- 進一步了解 PostCSS 整合。

