yonathan-boop/Claude

antislop-layoutmobile

反 Slop：AI 程式碼代理規則。行動版佈局技能

屬於 antislop 系統的一部分。請與 antislop.md（核心）一起閱讀。此技能深入探討回應式佈局的要點：佈局如何跨螢幕尺寸（手機到桌上型電腦）重新排列。包括斷點、縮放、網格、溢出、點擊目標和導航。它透過編號引用核心規則，絕不重複或重新編號。當任務是建立或編輯需要在任何螢幕寬度下都能正常顯示的佈局時，請載入此技能。

如何使用此技能

• 每當任務是行動版或回應式佈局工作時，請與 antislop.md 一起載入。核心技能掌管機制（目的測試、三個層級、交付關卡）；此技能提供行動版佈局的深度知識。
• 每個條目都具有相同的結構：Tell（模式）、Why（為何被視為 slop）、Fix（應如何修正），並引用相關的核心規則（格式為 R-XX）。
• 此技能背後的原則：**行動版佈局是一種不同的佈局，而不是電腦版佈局在較小尺寸下的版本。**它必須重新排列：重新堆疊、重新縮放，並有目的地重新排序。以下的每個模式都是一種佈局未能重新排列的情況。
• 核心技能中的交付關卡仍然是最終的檢查關卡。此文件末尾的「行動版佈局技能檢查清單」是與之一起執行的行動版特定補充項目。

斷點

僅有電腦版佈局

• Tell： 所有螢幕共用一個佈局狀態；行動版檢視就是將電腦版佈局塞進手機畫面中。
• Why： R-03 要求行動版佈局必須完美，不能是事後補救。一個只會縮小的頁面根本沒有行動版設計：原本並排且能正常顯示的卡片會重疊，為寬螢幕設計的文字會擠在狹窄的畫面中。
• Fix： 在內容開始無法正常顯示的斷點處定義一個真正的行動版狀態。行動版佈局應重新排列：欄位堆疊、尺寸縮小，並根據內容需求改變順序。如果行動版檢視只是電腦版檢視的縮小版，那麼佈局就尚未完成。

以裝置列表驅動的斷點

• Tell： 斷點以手機寬度（375px, 414px, 768px）命名，選擇原因是「那是 iPhone 的尺寸」，而不是因為內容在該處斷裂。
• Why： 裝置寬度每年、每個型號都在變化。斷點是佈局無法維持的點；強迫它匹配裝置列表，會使佈局遵循規格表而非內容本身（R-03）。
• Fix： 將斷點設置在內容實際斷裂的地方：當一個欄位變得無法閱讀時，當一排卡片變得太窄時。透過縮小視窗並觀察佈局何處「斷裂」來進行測試，然後在該處設置斷點。

行動版最後才處理

• Tell： 行動版規則作為事後覆蓋附加：一個很長的電腦版樣式表，末尾帶有一個修補一兩項問題的小型 media query。
• Why： 補丁式的覆蓋不是行動版設計。它只修復了被回報的症狀，卻留下了下一個問題，而且基礎樣式仍然是為寬螢幕調整的（R-03）。
• Fix： 將行動版視為一個經過設計的狀態，而非一個覆蓋。為窄視窗賦予其自身經過考量的尺寸和堆疊，並驗證整個佈局在該狀態下的表現，而不僅僅是修補過的部分（R-35）。

雙狀態佈局

• Tell： 一種只有兩種狀態的佈局：在一個斷點以下是單一 stacked 欄位，在其之上是寬的多欄網格，中間沒有任何定義。平板電腦或小型筆記型電腦的寬度會繼承最接近的狀態：要嘛是荒謬地被拉寬的手機堆疊，要嘛是塞進預期畫布一小部分的電腦版網格。
• Why： 頁面是一個連續的寬度範圍，R-03 要求它在每一個寬度下都能正常顯示，而不僅僅是兩個選定的斷點。兩個狀態會留下整個中間頻寬（大約 600 到 1024 像素，平板電腦和小型筆記型電腦的所在範圍）成為一個意外：內容既不是有目的地堆疊，也不是適合的網格。佈局只在其兩個採樣點上顯得經過設計，而在兩者之間的任何地方都是破損的。
• Fix： 在內容停止正常顯示的寬度處定義真正的狀態，並且狀態的數量應根據內容需求而定。典型的重新排列是三個狀態，而不是兩個：單欄，然後在卡片作為單一堆疊變得太寬時轉為雙欄網格，最後僅在確實合適時才使用完整的多欄網格。透過將視窗拖曳過整個範圍來驗證，而不是檢查兩個寬度就宣告完成（R-35）。

縮放與尺寸

所有元素都使用電腦版尺寸

