Container queries กลายเป็นฟีเจอร์ที่ได้รับการรองรับอย่างแพร่หลายแต่กลับมีอัตราการใช้งานไม่สูงเท่าที่ควร - ปัจจุบันเบราว์เซอร์รองรับราว 94% แต่ตามแบบสำรวจ 86% ของนักพัฒนารู้จักฟีเจอร์นี้จริงๆ แล้วมีเพียง 41.4% เท่านั้นที่นำไปใช้งานจริง เหตุผลหนึ่งมาจากความเข้าใจผิดที่มองว่า container queries ทำงานเหมือน media queries แบบเดิม ซึ่งไม่จริงและทำให้ใช้งานผิดจุดประสงค์
แตกต่างเชิงแนวคิด - viewport กับ container
เมื่อเราเขียน @media สิ่งที่ถามเบราว์เซอร์คือ - "ความกว้างของหน้าจอตอนนี้เป็นเท่าไร" - นั่นคือจุดอ้างอิงเป็น viewport ซึ่งออกแบบมาสำหรับการจัดวางเลย์เอาต์ระดับหน้าเพจหรือ "macro" layout เช่น header, grid หลัก หรือการตั้งค่าของอุปกรณ์
ในทางกลับกัน container queries ตั้งคำถามกับพื้นที่ที่คอมโพเนนต์ได้รับจริงๆ - เช่น .card ในกริดที่มีขนาด 300px บนหน้าจอขนาด 1920px คำตอบที่ได้จาก container queries ขึ้นอยู่กับขนาดพาเรนต์ของคอมโพเนนต์ ไม่ใช่ขนาด viewport ดังนั้นคอมโพเนนต์จะปรับตัวตามพื้นที่ที่มีจริงแทนที่จะถูกบังคับให้ใช้สไตล์ที่เหมาะกับหน้าจอโดยรวม
ใช้งานระดับ "micro" สำหรับคอมโพเนนต์
มองให้ชัดว่า media queries เหมาะกับการเปลี่ยนแปลงโครงสร้างระดับหน้า ส่วน container queries เหมาะกับการปรับรูปแบบภายในคอมโพเนนต์ - card, widget, form, navigation เป็นต้น ตัวอย่างง่ายๆ คือ typography ที่เคยใช้ vw/vh กับ media queries จะได้ผลดีเมื่ออ้างอิงกับหน้าจอทั้งหมด แต่เมื่อย้ายคอมโพเนนต์ไปอยู่ใน sidebar หรือคอนเท็กซ์อื่น ตัวอักษรอาจใหญ่เกินไปหรือเล็กเกินไป
container queries มีหน่วยเฉพาะเช่น cqi, cqw, cqb ซึ่งเมื่อจับคู่กับฟังก์ชัน clamp() จะทำให้ typography ยืดหยุ่นตามขนาดคอนเทนเนอร์จริงๆ แทนที่จะยืดตาม viewport
เทคนิคกับ Flexbox - ลดการพึ่งพา JavaScript
ข้อจำกัดของ CSS ก่อนหน้านี้คือไม่สามารถตรวจจับว่า flex item ถูก wrap หรือไม่โดยตรง จึงมักต้องใช้ JavaScript เช่น ResizeObserver หากจะจัดสไตล์เมื่อรายการถูก wrap แต่ด้วย container queries เราสามารถใช้เทคนิคให้ flex-item เป็น container และตั้ง flex-grow: 1 จากนั้นเมื่อพาเรนต์มีพื้นที่จำกัดที่ทำให้รายการ wrap ขึ้นมา พาเรนต์จะขยายความกว้างของไอเทมที่ถูก wrap แล้ว container query ภายในไอเทมจะทำงานและเปลี่ยนสไตล์โดยไม่ต้องพึ่ง JS
ข้อควรระวัง
- ต้องมี wrapper เพิ่ม - container ต้องเป็นองค์ประกอบคนละตัวที่ถูกประกาศเป็น container; เราไม่สามารถ query องค์ประกอบเดียวกันได้โดยตรง
- แม้จะทรงพลัง แต่ก็ต้องออกแบบให้เหมาะกับโครงสร้างคอมโพเนนต์ เพื่อหลีกเลี่ยงผลข้างเคียงที่ไม่คาดคิด
- ยังมี container style queries แบบตอบสนองตาม computed styles ซึ่งยังถือว่า experimental ในเวลานี้
โดยสรุป container queries ไม่ใช่ทดแทน media queries แต่เป็นเครื่องมือเสริมที่คนทำเว็บควรแยกความหมาย - ใช้ media queries สำหรับเลย์เอาต์ระดับหน้า และใช้ container queries เพื่อให้คอมโพเนนต์ตอบสนองได้อย่างแม่นยำตามพื้นที่ที่ได้รับจริง
สำหรับนักพัฒนา front-end ในไทย นี่คือช่วงเวลาที่ควรทดลองออกแบบคอมโพเนนต์แบบ component-first และปรับกระบวนการให้คำนึงถึงขนาดคอนเทนเนอร์เป็นหลัก เพราะโลกเว็บมีขนาด viewport ที่หลากหลาย - มีมากกว่า 2,300 ขนาดที่แตกต่างกัน - การพึ่งพา viewport เพียงอย่างเดียวไม่เพียงพออีกต่อไป
ที่มา: Smashing Magazine - เรียบเรียงและสรุปเป็นภาษาไทยโดยทีมงาน IT Genius
ไอทีจีเนียส เอ็นจิเนียริ่ง (IT Genius Engineering) ให้บริการด้านไอทีครบวงจร ทั้งงานด้านการอบรม (Training) สัมมนา รับงานเขียนโปรแกรม เว็บไซต์ แอพพลิเคชั่น งานออกแบบกราฟิก และงานด้าน E-Marketing ที่กำลังได้รับความนิยมในปัจจุบัน ทั้ง SEO , PPC , และ Social media marketting
ติดต่อเราเพื่อสอบถามผลิตภัณฑ์ ขอราคา หรือปรึกษาเรื่องไอที ได้เลยค่ะ
Line : @itgenius (มี @ ด้านหน้า) หรือ https://lin.ee/xoFlBFeFacebook : https://www.facebook.com/itgeniusonline
Tel : 02-570-8449 มือถือ 088-807-9770 และ 092-841-7931
Email : contact@itgenius.co.th
แนะนำหลักสูตรอบรมที่น่าสนใจ
Basic HTML5 and CSS3 (คอร์ส html 5 และ css 3 พื้นฐาน)
ในการเรียน html5 และ css3 นับเป็นเทคโนโลยีการพัฒนาเว็...
Advanced HTML5 and CSS3
หลักสูตรนี้จะเจาะลึกการใช้งาน HTML5 และ CSS3 ในขั้นสูง ผู้เรียนจะต้องมีความเข้าใจในการเ...
Basic Responsive Web Design
หลักสูตร สำหรับผู้ที่จะเรียนรู้หลักการออกแบบบนหน้าจอขนาดต่าง ๆ และนำไปประยุกต์สร้างเว็บ...
Basic JavaScript
หลักสูตร Basic JavaScript นี้ถูกออกแบบมาเพื่อให้ผู้เรียนได้เรียนรู้พื้นฐานของภาษา JavaS...
คำค้นหา : Container QueriesMedia QueriesResponsive DesignFlexboxCSS Units





