นักพัฒนาเว็บกำลังเผชิญกับความท้าทายด้านความเข้ากันได้ของเบราว์เซอร์อย่างมีนัยสำคัญกับฟีเจอร์ customizable select element ที่ Chrome เพิ่งเปิดตัวใหม่ เทคโนโลยีทดลองนี้ช่วยให้นักพัฒนาสามารถสร้างเมนูดรอปดาวน์ที่มีสไตล์สูงซึ่งไปไกลกว่าองค์ประกอบ HTML select แบบดั้งเดิม แต่การรองรับเบราว์เซอร์ที่จำกัดกำลังสร้างความหงุดหงิดในชุมชนนักพัฒนา
ฟีเจอร์ customizable select แสดงถึงความก้าวหน้าครั้งสำคัญในการควบคุมฟอร์มเว็บ ทำให้นักพัฒนาสามารถสร้างอินเทอร์เฟซดรอปดาวน์ที่ซับซ้อนและโต้ตอบได้ด้วยการจัดแต่งแบบกำหนดเอง การ scroll snapping และแม้แต่องค์ประกอบแบบเกมที่ได้รับแรงบันดาลใจจากอินเทอร์เฟซวิดีโอเกม อย่างไรก็ตาม การใช้งานปัจจุบันของเทคโนโลยีนี้เผยให้เห็นความแตกต่างอย่างชัดเจนในการรองรับเบราว์เซอร์ที่ส่งผลกระทบต่อการนำไปใช้ในโลกจริง
การรองรับเบราว์เซอร์สร้างปัญหาให้นักพัฒนา
ปัญหาเร่งด่วนที่สุดที่นักพัฒนาเผชิญคือความพร้อมใช้งานของฟีเจอร์นี้เฉพาะในเบราว์เซอร์ที่ใช้ Chrome เป็นฐาน ผู้ใช้ที่พยายามดู select element ที่ปรับปรุงแล้วเหล่านี้ใน Firefox และ Safari จะเห็นเพียงเมนูดรอปดาวน์มาตรฐาน โดยขาดการจัดแต่งแบบกำหนดเองและฟีเจอร์โต้ตอบที่ตั้งใจไว้ทั้งหมด ความไม่สอดคล้องของเบราว์เซอร์นี้บังคับให้นักพัฒนาต้องเลือกระหว่างฟังก์ชันการทำงานที่ล้ำสมัยกับการเข้าถึงได้แบบสากล
สถานการณ์นี้ได้กระตุ้นการอภิปรายเกี่ยวกับกลยุทธ์การปรับปรุงแบบค่อยเป็นค่อยไป แม้ว่าฟีเจอร์นี้จะทำงานข้ามเบราว์เซอร์ได้ในทางเทคนิคโดยการย้อนกลับไปใช้พฤติกรรม select มาตรฐาน แต่ความแตกต่างอย่างมากในประสบการณ์ผู้ใช้ทำให้เกิดคำถามเกี่ยวกับเวลาและวิธีการนำฟีเจอร์ทดลองดังกล่าวไปใช้ในสภาพแวดล้อมการผลิต
สถานะความเข้ากันได้ของเบราว์เซอร์:
- Chrome: รองรับเต็มรูปแบบพร้อมองค์ประกอบ select ที่ปรับแต่งได้
- Firefox: ย้อนกลับไปใช้ select มาตรฐาน ( Mozilla มีท่าทีเชิงบวกต่อข้อกำหนด)
- Safari: ย้อนกลับไปใช้ select มาตรฐาน (ไม่มีจุดยืนอย่างเป็นทางการ)
ความท้าทายในการใช้งานทางเทคนิค
นอกเหนือจากความเข้ากันได้ของเบราว์เซอร์แล้ว นักพัฒนายังระบุปัญหาทางเทคนิคเฉพาะที่ต้องแก้ไข ข้อเสนอแนะจากชุมชนเน้นปัญหาเกี่ยวกับแนวทางการใช้งานปัจจุบัน โดยเฉพาะอย่างยิ่งเกี่ยวกับวิธีการจัดการอินพุต ระบบเหตุการณ์ที่ใช้เมาส์ในปัจจุบันถูกวิพากษ์วิจารณ์ว่าล้าสมัยเมื่อเปรียบเทียบกับ pointer events สมัยใหม่ ซึ่งให้การรองรับที่ดีกว่าสำหรับอินพุตแบบสัมผัส ปากกา และเมาส์ ในขณะที่จัดการกรณีพิเศษได้อย่างมีประสิทธิภาพมากขึ้น
ปัญหาด้านประสิทธิภาพก็เกิดขึ้นเช่นกัน โดยเฉพาะอย่างยิ่งเกี่ยวกับฟังก์ชัน scroll snapping นักพัฒนารายงานความล่าช้าในการอัปเดตสถานะ UI เช่น ปุ่มนำทางที่ไม่สะท้อนทันทีเมื่อผู้ใช้ไปถึงจุดสิ้นสุดของรายการที่เลื่อนได้ ปัญหาเวลาเหล่านี้สร้างประสบการณ์ผู้ใช้ที่อึดอัดซึ่งลดทอนจากอินเทอร์เฟซที่ขัดเกลาที่ฟีเจอร์นี้มีจุดประสงค์ให้เกิดขึ้น
ปัญหาทางเทคนิคที่สำคัญที่ระบุได้:
- เหตุการณ์ของเมาส์ควรถูกแทนที่ด้วยเหตุการณ์ของพอยเตอร์เพื่อการจัดการอินพุตที่ดีกว่า
- การอัปเดตสถานะ UI ที่ล่าช้าเมื่อถึงขอบเขตการเลื่อน
- API ที่จำกัดสำหรับการควบคุม scroll snap แบบโปรแกรม
- ต้องใช้การคำนวณ CSS ที่ซับซ้อนเพื่อให้ทำงานได้อย่างถูกต้อง
 |