• Tell： 內距、間距、主視覺高度和卡片尺寸從電腦版到行動版都保持不變，導致每個區塊在手機上看起來都過大。
• Why： 為 1440px 畫布設計的元素會主宰一個 375px 的畫布。在電腦版上看起來自信的元素，在行動版上變得過大：沒有東西能合適地放置，沒有東西能呼吸，頁面感覺像是為了一個不在手中的螢幕而設計的（R-03）。間距和字體應遵循設計韻律（R-05），而這個韻律在行動版上有著更小的基調。
• Fix： 為行動版提供其自身的尺寸階層：更小的字體比例、更緊湊的區塊內距、更小的間距。保持點擊目標的最小尺寸（請參閱點擊目標），但在斷點處有目的地縮小其他一切元素。

固定像素字體

• Tell： 字型大小使用固定的 px，在電腦版和行動版之間從不改變，導致標題和正文在手機上仍然過大。
• Why： 不隨視窗回應的字型是為單一螢幕尺寸設計的字型。R-03 要求行動版佈局必須正常，R-06 要求字體排版能提升可讀性。一個橫跨整個手機寬度的標題，或是一個為寬行距調整的正文大小，會同時違反這兩條規則。
• Fix： 使用流動式字型（clamp()），使尺寸隨視窗縮放，或在斷點處設置更小的字型階層。在窄寬度下驗證結果（R-35），而不僅是在電腦版預覽中檢查。

100vh 區塊

• Tell： 主視覺和區塊高度設為 100vh，導致一個區塊填滿整個手機螢幕，並將所有其他內容推到摺疊線以下。
• Why： 為電腦版顯示器設計的滿視窗區塊在手機上變成一個巨大的區塊，而 100vh 包含了瀏覽器介面，在行動版瀏覽器上會溢出可見區域。它主宰了佈局，而不是介紹佈局（R-03）。
• Fix： 讓區塊根據內容決定尺寸（auto），或在需要真正全高區塊的地方使用動態視窗單位（dvh）。摺疊線以下的任何內容都不應是視窗單位的意外結果。

巨大的空白內距

• Tell： 電腦版比例的區塊內距（96px, 128px）保留在行動版上，在手機上造成區塊之間過高的空白間隙。
• Why： 為大畫布調整的內距在小畫布上變成了浪費的垂直空間。頁面滾動穿過空無一物的區域，而 R-05 所要求的韻律變成了每個區塊之間的空白深淵。
• Fix： 在斷點處將區塊內距減少到行動版的基調（大約一半或更少），並檢查頁面是否以自然的密度滾動，而不是穿過空白的沙漠。

網格與堆疊

不會摺疊的欄位

• Tell： 多欄網格在行動版上保持並排列，導致欄位縮小、文字尷尬地換行、元素互相碰撞。
• Why： 網格是一個關於可用寬度的承諾。當視窗變窄且網格不重新堆疊時，每個欄位都只得到一丁點空間，文字變得無法閱讀，卡片重疊（R-03）。這是碰撞失敗：電腦版的並排變成了行動版的堆疊。
• Fix： 在斷點處將網格摺疊成一個單一的重新排列欄位。並排變成堆疊，每個項目再次獲得完整寬度。在窄寬度下重新驗證（R-35）。

固定寬度的網格

• Tell： grid-template-columns 設定為固定的 px，或網格區域無法重新排列，導致視窗縮小時網格保持僵化。
• Why： 固定 px 的軌道不關心視窗；它保持其寬度並強制產生溢出或碰撞。佈局是為了一個畫布而構建，且無法改變形狀（R-03）。
• Fix： 使用 minmax() 或 auto-fit 與 auto-fill 來設定軌道尺寸，使欄位能隨著內容縮小和換行，並定義在斷點處會摺疊的網格區域。網格預設應該是流動的，只有在固定尺寸是故意的情況下才使用固定值。

強制 12 欄

• Tell： 將 12 欄網格強加於只需要一兩欄的行動版內容，導致跨度看起來隨意，數學運算與佈局對抗。
• Why： 12 欄系統是為具有許多內容欄位的寬畫布設計的。將其強加於手機，會使每個元素變成使用者從未見過的隱形網格的一個分數，內容被強迫適應網格，而不是網格適應內容（R-03）。
• Fix： 讓欄位跟隨內容。在行動版上，內容通常只需要一欄，最多兩欄；12 欄跨度只有在佈局確實有那麼多東西並排時才有意義。

溢出

水平滾動洩漏

• Tell： 頁面橫向滾動，因為某個元素比視窗還寬：一個表格、一個程式碼區塊、一張圖片、一個長的不斷開字串。
• Why： 水平滾動是行動版上一個破碎的承諾。使用者看不到頁面的邊界在哪裡，佈局明顯地溢出螢幕（R-03）。這是最常見的溢出 slop，因為肇事者在電腦版預覽中位於畫面之外，直到手機開啟它才會被注意到。
• Fix： 找出比視窗寬的元素（需要重新排列佈局或滾動容器的表格、需要換行的程式碼區塊、設有 max-width: 100% 的圖片），然後將其包含或重新排列。在最小的目標寬度下驗證整個頁面具有零水平滾動（R-35）。

隱藏溢出的裁剪

