Day 5｜輸入文字也有分工：Text Field、Textarea、Password 與 Search

本文同步自 2026 iThome 鐵人賽原文 ，發布日期為 2026-08-06。完整系列可見 iThome 系列頁 。

安安～我是ChiYu～

昨天才把邀請 Dialog 的操作區分清楚：送出用 Button，權限說明用 Link。按鈕總算不再互相冒充，我把視線往上一移，新的問題已經排好隊等我了。

帳號、密碼、搜尋和備註，一人分到一個長方形輸入框。AI 的處理方式俐落得很：複製元件、換 Placeholder、收工。

畫面沒有壞，四份工作卻被壓成同一種。帳號要保存短資料，密碼不能直接露出來，搜尋輸入後得改變清單，備註則要容得下一段完整說明。它們唯一穩定的共同點，大概只剩「都能打字」。

我先打開元件比較頁，把圓角、框線和顏色放到一旁，只看文字輸入後發生什麼。

圖 1：四個元件外觀都像輸入框，資料用途與輸入後的反應才是真正差別。

四個輸入框只換 Placeholder，資料規則仍然全靠 AI 猜

我先不背元件名稱，只問一題：使用者打完字後，系統接下來要做什麼？答案寫出來，四個框自然就分家了。

這裡沒有哪個元件比較高級。Text Field 不是預設答案，Search Field 也不會因為多一個放大鏡就自動懂得搜尋。先把資料與操作說清楚，再讓元件各自回座位。

我先實測最容易靠外觀混過去的 Password 與 Search

我先在 Password Field 輸入 Aurora2026，再按「顯示密碼」。內容沒有被清空，控制名稱改成「隱藏密碼」，畫面也提醒「密碼目前顯示中，請留意周遭環境」。

接著到 Search Field 輸入「設計」。原本的成員清單縮成一筆「陳怡安｜設計組」，結果文字顯示找到 1 位成員，旁邊出現清除控制。

如果只看截圖，這兩個欄位都像是右邊多一顆小按鈕的長方形框。真的操作一次，差異就藏不住了。

Password Field 在保護一個值，Search Field 在控制一批資料。框線長得像，責任完全不同。

Text Field 保存短資料，錯誤要留在欄位附近

在 Text Field｜文字輸入框 Demo 裡，我用專案名稱示範短文字輸入。這類元件適合姓名、Email、代碼與短名稱。

圖 2：Text Field 收一段短資料。Label、字數規則、目前值與錯誤回饋都留在欄位附近。

能打字只是 Text Field 的入場券。Label 要持續可見，必填與格式規則得說清楚；驗證失敗後，使用者剛才輸入的內容也不能憑空消失。

當內容已經長到需要換行、回頭閱讀，就別把 Text Field 往下拉高假裝沒事。那不是延長版 Text Field，是 Textarea 該接手了。

Password Field 遮住秘密，也要讓使用者安全校對

Password Field｜密碼輸入框 用來處理不應直接顯示的秘密值。預設遮蔽內容很合理，但不能因此要求使用者閉著眼睛相信自己完全沒打錯。

圖 3：Password Field 預設遮蔽內容；顯示或隱藏控制讓使用者校對輸入，切換後原值仍要保留。

顯示／隱藏控制要有清楚名稱，切換時不能清空內容，也不能把鍵盤焦點弄丟。畫面若提示密碼目前正在顯示，使用者才知道旁邊有人經過時該先遮回去。

姓名和 Email 雖然也是個人資料，卻需要直接校對。別看到「私人」兩個字，就順手把所有欄位變成一排圓點，最後連本人都不知道自己填了什麼。

Search Field 要讓清單真的變少，放大鏡不能只當裝飾

Search Field｜搜尋欄位 拿輸入文字去查找既有資料，不會把它當成表單值保存。它得交代何時查詢、搜尋中顯示什麼、找到幾筆，以及清除後回到哪裡。

圖 4：輸入「設計」後，畫面回報找到 1 位成員，只留下符合項目，並提供清除控制。

剛才輸入「設計」後，清單、結果數量與清除控制一起改變，這才叫搜尋。若框裡多了兩個字，底下三筆資料繼續老神在在，那只是 Text Field 戴了一副放大鏡。

輸入即搜尋時，結果區也不能每打一個字就大幅跳動。Vibe Coding 的需求若只寫「上面放一個搜尋框」，AI 最容易交出外觀；我還會補上觸發時機、搜尋中、無結果、結果數量與清除行為，才算把搜尋流程說完。

