可自訂 Select 的黃金法則：文字優先，裝飾其次
WebKit Blog · 2026-06-22
Safari 27 隨著可自訂 <select> 元素的支援正式落地，讓開發者終於能夠不依賴 JavaScript 函式庫就自由控制下拉選單的視覺外觀。WebKit 工程團隊在 2026 年 6 月 22 日發表文章，揭示了一條貫穿整個設計哲學的黃金法則：永遠為 <option> 元素提供文字內容或可存取的文字屬性。這條規則若被違反，將同時引發使用者體驗、無障礙性與向下相容三方面的問題。
可自訂 Select 的基本啟用方式
要啟用可自訂選單，開發者需要在 CSS 中為 <select> 元素與 ::picker(select) 偽元素同時設定 appearance: base-select。設定後，選單的彈出層會渲染於頂層（top layer），類似 popover 的行為，不再受父層 overflow 或 z-index 的限制。選單的寬度也不再自動依照最寬的 <option> 決定，開發者可透過 CSS Anchor Positioning 精確控制彈出位置。 為確保跨瀏覽器相容，所有相關樣式應包在 @supports (appearance: base-select) 條件區塊內。
@supports (appearance: base-select) {
select,
::picker(select) {
appearance: base-select;
}
}圖示搭配文字：正確的漸進增強模式
可自訂 <select> 最常見的使用情境，是在選項中加入圖示或色票以提升視覺辨識度。WebKit 文章給出了推薦的 HTML 結構，強調圖示應作為「裝飾性補充」而非「語義載體」。裝飾性圖片應設定 alt=""，確保螢幕閱讀器不會朗讀出無意義的圖片檔名，真正的語義由相鄰的文字節點承載。 若希望視覺上隱藏文字但保留無障礙性，可搭配 .visually-hidden 樣式類別。
<option>
<img src="bird.svg" alt="">
<span>野生動物</span>
</option>上述範例中，<img> 的 alt="" 讓輔助技術略過圖片，而 <span> 內的文字則成為 Accessibility Tree 中的節點名稱。若完全省略文字只放圖片，盲人使用者、點字顯示器使用者、語音辨識使用者都無法操作這個選項。圖示不應取代文字，而應強化文字的語義。
三個同時受益的面向
文章以三個面向說明為何「文字優先」是不可妥協的黃金法則。第一是更好的使用者體驗：純圖示選單對不熟悉圖示的使用者造成認知負擔，加上文字標籤後選項立刻變得一目瞭然。第二是更好的無障礙性：文字存在於 Accessibility Tree，讓螢幕閱讀器、語音控制工具與點字顯示器皆能正常運作。 第三是更穩健的漸進增強：當瀏覽器不支援 appearance: base-select、CSS 載入失敗或圖片無法顯示時，文字內容確保選單仍能被理解與操作。
向下相容的防護措施
WebKit 特別提醒，目前並非所有瀏覽器都支援可自訂 <select>，因此漸進增強的思維至關重要。在 @supports 條件區塊外的 <option> 文字，就是不支援新 API 的瀏覽器所能展示的全部內容。若開發者將選項文字放進視覺隱藏的 <span>，這段文字在舊版瀏覽器中仍會正常顯示，確保退回原生選單時體驗不中斷。 這個設計邏輯與 <picture> 元素的 <img> fallback 如出一轍——裝飾層失效時，語義層依然穩固。
個人網站的結構化資料入門：JSON-LD 完整解說
hawksley.dev · 2026-06-22
搜尋引擎爬蟲看到的網頁，往往和人眼所見的差異甚大——它們需要語義線索來理解頁面內容究竟是部落格文章、作者簡介，還是軟體專案。JSON-LD（JSON Linked Data）是 Google 官方推薦的結構化資料格式，能讓爬蟲精確掌握頁面語義，進而改善搜尋排名與社群連結預覽。hawksley.dev 近期發表了一篇完整指南，專門針對個人網站說明如何實作 JSON-LD。
JSON-LD 的基本結構與載入方式
JSON-LD 透過一個特殊的 <script> 標籤嵌入 HTML 的 <head> 區塊。由於 type="application/ld+json" 不是瀏覽器會執行的 JavaScript 類型，頁面效能不受影響，但 Googlebot 等專用爬蟲會主動解析這個標籤的內容。 頂層結構包含 @context（通常指向 https://schema.org）與 @graph 陣列，所有資料節點都放在 @graph 內，節點之間可透過 ID 互相引用，形成語義圖譜。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"name": "我的個人網站",
"url": "https://example.com"
}
]
}
</script>個人網站常用的節點類型
Person 節點是個人網站最核心的資料型別，用來描述網站作者的身分。文章作者強調，sameAs 屬性尤其重要，列出你在 GitHub、Mastodon、LinkedIn 等平台的個人頁面，能協助爬蟲消歧義（disambiguation），確認不同平台上的你是同一個人。建議在每一個頁面都包含簡化版的 Person 節點，而非只在「關於」頁放完整版本。 其他常用節點類型包括：
WebSite：描述整個網站的基本資訊，包括名稱、描述與標誌圖片ProfilePage：適合用於「關於我」頁面，比通用的WebPage更語義精確CollectionPage：適合用於文章列表、作品集等以集合為主的頁面BlogPosting：描述單篇部落格文章，包含發布日期、修改日期、作者與封面圖SoftwareApplication：適合在個人網站展示自己開發的軟體專案BreadcrumbList：描述頁面的麵包屑導覽路徑，有助搜尋結果顯示路徑資訊
節點 ID 的命名慣例與節點間引用
每個節點的 @id 應使用帶有唯一 hash 識別符的 URL，例如 https://example.com/#person，這樣不同頁面引用同一個節點時，爬蟲可識別它們代表的是同一個實體。節點之間的引用讓結構化資料從「獨立的鍵值對」升格為「語義圖譜」，賦予爬蟲推斷隱含關係的能力。 例如 BlogPosting 節點的 author 欄位可以直接引用 Person 節點的 ID，而不必重複填寫所有作者資訊。
{
"@type": "BlogPosting",
"@id": "https://example.com/blog/my-post/#blogposting",
"headline": "我的第一篇文章",
"datePublished": "2026-06-22",
"author": {
"@id": "https://example.com/#person"
}
}對個人網站的實際效益
實作 JSON-LD 帶來的效益不只是 SEO 排名。當文章連結被分享至 Discord、Slack 或社群平台時，BlogPosting 節點中的 image、headline、description 欄位能讓預覽卡片顯示更豐富的資訊。Google Search Console 的「複合式搜尋結果」功能也仰賴結構化資料，正確的 BreadcrumbList 可讓搜尋結果在標題下方顯示頁面路徑，提升點擊率。 對於沒有預算購買專業 SEO 工具的個人網站而言，JSON-LD 是成本最低、回報最直接的技術投資之一。
Firefox 151 正式支援 Web Serial API：瀏覽器直連序列埠裝置不再是 Chrome 專屬
Mozilla Hacks · 2026-05-21
長期以來，Web 應用程式與序列埠裝置（如微控制器、3D 印表機、工業感測器）的溝通，必須透過原生應用程式或橋接軟體才能達成。Mozilla 於 2026 年 5 月宣佈，Firefox 151 正式支援 Web Serial API，使網頁應用程式能夠在取得使用者授權後，直接與透過序列埠、USB CDC-ACM 或藍牙 SPP 模擬序列埠的硬體裝置通訊。這項 API 自 Chrome 89（2021 年）起便是 Chromium 系瀏覽器的專屬功能，Firefox 的加入讓跨瀏覽器支援邁出重要一步。
Web Serial API 的核心架構
Web Serial API 的進入點是 navigator.serial，提供兩個主要方法：getPorts() 用來取得使用者先前已授權的埠列表，requestPort() 則觸發瀏覽器的原生埠選擇對話框，要求使用者明確選擇一個裝置。呼叫 requestPort() 必須在使用者手勢（如按鈕點擊）的事件處理器內發起，這是瀏覽器刻意設計的安全門檻，防止頁面在未經授權的情況下靜默存取硬體。 取得 SerialPort 物件後，需呼叫 port.open() 並指定鮑率（baudRate）才能開始傳輸。
// 必須在使用者手勢（如 click）內呼叫
const port = await navigator.serial.requestPort();
await port.open({ baudRate: 9600 });
// 讀取資料流
const reader = port.readable.getReader();
while (true) {
const { value, done } = await reader.read();
if (done) break;
console.log('收到資料：', value);
}
reader.releaseLock();基於 Streams API 的資料流架構
Web Serial API 的讀寫介面完全基於 WHATWG Streams API 設計，SerialPort 物件同時暴露 readable（ReadableStream）與 writable（WritableStream）兩個屬性。這個架構讓開發者可以利用 TransformStream 在資料流中插入解碼邏輯，例如使用 TextDecoderStream 將原始位元組轉換為字串，或使用自訂的換行解析器切割完整的指令訊框。 對於需要雙向通訊的應用場景（如傳送 G-code 指令給 3D 印表機並讀取回應），兩個流可以獨立並行運作。
// 傳送資料給裝置
const writer = port.writable.getWriter();
const encoder = new TextEncoder();
await writer.write(encoder.encode('G28\n')); // 歸零指令
writer.releaseLock();安全模型、熱插拔與使用限制
Web Serial API 僅在安全上下文（Secure Context）下可用，頁面必須透過 https:// 提供，本地開發時 localhost 亦被視為安全上下文。伺服器管理員可透過 Permissions-Policy: serial=() HTTP 標頭在整個站台層級停用此 API，對共享主機環境或需嚴格安全控管的場景尤為重要。API 同時支援監聽裝置的熱插拔事件：navigator.serial.addEventListener("connect", handler) 與 disconnect 事件讓應用程式能即時反應硬體狀態，不需輪詢。 應用場景涵蓋線上韌體燒錄器、硬體除錯介面、教育用微控制器平台（如 BBC micro:bit、ESP32）等。
跨瀏覽器現況與開發者注意事項
Firefox 151 的支援使工程師導向的 Web 工具不再被強制要求使用者切換至 Chrome，覆蓋範圍顯著擴大。Safari 目前仍不支援 Web Serial API，MDN 的瀏覽器相容性表格標記此 API 尚未達到「Baseline」狀態。在面向一般消費者的通用網站中仍需考量 fallback 策略，或在功能偵測失敗時引導使用者安裝對應的原生應用程式。 開發者可透過 if ("serial" in navigator) 進行功能偵測，確保在不支援的環境下優雅降級。
原始來源：Mozilla Hacks — Announcing Web Serial Support in Firefox · MDN — Web Serial API