• Tell： 容器上的 overflow: hidden 在窄寬度下裁剪內容，隱藏文字或控制項，而不是讓它們適應。
• Why： 裁剪是隱藏失敗。當容器因為佈局無法容納而切斷其內容時，使用者會失去資訊和互動能力（R-03）。這方面的縮放和文字縮放問題由 antislop-human 負責。
• Fix： 讓內容重新排列而不是裁剪：允許容器成長、讓其內容換行，或在斷點處將其摺疊。僅在裁剪是設計意圖時才進行裁剪（例如縮圖），絕不要在會隱藏內容的地方使用。

固定寬度的子元素

• Tell： flex 或 grid 的子元素具有固定的 px 寬度或 min-width，在窄螢幕上會衝出其父容器。
• Why： 以絕對 px 尺寸設定的子元素不關心其父容器有多少空間。在行動版上，父容器縮小而子元素保持寬度，因此它會溢出容器和頁面（R-03）。
• Fix： 使用相對單位設定子元素尺寸，並讓它們換行（flex-wrap、流動寬度、網格子元素的 min-width: 0）。子元素應能隨著容器縮小，而不是保持電腦版尺寸。

點擊目標

過小的目標

• Tell： 按鈕、連結和控制項小於約 44 x 44 像素，用游標在電腦版上很容易點擊，但用拇指卻很難點到。
• Why： 電腦版游標具有像素級精確度；拇指則沒有。一個在 16px 時還可以的目標，在手機上變成了令人沮喪的練習，並且違反了 UI 在行動版上可用的承諾（R-03）。
• Fix： 賦予互動目標至少 44 x 44 像素的最小觸控區域，即使視覺上較小，也要透過內距或更大的點擊範圍來達成。在手機寬度下驗證整個控制項集合（R-35）。

目標距離太近

• Tell： 44px 的目標擠在一起沒有間隙，導致拇指點擊時點到錯誤的目標。
• Why： 目標尺寸只有與目標間距結合才有意義。兩個緊貼的大控制項行為就像一個大控制項：使用者無法可靠地選擇其中任何一個（R-03）。
• Fix： 在相鄰的互動目標之間留下清晰的間隙，至少幾個像素，理想情況下應足夠大，使手指按壓區域不會重疊。間距是可點擊性的另一半。

僅限懸停的互動

• Tell： 僅在懸停時才存在的選單、揭示框和工具提示，導致觸控使用者永遠無法打開它們。
• Why： 觸控螢幕上沒有懸停狀態。一個僅對懸停有反應的互動，對行動版使用者來說根本不存在，任何依賴懸停的控制項都是一條死路（R-03）。
• Fix： 為每個僅限懸停的互動提供一個點擊等效項：在懸停時開啟的選單也應在點擊時開啟，揭示框也應在點擊時顯示，並且互動元素應顯示可見的 :active 回饋，以便點擊能被確認。透過僅使用觸控來測試 UI（R-35）。

行動版導航

保持電腦版風格的導航

• Tell： 電腦版的頂部導覽列及其一排連結在行動版上保持並排，導致連結擁擠、換行成兩排，或溢出視窗。
• Why： 電腦版導航是為寬畫布設計的。在手機上保持為一排會變成一團擁擠的連結，而這是行動版使用者遇到的第一件事（R-03）。導航是重新排列最重要的地方：使用者在能夠前往任何地方之前，必須先找到要去哪裡。
• Fix： 在斷點處將導航摺疊成行動版模式：為少數主要目的地提供底部導航，或為其餘項目提供選單。連結從一排中重新排列出來，主要目的地保持在一個拇指點擊的距離內。驗證它在窄寬度下能正常運作（R-35）。

純漢堡選單

• Tell： 所有內容都隱藏在一個沒有標籤也沒有提示的漢堡圖示後面，導致使用者從未意識到選單的存在，或無法分辨它會打開什麼。
• Why： 純漢堡選單假設使用者已經知道該圖示的含義，並且知道後面藏著一個選單。這是行動版使用者可能不具備的知識，而在行動版上，隱藏選單可能包含在應用程式中導航的唯一方法（R-03）。
• Fix： 保持選單的可發現性：為漢堡圖示加上標籤（「選單」），或保持主要目的地可見，僅隱藏次要項目。如果選單是到達某個重要項目的唯一途徑，那麼這個可達性必須是顯而易見的。

佔用內容空間的底部導航

• Tell： 一個固定的底部導航列覆蓋在內容之上，遮住了最後的列表項目、最後一個按鈕或使用者試圖完成的表單。
• Why： 底部導航是行動版上的一個常見模式，但它不能覆蓋內容。遮住使用者正試圖互動的 UI 會破壞操作流程，並且違反了 R-03 中關於佈局不應隱藏互動或資訊的要求。
• Fix： 為底部導航提供明確的定位空間：在頁面底部使用等於導航列高度的內距，或在導航列上方留出空間。確保所有內容都可供使用者查看和觸及。