Modern CSS อาจทำให้งาน Front‑End ซับซ้อนขึ้นได้จริงหรือ

ย่อหน้าเปิด - ฟีเจอร์ CSS ยุคใหม่เช่น container queries, native nesting และ :has() ช่วยให้เราลดโค้ด JavaScript เดิมได้อย่างน่าพอใจ แต่ผู้เขียนตั้งคำถามว่าการย้ายตรรกะบางส่วนไปไว้ใน CSS อาจทำให้ระบบโดยรวมยากจะคาดเดาและดีบักมากขึ้น เรื่องนี้สำคัญเพราะทีม front-end ต้องเข้าใจผลกระทบข้ามชั้นระหว่าง CSS, JavaScript และการจัดวางเลย์เอาต์ของเบราว์เซอร์

ความเรียบง่ายในท้องถิ่น vs ความซับซ้อนของระบบ

ผู้เขียนไม่ได้บอกว่า Modern CSS เป็นสิ่งเลวร้าย แต่ชี้ว่าฟีเจอร์ใหม่สามารถทำให้ไฟล์เดียวดูสะอาดขึ้นในเชิงโค้ด แต่ก็อาจสร้างสถานะการทำงานที่ซ้อนทับกับ JavaScript หรือกฎเดิมได้ ในงานจริงมักเกิดการย้ายแบบค่อยเป็นค่อยไป - ตัวอย่างเช่นการแทน ResizeObserver ด้วย @container rule ที่ดูเรียบร้อย แต่ Observer เดิมอาจยังคงอยู่ในไฟล์อื่นหรือมี selector ที่เหลืออยู่ ทำให้เกิดสถานะที่ไม่มีใครเขียนไว้ระหว่าง breakpoint เดิมและใหม่

เมื่อเจ้าของสองคนควบคุมพฤติกรรมเดียวกัน

ปัญหาหนึ่งคือพฤติกรรมของคอมโพเนนต์ถูกกำหนดโดยสองแหล่ง เช่น JavaScript ที่สลับคลาส และ CSS ที่ใช้ :has() หรือ container queries มาคำนวณผลลัพธ์ ผู้เขียนแนะนำให้แบ่งความรับผิดชอบให้ชัดเจน - CSS ควรรับผิดชอบ presentation ที่ขึ้นกับขนาดหรือโครงสร้าง DOM ในขณะที่ JavaScript ควรเป็นเจ้าของสถานะแอปพลิเคชันและงานที่เป็น asynchronous

ผลข้างเคียงจาก container-type และ block formatting contexts

การประกาศ container-type: inline-size ดูเหมือนจะบอกแค่ให้ลูกคอมโพเนนต์สามารถ query ความกว้างได้ แต่จริง ๆ แล้วการประกาศนี้เปลี่ยนพฤติกรรมการจัดเลย์เอาต์หลายอย่างรวมถึงการสร้าง block formatting context และ inline-size containment ซึ่งอาจทำให้ margin ที่เคยยุบรวมเปลี่ยนเป็นไม่ยุบรวม หรือองค์ประกอบบางชิ้นวัดความกว้างเป็น 0px เมื่อนำไปรวมกับ flex, float หรือ auto grid

• ก่อนเพิ่ม container-type องค์ประกอบอาจดูและพฤติกรรมปกติ
• หลังเพิ่ม อาจเกิดการเปลี่ยนแปลงที่ไม่คาดคิด เช่นการเพิ่มความสูงหรือการหายไปของการแสดงผล

ผู้เขียนแนะให้ถามตัวเองก่อนใช้ container-type ว่าองค์ประกอบนั้นเอาความกว้างมาจากไหน หากมาจากเนื้อหาอาจต้องกำหนด width จากบริบทหรือย้าย container-type ไปไว้ที่ wrapper ที่มีขนาดชัดเจน รวมถึงทดสอบคอมโพเนนต์ในทุกเลย์เอาต์จริง ไม่ใช่แค่ในสภาพแวดล้อมแยกกัน

สิ่งที่ทีมควรทำต่อ

เมื่อย้ายความรับผิดชอบจาก JavaScript ไปยัง CSS ให้ทำให้เสร็จ - ลบ observer, คลาส และ selector ที่ไม่ใช้แล้ว เพื่อไม่ให้มีเจ้าบ้านเก่ายังอาศัยอยู่ นอกจากนี้ควรจดบันทึกการตัดสินใจ และใส่เทสต์เชิงเลย์เอาต์ด้วย เพราะ diff ของโค้ดมักแสดงแค่ความเรียบง่ายระดับไฟล์ แต่ไม่บอกว่ามีความสัมพันธ์หรือการโต้ตอบที่ซ่อนอยู่กี่จุด

สรุป - Modern CSS เพิ่มความสามารถมาก แต่ก็เพิ่มชนิดของความซับซ้อนใหม่ด้วย ทีมพัฒนาและนักออกแบบควรประเมินผลกระทบทั้งในระดับท้องถิ่นและระดับระบบก่อนใช้งานจริง และเมื่อย้ายตรรกะข้ามชั้นแล้วต้องทำความสะอาดโค้ดทั้งหมดเพื่อหลีกเลี่ยงสถานะที่ไม่มีใครควบคุม

ข้อควรติดตามสำหรับคนทำงานสายไอทีในไทยคือการเสริมทักษะด้านการทดสอบเลย์เอาต์และการเข้าใจ interaction ระหว่าง CSS กับ JavaScript จะช่วยลดเวลาดีบักเมื่อต้องรับมือกับฟีเจอร์สมัยใหม่

ที่มา: Smashing Magazine - เรียบเรียงและสรุปเป็นภาษาไทยโดยทีมงาน IT Genius