องค์ประกอบ <picture> จะไม่แสดงผลใดๆ ด้วยตัวเอง แต่ทำหน้าที่เป็นเครื่องมือช่วยตัดสินใจสำหรับองค์ประกอบ <img> ภายในแทน ซึ่งจะบอกว่าจะแสดงผลอะไร <picture> เป็นไปตามแบบก่อนซึ่งองค์ประกอบ <audio> และ <video> กำหนดไว้แล้ว ซึ่งเป็นองค์ประกอบ Wrapper ที่มีองค์ประกอบ <source> แต่ละรายการ
<picture>
<source …>
<source …>
<img …>
</picture …>
<img> ภายในยังมีรูปแบบสำรองที่เชื่อถือได้สำหรับเบราว์เซอร์รุ่นเก่าที่ไม่รองรับรูปภาพที่ตอบสนองตามอุปกรณ์
ดังนี้ หากเบราว์เซอร์ของผู้ใช้ไม่รู้จักองค์ประกอบ <picture> ระบบก็จะไม่สนใจองค์ประกอบนั้น จากนั้นก็จะทิ้งองค์ประกอบ <source> ไปด้วย เนื่องจากเบราว์เซอร์จะจดจำองค์ประกอบเหล่านี้ไม่ได้เลย หรือไม่จะมีบริบทที่มีความหมายสำหรับองค์ประกอบดังกล่าวหากไม่มีพาเรนต์ <video> หรือ <audio>
แต่เบราว์เซอร์ทั้งหมดจะจดจำองค์ประกอบ <img> ภายในได้ และแหล่งที่มาที่ระบุไว้ใน src จะแสดงผลตามที่คาดไว้
รูปภาพ "กำกับศิลป์" ที่มี <picture>
การเปลี่ยนแปลงเนื้อหาหรือสัดส่วนภาพของรูปภาพตามขนาดของรูปภาพในหน้านั้น โดยทั่วไปจะเรียกว่ารูปภาพที่ปรับเปลี่ยนตาม "ศิลป์" srcset และ sizes ออกแบบมาให้ทำงานแบบมองไม่เห็น โดยสลับแหล่งที่มาตามที่เบราว์เซอร์ของผู้ใช้กำหนดได้อย่างลื่นไหล
แต่ก็มีบางครั้งที่คุณต้องการปรับเปลี่ยนแหล่งข้อมูลในเบรกพอยท์ต่างๆ เพื่อให้ไฮไลต์เนื้อหาได้ดียิ่งขึ้น ในลักษณะเดียวกับที่คุณปรับเลย์เอาต์หน้าเว็บ
ตัวอย่างเช่น รูปภาพส่วนหัวแบบเต็มความกว้างโดยมีโฟกัสตรงกลางขนาดเล็กอาจทำงานได้ดีในวิวพอร์ตขนาดใหญ่ ดังนี้
แต่เมื่อลดขนาดลงให้พอดีกับวิวพอร์ตขนาดเล็ก โฟกัสตรงกลางของรูปภาพอาจหายไป:
เรื่องของแหล่งที่มาของรูปภาพเหล่านี้เหมือนกัน แต่หากต้องการโฟกัสที่สิ่งที่ถ่ายนั้นให้ดีขึ้น คุณจะต้องให้สัดส่วนของแหล่งที่มาของรูปภาพเปลี่ยนแปลงตามเบรกพอยท์ เช่น การซูมที่แคบขึ้นตรงกลางรูปภาพ และรายละเอียดบางส่วนที่ขอบถูกครอบตัด
"การครอบตัด" ดังกล่าวทำได้ผ่าน CSS แต่ผู้ใช้จะขอข้อมูลทั้งหมดที่ประกอบขึ้นเป็นรูปภาพ แม้ว่าสุดท้ายแล้วจะไม่เคยเห็นก็ตาม
องค์ประกอบ source แต่ละรายการมีแอตทริบิวต์ที่กําหนดเงื่อนไขสำหรับการเลือก source ดังกล่าว ได้แก่ media ซึ่งยอมรับการค้นหาสื่อ และ type ที่ยอมรับประเภทสื่อ (ก่อนหน้านี้เรียกว่า "ประเภท MIME") ระบบจะเลือก <source> แรกในลำดับแหล่งที่มาให้ตรงกับบริบทการท่องเว็บปัจจุบันของผู้ใช้ และเนื้อหาของแอตทริบิวต์ srcset ใน source นั้นจะใช้เพื่อกำหนดตัวเลือกที่เหมาะสมสำหรับบริบทนั้น ในตัวอย่างนี้จะเลือก source แรกที่มีแอตทริบิวต์ media ซึ่งตรงกับขนาดวิวพอร์ตของผู้ใช้
<picture>
<source media="(min-width: 1200px)" srcset="wide-crop.jpg">
<img src="close-crop.jpg" alt="…">
</picture>
คุณควรระบุ img ภายในตามลำดับสุดท้ายเสมอ หากไม่มีองค์ประกอบ source ที่ตรงกับเกณฑ์ media หรือ type รูปภาพดังกล่าวจะทำหน้าที่เป็นแหล่งที่มา "เริ่มต้น" หากคุณใช้คำค้นหาสื่อ min-width รายการ คุณจะต้องมีแหล่งที่มาที่ใหญ่ที่สุดก่อน ตามที่เห็นในโค้ดก่อนหน้านี้ เมื่อใช้คิวรี่สื่อ max-width คุณควรใส่แหล่งที่มาที่เล็กที่สุดก่อน
<picture>
<source media="(max-width: 400px)" srcset="mid-bp.jpg">
<source media="(max-width: 800px)" srcset="high-bp.jpg">
<img src="highest-bp.jpg" alt="…">
</picture>
เมื่อเลือกแหล่งที่มาตามเกณฑ์ที่คุณระบุไว้ ระบบจะส่งแอตทริบิวต์ srcset ใน source ไปพร้อมกับ <img> ราวกับว่ามีการกำหนดแหล่งที่มานั้นด้วย <img> หมายความว่าคุณมีอิสระที่จะใช้ sizes เพื่อเพิ่มประสิทธิภาพให้แหล่งที่มาของรูปภาพที่มีอาร์ตเวิร์กที่เน้นอาร์ตเวิร์ก
<picture>
<source media="(min-width: 800px)" srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w">
<source srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w">
<img src="fallback.jpg" alt="…" sizes="calc(100vw - 2em)">
</picture>
แน่นอนว่ารูปภาพที่มีสัดส่วนอาจแตกต่างกันไปตามองค์ประกอบ <source> ที่เลือกไว้จะทำให้เกิดปัญหาด้านประสิทธิภาพ
<img> รองรับเฉพาะแอตทริบิวต์ width และ height เพียงรายการเดียว แต่การไม่ระบุแอตทริบิวต์เหล่านั้นอาจทำให้ประสบการณ์ของผู้ใช้แย่ลงที่วัดได้
เพื่อรองรับกรณีนี้ เหตุการณ์ที่เพิ่งเกิดขึ้นไม่นานแต่ได้รับการรองรับเป็นอย่างดี การเพิ่มข้อกำหนด HTML ทำให้สามารถใช้แอตทริบิวต์ height และ width ในองค์ประกอบ <source> ได้ ซึ่งจะลดการเปลี่ยนแปลงของเลย์เอาต์เช่นเดียวกับที่ทำใน <img> โดยมีการสำรองพื้นที่ที่เหมาะสมไว้ในเลย์เอาต์สำหรับองค์ประกอบ <source> ใดก็ตามที่เลือกไว้
<picture>
<source
media="(min-width: 800px)"
srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w"
width="1600"
height="800">
<img src="fallback.jpg"
srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w"
sizes="calc(100vw - 2em)"
width="1200"
height="750"
alt="…">
</picture>
โปรดทราบว่าการกำหนดทิศทางศิลปะนั้นสำคัญกว่าการตัดสินใจที่อิงตามขนาดวิวพอร์ต และควรคำนึงถึงกรณีที่กรณีเหล่านั้นส่วนใหญ่จัดการได้อย่างมีประสิทธิภาพมากกว่าเมื่อใช้ srcset/sizes ตัวอย่างเช่น การเลือกแหล่งที่มาของรูปภาพที่เหมาะกับรูปแบบสีที่ผู้ใช้ต้องการมีดังนี้
<picture>
<source media="(prefers-color-scheme: dark)" srcset="hero-dark.jpg">
<img srcset="hero-light.jpg">
</picture>
แอตทริบิวต์ type
แอตทริบิวต์ type ช่วยให้คุณใช้เครื่องมือตัดสินใจแบบคำขอรวมครั้งเดียวขององค์ประกอบ <picture> เพื่อแสดงเฉพาะรูปแบบรูปภาพให้กับเบราว์เซอร์ที่รองรับรูปแบบดังกล่าวเท่านั้น
ตามที่คุณได้เรียนรู้ในรูปแบบรูปภาพและการบีบอัด การเข้ารหัสที่เบราว์เซอร์ไม่สามารถแยกวิเคราะห์จะไม่ใช่ข้อมูลรูปภาพเสียอีก
ก่อนที่จะเปิดตัวองค์ประกอบ <picture> โซลูชันฟรอนท์เอนด์ที่ได้ผลดีที่สุดสำหรับการแสดงรูปแบบรูปภาพใหม่กำหนดให้เบราว์เซอร์ต้องขอและพยายามแยกวิเคราะห์ไฟล์ภาพก่อนตัดสินใจว่าจะนำไฟล์ดังกล่าวออกและโหลดไฟล์สำรองหรือไม่ ตัวอย่างที่พบบ่อยคือสคริปต์ตามบรรทัดต่อไปนี้
<img src="image.webp"
data-fallback="image.jpg"
onerror="this.src=this.getAttribute('data-fallback'); this.onerror=null;"
alt="...">
ด้วยรูปแบบนี้ คำขอสำหรับ image.webp จะยังคงทำในทุกเบราว์เซอร์ ซึ่งหมายถึงการโอนที่เสียเปล่าสำหรับเบราว์เซอร์ที่ไม่มีการรองรับ WebP เบราว์เซอร์ที่แยกวิเคราะห์การเข้ารหัส WebP ไม่ได้ในภายหลังจะทำให้เกิดเหตุการณ์ onerror และสลับค่า data-fallback เป็น src นับเป็นโซลูชันที่สูญเปล่า แต่แนวทางเช่นนี้เป็นเพียงตัวเลือกเดียว
ที่มีให้ในระบบฟรอนท์เอนด์ โปรดทราบว่าเบราว์เซอร์จะเริ่มขอรูปภาพก่อนที่สคริปต์ที่กำหนดเองจะมีโอกาสเรียกใช้หรือแม้แต่ถูกแยกวิเคราะห์ ดังนั้น เราจึงไม่สามารถดักจับกระบวนการนี้ได้
องค์ประกอบ <picture> ได้รับการออกแบบมาอย่างชัดเจนเพื่อหลีกเลี่ยงคำขอที่ซ้ำซ้อน แม้ว่าเบราว์เซอร์จะจดจำรูปแบบที่ไม่รองรับไม่ได้หากไม่ขอ แต่แอตทริบิวต์ type จะเตือนเบราว์เซอร์เกี่ยวกับการเข้ารหัสแหล่งที่มาล่วงหน้าเพื่อตัดสินใจว่าจะส่งคำขอหรือไม่
ในแอตทริบิวต์ type ให้ระบุประเภทสื่อ (เดิมเรียกว่าประเภท MIME)
ของแหล่งที่มาของรูปภาพที่ระบุในแอตทริบิวต์ srcset ของแต่ละ <source> ซึ่งจะทำให้เบราว์เซอร์มีข้อมูลทั้งหมดที่จำเป็นต้องระบุในทันทีว่าสามารถถอดรหัสตัวเลือกรูปภาพที่ได้จาก source โดยไม่ต้องส่งคำขอภายนอกใดๆ หรือไม่ หากระบบไม่รู้จักประเภทสื่อดังกล่าว <source> และผู้สมัครทั้งหมดจะถูกเพิกเฉย และเบราว์เซอร์ก็จะทำงานต่อ
<picture>
<source type="image/webp" srcset="pic.webp">
<img src="pic.jpg" alt="...">
</picture>
ในที่นี้ เบราว์เซอร์ที่รองรับการเข้ารหัส WebP จะจดจำ image/webp Media Type ที่ระบุในแอตทริบิวต์ type ขององค์ประกอบ <source> เลือก <source> นั้น และเนื่องจากเราให้ตัวเลือก <source> เพียงรายการเดียวใน srcset เพื่อสั่งให้ <img> ภายในส่งคำขอ โอน และแสดงผล pic.webp เบราว์เซอร์ที่ไม่มีการรองรับ WebP จะไม่สนใจ source และจะไม่มีวิธีการใดๆ ในทางตรงกันข้าม <img> จะแสดงผลเนื้อหาของ src ตามที่ทำมาตั้งแต่ปี 1992
คุณไม่จำเป็นต้องระบุองค์ประกอบ <source> รายการที่ 2 ด้วย type="image/jpeg" ที่นี่ คุณสามารถใช้การรองรับ JPEG แบบสากลได้
ไม่ว่าบริบทการเรียกดูของผู้ใช้จะเป็นอย่างไร ทั้งหมดนี้จะเกิดขึ้นด้วยการโอนไฟล์เพียงครั้งเดียว และไม่มีการใช้แบนด์วิดท์สิ้นเปลืองสำหรับแหล่งที่มาของภาพที่ไม่สามารถแสดงผลได้ ซึ่งก็เป็นสิ่งที่มองการณ์ไกล และเนื่องจากรูปแบบไฟล์จะใหม่และมีประสิทธิภาพมากกว่าจะมีประเภทสื่อเป็นของตัวเอง ซึ่ง picture จะช่วยให้คุณใช้ประโยชน์จากสิ่งเหล่านี้ได้เพราะไม่มี JavaScript ไม่ต้องใช้ทรัพยากร Dependency ฝั่งเซิร์ฟเวอร์ และใช้ความเร็วระดับ <img> ได้ทั้งหมด
อนาคตของรูปภาพที่ตอบสนองตามอุปกรณ์
รูปแบบมาร์กอัปทั้งหมดที่กล่าวถึงในที่นี้มีการยกระดับมาตรฐานอย่างมาก นั่นก็คือการเปลี่ยนแปลงฟังก์ชันของสิ่งที่เป็นที่ยอมรับและเป็นศูนย์กลางของอินเทอร์เน็ตเพราะ <img> ไม่ใช่เรื่องเล็กๆ และชุดปัญหาที่การเปลี่ยนแปลงเหล่านี้ตั้งเป้าไว้ก็แก้ไขได้อย่างมากมาย หากคุณเคยคิดว่ามีสิ่งที่ต้องปรับปรุงอีกมากกับรูปแบบมาร์กอัปเหล่านี้ คุณตอบถูกแล้ว ตั้งแต่ระยะเริ่มแรก มาตรฐานเหล่านี้มีไว้เพื่อเป็นรากฐานสำหรับเทคโนโลยีในอนาคตที่จะพัฒนาต่อไป
โซลูชันทั้งหมดเหล่านี้ต้องอาศัยมาร์กอัปเสมอ เพื่อให้รวมอยู่ในเพย์โหลดเริ่มต้นจากเซิร์ฟเวอร์และทันเวลาเพื่อให้เบราว์เซอร์ขอแหล่งที่มาของรูปภาพ ซึ่งเป็นข้อจำกัดที่ทำให้แอตทริบิวต์ sizes ไม่ถูกต้องที่ยอมรับไม่ได้
แต่เนื่องจากฟีเจอร์เหล่านี้เปิดตัวในแพลตฟอร์มเว็บ ก็ได้มีการนำเสนอวิธีเลื่อนคำขอรูปภาพแบบเนทีฟ
จะไม่มีการขอองค์ประกอบ <img> ที่มีแอตทริบิวต์ loading="lazy" จนกว่าจะทราบเลย์เอาต์ของหน้าเว็บ เพื่อเลื่อนคำขอสำหรับรูปภาพที่อยู่นอกวิวพอร์ตเริ่มต้นของผู้ใช้ไปจนกระทั่งกระบวนการแสดงผลหน้าเว็บภายหลัง ซึ่งอาจหลีกเลี่ยงคำขอที่ไม่จำเป็น เนื่องจากเบราว์เซอร์เข้าใจเลย์เอาต์หน้าเว็บในขณะที่มีการส่งคำขอเหล่านี้ จึงมีการเสนอแอตทริบิวต์ sizes="auto" เป็นส่วนเพิ่มเติมในข้อกำหนด HTML เพื่อจะได้ไม่ต้องทำงานบ้านให้แอตทริบิวต์ sizes ที่เขียนด้วยตนเองในกรณีเหล่านี้
นอกจากนี้ยังมีองค์ประกอบ <picture> เพิ่มเติมอีกเล็กน้อยในขณะนี้ เพื่อให้ตรงกับการเปลี่ยนแปลงที่น่าตื่นเต้นเป็นพิเศษกับวิธีที่เราจัดรูปแบบเลย์เอาต์หน้าเว็บ แม้ว่าข้อมูลวิวพอร์ตจะเป็นพื้นฐานเสียงสำหรับการตัดสินใจเกี่ยวกับเลย์เอาต์ระดับสูง แต่ก็ทำให้เราไม่สามารถใช้แนวทางการพัฒนาในระดับคอมโพเนนต์แบบเต็มได้ ซึ่งหมายถึงคอมโพเนนต์ที่สามารถวางลงในส่วนใดก็ได้ของเลย์เอาต์หน้าเว็บ โดยมีรูปแบบที่ตอบสนองต่อพื้นที่ที่คอมโพเนนต์ใช้อยู่ ข้อกังวลนี้นำไปสู่การสร้างการค้นหาคอนเทนเนอร์ ซึ่งเป็นวิธีการจัดรูปแบบองค์ประกอบตามขนาดของคอนเทนเนอร์ระดับบนสุด แทนที่จะเป็นวิวพอร์ตเพียงอย่างเดียว
แม้ว่าไวยากรณ์การค้นหาคอนเทนเนอร์มีความเสถียรเท่านั้น และการรองรับเบราว์เซอร์มีจํากัดมากในขณะที่เขียน การเพิ่มเทคโนโลยีเบราว์เซอร์ที่เปิดใช้ฟังก์ชันดังกล่าวจะทำให้องค์ประกอบ <picture> สามารถทำสิ่งต่างๆ ได้ นั่นก็คือแอตทริบิวต์ container ที่เป็นไปได้ซึ่งอนุญาตเกณฑ์การเลือก <source> ตามพื้นที่ที่ <img> ขององค์ประกอบ <picture> จะใช้พื้นที่ แทนที่จะใช้ตามขนาดของวิวพอร์ต
ถ้าฟังดูคลุมเครือเล็กน้อย ก็มีเหตุผลดีๆ นั่นก็คือ การสนทนาเรื่องมาตรฐานเว็บเหล่านี้ดำเนินไปอย่างต่อเนื่องแต่ยังไม่ชัดเจน นั่นเป็นเพราะปัจจุบันคุณยังไม่สามารถใช้งาน
แม้ว่ามาร์กอัปรูปภาพที่ตอบสนองตามอุปกรณ์จะทำงานได้ง่ายขึ้นเมื่อเวลาผ่านไป เช่นเดียวกับเทคโนโลยีเว็บอื่นๆ แต่ก็มีบริการ เทคโนโลยี และเฟรมเวิร์กจำนวนมากที่จะช่วยลดภาระในการเขียนมาร์กอัปด้วยลายมือที่มีอยู่มากมาย ในโมดูลถัดไป เราจะมาดูวิธีผสานรวมทุกอย่างที่ได้เรียนรู้เกี่ยวกับรูปแบบรูปภาพ การบีบอัด และรูปภาพที่ตอบสนองตามอุปกรณ์เข้ากับเวิร์กโฟลว์การพัฒนาสมัยใหม่