Textarea 留給完整段落，送出失敗也不能吃掉內容

Textarea｜多行輸入框 適合備註、說明與原因。它需要足夠空間讓使用者回頭閱讀，也要處理換行、字數限制與送出失敗後的內容保留。

圖 5：Textarea 處理段落內容。可閱讀的輸入空間、字數提示與錯誤後保留內容，都是這個元件的工作。

字數接近上限時可以先提醒，超過後則要明確說出限制。若送出失敗，不能順便把使用者剛打完的兩百字一起消滅，否則下一次填寫大概會比錯誤訊息更有情緒。

反過來，只收一個短名稱或代碼時也不用 Textarea。畫面多出一大片空間，資料不會因此變得比較重要。

四個元件都能在 文字輸入元件完整比較頁 放在一起核對。先看資料用途，再到各自頁面操作狀態，會比看著四個靜態框猜名稱有效。

輸入第一個字後 Placeholder 就下班了，Label 不能跟著走

輸入框常被做得只剩 Placeholder，畫面看起來很乾淨。代價也很直接：使用者打下第一個字，欄位名稱就消失了。

Placeholder 比較像暫時貼在門上的便利貼，Label 才是門牌。便利貼一被輸入內容蓋掉，使用者回頭只剩一串資料，還得重新猜這是哪個房間。

圖 6：Label、輔助說明、目前值與錯誤訊息各有責任，不能全部塞進 Placeholder。

這圈文字看起來不像元件主角，卻直接決定欄位出錯後能不能修。只把輸入框畫漂亮，等於替表單準備了一張很好看的沉默臉。

四個問題，決定文字該進哪一種輸入元件

1. 要從既有資料中找項目嗎？使用 Search Field。
2. 內容需要遮蔽嗎？使用 Password Field。
3. 使用者要寫一段完整說明嗎？使用 Textarea。
4. 其餘短文字、代碼或格式化資料，使用 Text Field。

這個順序是我會採用的判斷方式。先排除搜尋、秘密與長內容，剩下的短資料才交給 Text Field，不會一開始就把所有需求塞進預設輸入框。

改寫 Prompt：四個欄位要各自交代資料與反應

我不再要求 AI「做四個漂亮輸入框」。下面這份 Prompt 直接寫清楚資料規則、操作結果和 360px 的驗收方式：

為 LumenDesk 的新增成員表單設計四種輸入元件：
1. 工作區帳號使用 Text Field，保留可見 Label，必填與格式錯誤要顯示在欄位附近。
2. 初始密碼使用 Password Field，預設遮蔽，提供有文字說明的顯示／隱藏按鈕；切換時不可清空內容。
3. 成員搜尋使用 Search Field；輸入「設計」後顯示符合人數與清除控制，並提供搜尋中與無結果狀態。
4. 邀請備註使用 Textarea，最多 200 字，顯示目前字數與超過上限的錯誤訊息。
所有欄位在 360px 寬度下都要看得見 Label、訊息與操作控制。

這段規格交出去後，我還會故意做四件不太配合的事：填錯帳號、切換密碼顯示、搜尋不存在的成員，再讓備註超過 200 字。

帳號欄要保留錯誤值並告訴我怎麼修；密碼切換不能清空；搜尋要進入無結果狀態並保留清除入口；Textarea 則要顯示目前字數與上限。若最後只得到四圈紅色邊框，這份表單仍然在演同一齣戲。

四個欄位不必長得花俏，但不能繼續互相代打

修改後的 Demo 裡，帳號欄負責保存短資料與格式錯誤；密碼預設遮蔽，切換顯示後原值仍在；搜尋「設計」真的會縮小成員清單；備註則保留多行內容與字數狀態。

四個元件可以使用同一套視覺 Token，這沒有問題。真正被拆開的是資料責任與互動行為。

我繼續往下填邀請表單，AI 又很整齊地替 Email、站內通知、通知頻率和「邀請後立即啟用」放上同一種開關。

熟悉的味道回來了。

現在要處理的問題不再是「可以輸入什麼」，而是「可以選幾個」以及「選完是否立即生效」。明天接著拆 Checkbox、Radio 和 Switch。

參考資料與查閱日期

• W3C WAI：Labeling Controls
• MDN：<input type="search">
• MDN：<textarea>

資料查閱：2026-07-31。