แท็ก <optgroup> อยู่ในมาตรฐาน HTML มาตั้งแต่เวอร์ชัน HTML 4.01 (ปลายยุค 90s) โดยมีหน้าที่ชัดเจนคือการจัดหมวดหมู่ตัวเลือกภายใน <select> เพื่อช่วยแยกกลุ่มข้อมูลให้ผู้ใช้อ่านและตัดสินใจได้ง่ายขึ้น แต่ในงานพัฒนาเว็บแอปพลิเคชันยุคปัจจุบัน แทบไม่ค่อยเห็นนักพัฒนาหรือ UI Designer เลือกหยิบมาใช้งาน
โครงสร้างและการทำงานพื้นฐาน
จุดประสงค์ของ <optgroup> คือการสร้าง Label ที่คลิกเลือกไม่ได้ เพื่อคั่นกลุ่มของ <option>
<select name="developer_role">
<optgroup label="Frontend">
<option value="vue">Vue.js</option>
<option value="react">React</option>
</optgroup>
<optgroup label="Backend">
<option value="dotnet">.NET Core</option>
<option value="laravel">Laravel</option>
</optgroup>
</select>
แม้จะตอบโจทย์ semantic markup และ accessibility (Screen Reader อ่านแยกกลุ่มได้ถูกต้องโดยไม่ต้องพึ่ง ARIA เพิ่มเติม) แต่องค์ประกอบนี้กลับถูกลดบทบาทลงอย่างมากด้วยเหตุผลเชิงเทคนิคและพฤติกรรมผู้ใช้
สาเหตุหลักที่ <optgroup> ไม่ได้รับความนิยม
1. ข้อจำกัดรุนแรงด้าน CSS Styling
<select> และ <optgroup> เป็น native OS-rendered controls เบราว์เซอร์แต่ละตัว (Chrome, Safari, Firefox) รวมถึงระบบปฏิบัติการ (iOS, Android, macOS, Windows) จะเรนเดอร์เมนูดรอปดาวน์แตกต่างกันโดยสิ้นเชิง
- คุณไม่สามารถปรับแต่ง
padding,margin,font-sizeหรือสีพื้นหลังของ<optgroup label="...">ได้อย่างอิสระ - เมื่อต้องส่งมอบงานให้ตรงกับ Design System ใน Figma การใช้ native
<optgroup>มักจะทำให้ UI แตกหรือไม่ตรงตามสเปก
2. ไม่รองรับการซ้อนกลุ่มหลายระดับ (No Nested Groups)
ตามข้อกำหนดของ W3C แท็ก <optgroup> ไม่สามารถซ้อนกันเองได้ (ห้ามวาง <optgroup> ข้างใน <optgroup>) หากข้อมูลมีลำดับชั้นลึก เช่น หมวดหมู่หลัก -> หมวดหมู่ย่อย -> รายการย่อย native element จะไม่สามารถแสดงผลแบบ multi-level tree ได้
3. การแสดงผลบนอุปกรณ์พกพา (Mobile Picker)
เวลาเปิด <select> บนสมาร์ตโฟน:
- iOS
เรนเดอร์เป็น Wheel picker ซึ่งบางเวอร์ชันของ Safari จะแสดง label ของ optgroup กลืนไปกับตัวเลือก หรือเว้นวรรคแบบแปลกๆ ทำให้ผู้ใช้สับสนว่าข้อความไหนเลือกได้ ข้อความไหนเป็นแค่หัวข้อ - Android
มักเปิดขึ้นมาเป็น Dialog ลอย ซึ่งรูปแบบการแบ่งขีดเส้นคั่นกลุ่มของแต่ละแบรนด์มือถือไม่สม่ำเสมอกัน
4. ขาดฟังก์ชัน Search / Filtering ในตัว
ถ้าชุดข้อมูลเยอะจนต้องแบ่งหมวดหมู่ (เช่น รหัสสาขาธนาคาร, จังหวัด-อำเภอ, หรือ timezone) ปัญหาที่แท้จริงของผู้ใช้คือ การค้นหา ไม่ใช่แค่การจัดกลุ่มแบบเลื่อนดูยาวๆ เพราะ native <select> ไม่รองรับ input search box ภายในตัว ผู้ใช้ต้องใช้วิธีกดปุ่มคีย์บอร์ดเดาตัวอักษรแรก ซึ่งไม่สะดวกบนหน้าจอมือถือ
ทางเลือกที่คนหันไปใช้แทน
เมื่อ native HTML มีข้อจำกัด โลกฝั่ง Frontend จึงเปลี่ยนไปใช้โซลูชันที่ยืดหยุ่นกว่า
- Custom Dropdown Components
การใช้<div>ประกอบร่วมกับ WAI-ARIA role (role="listbox",role="group") ผ่านไลบรารียอดนิยม เช่น Radix UI, Headless UI, Shadcn UI หรือคอมโพเนนต์เฟรมเวิร์กอย่าง Vuetify / PrimeVue - Autocomplete & Combobox
เครื่องมืออย่าง Tom Select, Choices.js หรือ Select2 (ในระบบเดิม) ที่ให้ทั้งการพิมพ์ค้นหา (Typeahead), การทำ Badge หมวดหมู่, และการปรับแต่งสไตล์ได้ 100% ผ่าน CSS/Tailwind
บริบทที่ <optgroup> ยังคุ้มค่าที่จะใช้
แม้จะไม่หวือหวา แต่ <optgroup> ยังมีที่ยืนสำหรับงานบางประเภท
- ระบบ Admin / Internal Tool หลังบ้าน
หน้าจอจัดการข้อมูลที่เน้นความเร็วในการโหลด ไม่ต้องการแบก JavaScript library เพิ่มเติม - ฟอร์มที่ไม่พึ่ง JavaScript
กรณีที่ต้องการให้ฟอร์มทำงานได้แม้ฝั่ง client ปิด script หรือเครือข่ายโหลด JS ไม่สมบูรณ์ - ข้อมูลขนาดเล็กถึงปานกลาง (10–30 รายการ)
เช่น การเลือกช่วงเวลาทำงาน (กะเช้า / กะดึก) ที่มีหมวดชัดเจนและไม่ต้องค้นหา
<optgroup> ไม่ได้หายไปเพราะมันใช้งานไม่ได้ แต่เพราะความคาดหวังต่อ UX ของเว็บยุคใหม่ก้าวข้ามขีดความสามารถของ native drop-down control ไปแล้ว