LESSON-12 · TOPIC 02
能區分控制項目前無效的 :invalid 與經使用者互動後才適合顯示錯誤的 :user-invalid。
能區分控制項目前無效的 :invalid 與經使用者互動後才適合顯示錯誤的 :user-invalid。
頁面一載入就滿版紅色錯誤會造成噪音；延後視覺錯誤不代表延後原生 validity 判定。
要修改的檔案：files/starter/main.js
定位：先執行 input.checkValidity()，再分開讀 matches(':invalid') 與 matches(':user-invalid')。｜依 starter-2 定位，只修改「:invalid 與 :user-invalid」的責任。
先結果，再原理；完成後要能說出自己看見的證據。
聯絡頁載入後所有 required 欄位立刻紅框，使用者還沒開始填寫。
起始狀態：email required 且 value 空白，data-valid-value 提供 student@example.com。
required facts invalidBefore=true、userInvalidAfter=true、validAfter=true。
驗收證據：invalidBefore=true、userInvalidAfter=true、validAfter=true
希望保留原生驗證，同時避免未操作欄位一載入就顯示強烈錯誤時。
常見混淆：:user-invalid 的互動時機由瀏覽器決定，不等同自行加入 touched class，支援差異需驗證。
這段程式是理解起點，不是要你直接跳過 Starter。
:invalid 是『現在資料不合規則』；:user-invalid 是瀏覽器判定使用者已經互動到適合顯示錯誤。
正式說法：:invalid matches controls failing constraint validation；:user-invalid matches invalid controls after user interaction according to user-agent heuristics。
input:invalid{border-color:#b42318}input:user-invalid{background:#fff1f0}每一步都留下可觀察結果；如果沒看到，先看「卡住先查」。
檔案：files/starter/main.js 定位：先執行 input.checkValidity()，再分開讀 matches(':invalid') 與 matches(':user-invalid')。
要做：先重新載入 Starter，記錄目前畫面、DOM、Computed、Console 或文件內容。
預期：能指出「先執行 input.checkValidity()，再分開讀 matches(':invalid') 與 matches(':user-invalid')。」目前的缺口。
證據：保存 files/starter/main.js 的目前狀態，並指出下一步只會修改哪個檔案責任。
卡住先查：確認開啟的是 files/starter/main.js，且定位到 先執行 input.checkValidity()，再分開讀 matches(':invalid') 與 matches(':user-invalid')。。
檔案：files/starter/main.js 定位：先執行 input.checkValidity()，再分開讀 matches(':invalid') 與 matches(':user-invalid')。
要做：執行表單 probe：讀空白 invalid、觸發使用者驗證狀態，再填 data-valid-value 並重驗。
預期：required facts invalidBefore=true、userInvalidAfter=true、validAfter=true。
證據：invalidBefore=true、userInvalidAfter=true、validAfter=true
卡住先查：先執行 input.checkValidity()，再分開讀 matches(':invalid') 與 matches(':user-invalid')。
檔案：files/starter/main.js 定位：先執行 input.checkValidity()，再分開讀 matches(':invalid') 與 matches(':user-invalid')。
要做：重新整理頁面，再逐項比對預期結果與 evidence。
預期：required facts invalidBefore=true、userInvalidAfter=true、validAfter=true。
證據：invalidBefore=true、userInvalidAfter=true、validAfter=true
卡住先查：先執行 input.checkValidity()，再分開讀 matches(':invalid') 與 matches(':user-invalid')。
這個示範只讓你看懂概念，不會替你修改 Starter，也不會自動宣告完成。
勾選只是學習紀錄；真正完成仍要回到 Starter 的實際結果。
先確認 validity，再討論錯誤顯示時機。
空白 required 應 invalid；模擬 blur/submit 後才觀察 user-invalid。
完整解答與原因：constraint validation 一開始已判定 invalid；user-invalid 反映互動後的顯示時機；填入有效 email 後 validAfter=true。