作品分類寫進 hash：讓篩選狀態跟著網址走

讀者在作品頁切到設計分類，再把網址傳給別人，如果對方打開後又回到預設分類，這個選擇其實只留在原來的畫面裡。

本站把作品分類放在網址的 hash。它讓「目前想看哪一類」有一個能分享、重新載入和返回的表示方式，但不代表所有周邊連結都會自動保持同步。2026 年 10 月 26 日，我把分類入口、無腳本退路和語言連結一起核對，確認這個狀態實際走到哪裡。

先挑值得留在網址裡的狀態

作品頁的分類選擇影響讀者要看哪一組內容，適合跟著網址走。卡片此刻的位移、圖牆高度和進場動畫進度則是呈現細節，不必一起變成公開網址。

目前三個分類使用同一份作品文件，分別對應這些繁中網址：

/about/work#development
/about/work#design
/about/work#aigc

Fragment 是 URI 中由 # 開始的部分，請求資源時不會送到伺服器，而是由用戶端在取得資源後處理。[3] 所以這裡不是替三個分類各建一份靜態頁，也不是依 hash 從伺服器撈不同資料。

這個選擇符合目前的內容規模：各分類正文已在 HTML 裡，網址只需要表達讀者想看的區塊。如果未來改成大量資料查詢、搜尋或多條件組合，就要重新決定路徑、query 和資料取得的分工，不能把這個小型案例直接當成所有篩選介面的答案。

分類入口從一開始就是連結

開發、設計與 AIGC 的入口是帶有 fragment 的 anchor，不是只有 click handler 的假連結。每個目的地也有相應的區塊 ID。

有腳本時，一般點擊會更新 location.hash，再同步顯示的區塊、分類外觀及 aria-current。使用修飾鍵的點擊則不走這段攔截，保留瀏覽器原來的處理方式。

這組入口沒有宣告成 ARIA tabs，也沒有實作方向鍵切換 tab 的規則。它們是控制目前閱讀區塊的原生連結，不能因為畫面上排成一列，就替它補上一份不存在的鍵盤契約。

另外，分類切換與圖牆排列是兩件事。Hash 決定哪個區塊顯示；卡片怎麼分欄、圖片載入後如何重排，仍由作品頁自己的排程與觀察器處理。網址不用知道每張卡片的座標。

CSS 退路不必和腳本模式完全相同

停用頁面腳本後，在支援相關選擇器的瀏覽器裡，CSS 仍能用 :target 和 :has() 判斷目前的目標區塊，隱藏其他分類。

我在本機 Edge 禁止頁面腳本，直接打開設計分類，再用原生連結切到 AIGC，對應內容都能顯示。這個模式沒有執行腳本圖牆排列，也不會由腳本補上目前分類的可及性狀態。

有一個差別必須保留：沒有 hash 時，無腳本版本會留下全部分類內容；有腳本版本則預設顯示開發分類。遇到無法辨認的 hash，腳本同樣回到開發分類。

情境	顯示策略
有腳本、hash 對應設計	顯示設計區塊
有腳本、沒有或不認得分類 hash	預設顯示開發區塊
無腳本、支援選擇器且有對應 target	CSS 顯示目標分類
無腳本、沒有 target	各分類內容仍可閱讀

這個退路優先保住內容，不假裝每一種環境都有完全一樣的增強結果。不支援相關 CSS 的環境，也不能用這次 Edge 的觀察替它背書。

上一頁和重新整理，要讀回同一個選擇

只在 click handler 裡改畫面不夠。讀者可能直接打開帶 hash 的網址，也可能使用上一頁，而不是再點一次分類入口。

目前腳本在初始化時讀取 hash，並監聽 hashchange 與 popstate，把顯示狀態重新對齊網址。本機操作從設計切到 AIGC，再以瀏覽器歷史返回，畫面回到設計；重新載入後，也仍顯示設計分類。

這些觀察證明的是分類與網址的同步，不是所有歷史返回快取情境都已驗收。網址保留了狀態，仍然需要正確的初始化和事件處理，才能把那個狀態還原成畫面。

另一個入口可能拿著舊的狀態快照

核對語言切換時，我找到一個比「有沒有複製 hash」更具體的限制：目前共用腳本在初始化及桌面語言選單切換開合時更新語言連結，並沒有在每次作品分類改變後同步所有入口。

實際先打開設計分類，再切到 AIGC，手機導覽裡的英文連結仍保留初始的設計 hash；改由桌面語言選單觸發更新，才會帶上當下的 AIGC hash。

所以不能把「初始化時複製過網址」寫成「語言切換永遠保留目前分類」。這是目前實作的限制，不是建議讀者每次先開桌面選單，也不是這篇文章已經修好該行為。

如果要把這類狀態契約補完整，我會先列出哪些入口依賴它，再決定更新應該跟著狀態變更，還是發生在使用入口之前。這比在每個連結旁邊各存一份分類，更容易檢查誰還拿著舊值。

靜態 Astro 頁面如何保留 Canvas、GSAP 與局部互動說明互動的責任範圍；這裡關心的是狀態的去向。Hash 讓分類可以跟著網址走，實際分享、返回和跨入口同步，仍要分別確認。

Sources

[3] https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Fragment — MDN: URI fragment