|---|
| ภาพนี้แสดงเมนูการเลือกที่คล้ายกับส่วนติดต่อดรอปดาวน์ที่ปรับแต่งได้ตามที่กล่าวถึง เน้นย้ำองค์ประกอบการออกแบบส่วนติดต่อที่อยู่ภายใต้การตรวจสอบทางเทคนิค |
แนวโน้มในอนาคตและการพัฒนามาตรฐาน
แม้จะมีข้อจำกัดในปัจจุบัน แต่ก็มีสัญญาณบวกสำหรับการนำไปใช้ในวงกว้าง Mozilla ได้แสดงการสนับสนุนข้อกำหนด ซึ่งบ่งชี้ว่าการใช้งาน Firefox อาจจะมาในอนาคต การสนับสนุนมาตรฐานนี้แสดงให้เห็นว่าฟีเจอร์นี้อาจจะบรรลุความเข้ากันได้ข้ามเบราว์เซอร์ที่จำเป็นสำหรับการใช้งานอย่างแพร่หลายในที่สุด
ชุมชนนักพัฒนากำลังทำงานอย่างแข็งขันเพื่อแก้ไขข้อบกพร่องปัจจุบันในขณะที่ข้อกำหนดมีการพัฒนา การอภิปรายเกี่ยวกับฟีเจอร์ API ที่ขาดหายไป เช่น การควบคุม scroll snapping แบบโปรแกรม บ่งชี้ถึงการปรับปรุงความสามารถของเทคโนโลยีที่กำลังดำเนินอยู่
ในขณะนี้ นักพัฒนาที่สนใจใช้ customizable select elements ต้องชั่งน้ำหนักอย่างรอบคอบระหว่างประโยชน์ของฟังก์ชันการทำงานขั้นสูงกับความเป็นจริงของการรองรับเบราว์เซอร์ที่จำกัดและข้อจำกัดทางเทคนิค
อ้างอิง: The customizable select - Part four: Scroll snapping, state queries, monster hunt