ป้ายกำกับ: สาระความรู้

แท็ก <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 ไปแล้ว