ในการทำ responsive web design หากพูดถึงการใช้รูปต่างๆ ในหน้าเว็บแล้ว เราอาจจะต้องเลือกใช้รูปขนาดใหญ่สุดเพื่อที่จะสามารถแสดงผลได้อย่างคมชัดบน desktop เเต่ด้วยข้อจำกัดของ responsive web design ทำให้เว็บในแต่ละเวอร์ชั่นนั้นจะใช้โค้ดร่วมกัน ไม่ว่าจะเป็น mobile, tablet หรือ desktop ก็ตาม ด้วยเหตุนี้เอง จึงทำให้เกิดปัญหาที่ว่า mobile อาจจะต้องมาโหลดรูปขนาดใหญ่โดยไม่จำเป็น หรือผู้ที่ใช้ retina display อาจจะพบว่ารูปที่โหลดมานั้นไม่คมชัดเท่าไรนัก เนื่องจากเป็นรูปที่ไม่ได้รองรับหน้าจอความละเอียดสูงนั่นเอง
ปัญหาเกี่ยวกับรูปใน responsive web นี้ กลายเป็นปัญหาสำคัญ จึงทำให้เกิดการแก้ปัญหาที่เรียกว่า “Adaptive images” ขึ้นมา โดยจุดประสงค์ก็คือ การทำให้ผู้ใช้งานโหลดเฉพาะรูปที่เหมาะสมกับสภาพแวดล้อมของผู้ใช้งานในขณะนั้นๆ แทนที่จะบังคับให้ผู้ใช้งานโหลดรูปขนาดใหญ่สุดไป แต่วิธีนี้นั้นค่อนข้างจะซับซ้อนและทำได้ยาก
ความเป็นมาของ Adaptive Images
adaptive images เริ่มต้นมาจากการที่มีนักพัฒนากลุ่มหนึ่ง เห็นความสำคัญของปัญหาที่ว่านี้ และพยายามรวมตัวกันเพื่อแก้ปัญหา พวกเขาได้แจ้งไปยัง WHATWG เพื่อทราบถึงแนวทางการแก้ไขปัญหาของพวกเขา ทาง WHATWG จึงเสนอว่าพวกเขาควรตั้งเป็นกลุ่มขึ้นมาเลย พวกเขาทำตามคำแนะนำของ WHATWG และใช้ชื่อกลุ่มว่า “Responsive Images Community Group (RICG)”
แนวทางการแก้ปัญหาของ RICG คือการเพิ่ม html element ที่มีชื่อว่า “picture” เข้ามา ซึ่ง picture element นี้ได้แรงบันดาลใจมาจาก markup ของ video tag นั่นเอง กระบวนการทำงานของ RICG นั้นเป็นไปตามขั้นตอนของการกำหนด specification มีการรวบรวมปัญหาต่างๆ ที่เป็นไปได้มาทั้งหมด แล้วดูว่า solution ของพวกเขาสามารถแก้ปัญหาเหล่านั้นได้หรือไม่
ในระหว่างที่ RICG ทำงานกันอยู่นั้น พนักงานของ Apple คนหนึ่งที่มีชื่อว่า Edward O’Connor ได้เสนอไอเดียของเขาต่อ WHATWG โดยตรง เขามองว่าการเพิ่ม attribute ที่ชื่อว่า srcset มาใช้กับ img element ดูจะเป็นทางเลือกที่ดีกว่าการใช้ picture element ของ RICG
ด้วยเหตุนี้เอง กลุ่มผู้เสนอไอเดียเกี่ยวกับ adaptive images จึงแบ่งออกเป็น 2 กลุ่ม developers(คนที่เขียนโค้ด) ส่วนใหญ่นั้นชอบวิธี picture element ส่วน implementors(คนที่นำ specifications ไปทำให้ใช้ได้กับ web browsers) กลับชอบวิธี srcset attribute มากกว่า
หลังจากนั้นไม่นาน WHATWG ซึ่งสมาชิกส่วนใหญ่เป็น implementors เลือกที่จะเพิ่ม srcset เข้าไปใน draft ของ specifications แทนที่จะเป็น picture element ของ RICG เหตุการณ์นี้สร้างความไม่พอใจให้แก่นักพัฒนาบางส่วนใน RICG เนื่องจากการเสนอไอเดียของ Edward O’Connor นั้นไม่เป็นไปตามกระบวนการเหมือนอย่างที่ RICG ได้ทำมาตั้งแต่แรก อย่างไรก็ตาม ทั้ง 2 solutions ต่างก็ได้มีการพัฒนามาอย่างต่อเนื่อง และได้ถูกเพิ่มเข้ามาใน draft ของ W3C ในที่สุด
Picture Element
อย่างที่ได้บอกไปแล้วว่า picture element ของ RICG นั้นได้แรงบันดาลใจมาจาก video element ซึ่ง RICG มองว่า pattern แบบนี้ authors(คนเขียนโค้ด) น่าจะคุ้นเคยกันเป็นอย่างดี จุดเด่นของ picture element ก็คือการรองรับ media queries ซึ่งนั่นก็หมายความว่าเราสามารถกำหนดเงื่อนไขของการเลือกรูปมาแสดงได้ด้วยตัวเอง นอกจากนี้ picture element ยังมี fallback สำหรับ web browsers ที่ยังไม่รองรับอีกด้วย ซึ่งเป็นหลักการเดียวกับ video element นั่นเอง
1 2 3 4 5 6 | <picture> <source media="(min-width: 45em)" src="large.jpg"> <source media="(min-width: 18em)" src="medium.jpg"> <source src="small.jpg"> <img src="small.jpg" alt=""> </picture> |
อย่างไรก็ดี picture element อาจจะมีปัญหาอยู่บ้างในเรื่องของ performance เนื่องจาก parser ของ web browsers จะต้องมาเสียเวลาหา </picture> ให้เจอเสียก่อน จึงจะสามารถคำนวณได้ว่าควรเลือกรูปไหนมาแสดง
Srcset Attribute
เรามาดูไอเดียของ Edward O’Connor กันบ้าง เขาเลือกที่จะใช้ adaptive images กับ img element เหมือนเดิม แทนที่จะสร้าง html element ขึ้นมาใหม่ เพียงแต่ว่าเขาเสนอให้เพิ่ม attribute เข้ามาอีกอันหนึ่ง ซึ่งก็คือ srcset นั่นเอง
1 2 3 4 5 6 7 | <img src="fallback.jpg" alt="" srcset=" low-resolution.jpg 1x, high-resolution.jpg 2x" > |
จากตัวอย่างการใช้ srcset attribute ด้านบน จะเห็นว่า srcset นั้นจะประกอบไปด้วยรูปเวอร์ชั่นต่างๆ ที่เราได้เตรียมไว้ โดยจะมี comma คั่นอยู่ จุดเด่นของ srcset attribute ก็คือเราจะสามารถใส่ “hint(คำใบ้)” ให้กับแต่ละเวอร์ชั่นได้ด้วยว่าเราอยากให้ web browsers เลือกรูปนี้มาแสดงเมื่อใด
hint ของ srcset attribute นั้นมีอยู่ 3 แบบ ด้วยกัน คือ w, h และ x โดย x นั้นจะหมายถึง pixel density ของ device นั้นๆ นั่นเท่ากับว่า เราสามารถเลือกแสดงรูปให้เหมาะสมกับหน้าจอความคมชัดสูงอย่าง retina display ได้แล้ว
ส่วน w กับ h นั้นจะหมายถึงขนาดของ viewport ที่ใหญ่ที่สุด หรือ max-width และ max-height นั่นเอง ลองดูตัวอย่างต่อไปนี้
1 2 3 4 5 6 7 8 | <img src="fallback.jpg" alt="" srcset=" show@0-720.jpg 720w, show@721-1280.jpg 1280w, show@1281+.jpg 1x" > |
จากตัวอย่างด้านบนจะเห็นว่า hint แบบ w นั้นจะอ้างอิงกับ max-width ไม่ใช่ min-width โดยรูปขนาดใหญ่ที่สุดที่เราจะใช้กับ infinite width นั้นให้เราใส่ hint เป็น 1x ซึ่ง web browsers จะรู้เองว่ามันควรใช้รูปนี้มาแสดงผล หาก viewport มีความกว้างมากกว่า 1280 px
บางคนอาจสงสัยว่า w กับ h นั้นสามารถกำหนดให้เป็นหน่วย em ได้หรือไม่ ? คำตอบคือ “ไม่ได้” เหตุผลก็คือ em นั้นเป็นหน่วยในมุมมองของ authors ซึ่งสุดท้ายแล้ว สิ่งที่ web browsers เข้าใจจริงๆ ก็คือ px อยู่ดี
จะเห็นว่า srcset attribute นั้นมีข้อดีตรงที่เราไม่ต้องมาเขียน query เองว่าจะเลือกรูปไหนมาแสดงผล เราเพียงแต่ใส่ hint เข้าไปเท่านั้น ที่เหลือก็ปล่อยให้ web browsers ตัดสินใจเองว่าจะเลือกรูปไหนมาใช้ ซึ่งมันจะเลือกรูปที่ “เหมาะสม” ที่สุดในสภาพแวดล้อมนั้นๆ มาแสดงโดยอัตโนมัติ โดยมันจะดูจากปัจจัยหลายๆ อย่าง ไม่ว่าจะเป็น network speed, latency รวมไปถึง orientation
ทำไมต้องมีทั้ง picture element และ srcset attribute ?
คำตอบง่ายๆ เลยก็คือ ทั้ง 2 solutions ต่างก็ยังไม่สามารถตอบโจทย์ของ adaptive images ได้ครบในทุกๆ use cases บ่อยครั้งที่เราพบว่ารูปใน mobile นั้นเล็กจนดูไม่รู้เรื่อง ทั้งนี้เป็นเพราะว่าคนส่วนใหญ่จะลดขนาดของรูปลงให้สัมพันธ์กับขนาดของหน้าจอ พวกเขาอาจลืมไปว่าในบางครั้ง จุดโฟกัสนั้นไม่ได้อยู่ที่กึ่งกลางของรูป การกำหนดขนาดของรูปให้เป็น % โดยอิงตาม container นั้นอาจทำให้ใจความสำคัญของรูปเสียไป หรืออาจเล็กลงมากจนดูไม่รู้เรื่องเมื่อดูในหน้าจอขนาดเล็ก
Art Direction by Responsive Images Community Group (RICG)
“Art Direction” คือการจัดเตรียมรูปที่เหมาะสมกับขนาดหน้าจอต่างๆ เอาไว้ โดยรูปนั้นอาจจะใช้การ crop จากรูปขนาดดั้งเดิม เพื่อให้ใจความสำคัญของรูปยังคงอยู่ครบถ้วนแม้ว่าจะดูด้วยหน้าจอขนาดเล็กก็ตาม เราลองมาดูว่า picture element และ srcset attribute จะสามารถจัดการกับ use case นี้ได้อย่างไร ?
1 2 3 4 5 6 | <picture> <source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x"> <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x"> <source srcset="small-1.jpg 1x, small-2.jpg 2x"> <img src="small-1.jpg" alt=""> </picture> |
จากโค้ดด้านบน เราใช้ picture element เข้ามาช่วยในการเลือกเวอร์ชั่นของภาพที่เรา crop ไว้ มาใช้ให้เหมาะกับหน้าจอขนาดต่างๆ ส่วน srcset นั้น เราจะเอามาใช้กับการเลือกภาพให้เหมาะสมกับ pixel density ของ device นั้นๆ จะเห็นว่า picture element นั้น เหมาะอย่างยิ่งในการทำ art direction อย่างไรก็ตาม หากไม่มี srcset attribute แล้วล่ะก็ ประสิทธิภาพของ art direction ก็คงจะลดลงไป และนี่เองคือเหตุผลที่ทั้ง 2 solutions นี้ถูกเพิ่มเข้ามาใน specifications
บางคนอาจสงสัยว่า media queries ก็สามารถระบุ device-pixel-ratio ได้นี่ ทำไมถึงต้องมาใช้ srcset ด้วย ? เหตุผลก็คืออุปกรณ์ที่มี device-pixel-ratio มากกว่า 1 นั้นมักจะเป็นพวก mobile ซึ่งอาจจะมีความเร็วในการเชื่อมต่อ internet ไม่มากนัก การใช้ srcset แทน media queries นั้นมีข้อดีตรงที่เราจะปล่อยให้ web browsers ตัดสินใจเองได้ว่า users คนนั้นๆ ควรจะได้รูปเวอร์ชั่นไหนไป หากเค้าใช้ retina display แต่เค้าใช้ internet ความเร็วแค่ 56K สู้เอารูปเวอร์ชั่นความคมชัด 1 เท่าไปดีกว่า แม้อาจจะมัวบ้างนิดหน่อย แต่ก็ใช้เวลาโหลดน้อยกว่ามาก อย่าลืมว่ารูปเวอร์ชั่นความคมชัด 2 เท่านั้น ขนาดของไฟล์อาจจะใหญ่กว่าถึง 4 เท่า เนื่องจากขนาดของมันจะคูณ 2 ทั้งความกว้างและความสูง
บางคนคิดต่อว่า srcset attribute ก็ทำ art direction ได้นี่ เพราะมันก็มี hint w, h ถูกครับ มันทำได้ แต่มันจะไม่แน่นอนเหมือนกับการใช้ picture element ที่เราจะเป็นคนกำหนดเองได้เลย ไม่ใช่ปล่อยให้ web browsers กำหนด ซึ่งเราจะไม่สามารถการันตีได้ว่า users จะได้รับภาพที่เราตั้งใจจะให้เขาไปจริงๆ
เหตุผลอีกข้อที่นิยมใช้ picture element ทำ art direction ก็คือ หลายๆ คน ทำ responsive web โดยยึดหลึก Mobile-First(min-width) ซึ่งถ้าเราใช้ srcset attribute แล้วล่ะก็ เราจะต้องเขียน hint โดยยึดหลัก Desktop-First(max-width) ทำให้ breakpoints นั้นจะไม่ตรงกัน แต่ถ้าหากเราใช้ picture element แล้วล่ะก็ เราสามารถใช้ media queries ได้เลย ไม่ว่าจะยึดหลักอะไรก็ไม่มีปัญหา
Adaptive Images สามารถใช้ได้จริงแล้วหรือยัง ?
ล่าสุด webkit ได้นำ srcset attribute ไป implement แล้ว ส่วน picture element นั้นยังคงต้องพึ่ง polyfill ไปก่อน บางคนอาจจะบ่นว่า ทำไมกว่า web browsers ทั้งหมดจะรองรับอะไรใหม่ๆ นั้นใช้เวลานานจัง ทำไมเค้าไม่ทำกันไวๆ คำตอบคือ กว่า solution จะกลายมาเป็น specification นั้น ผู้ร่วมเสนอ solution จะต้องใช้ความคิดกันอย่างมาก พูดง่ายๆ คือ พวกเขาต้องคิดแล้วคิดอีก เพราะสิ่งที่จะเป็น specification นั้นหมายความว่ามันจะถูกนำไปใช้กับคนทั้งโลก เมื่อ specification กลายเป็น “recommendation” แล้ว web browsers ต่างๆ ก็จะนำไป implement อีกที
จริงๆ แล้ว กลุ่มคนที่ช่วยกันกำหนด specifications เหล่านี้ไม่ได้เป็นคนใหญ่คนโตอะไรเลย พวกเขาก็เหมือนนักพัฒนาอย่างเราๆ นี่แหละ เพียงแต่ว่าเวลาเขาเจอปัญหาแล้วเขาไม่นิ่งเฉย เขาพยายามแก้ปัญหา เราแค่รอเอาไปใช้จะบ่นไปทำไม สู้เอาเวลาไปช่วยพวกเค้าเขียน specification ยังจะดีเสียกว่า หรือไม่จริง ?