องค์ประกอบ <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 ที่ระบุในแอตทริบิวต์ type
ขององค์ประกอบ <source> ให้เลือก <source> นั้น และเนื่องจากเราได้ระบุคำที่แนะนำไว้เพียงตัวเดียวใน srcset ทำให้คำแนะนำภายใน
<img> เพื่อร้องขอ โอน และแสดงผล pic.webp เบราว์เซอร์ที่ไม่มีการรองรับ WebP จะไม่สนใจ source และ
ถ้าไม่มีคำสั่งใดๆ ในทางตรงกันข้าม <img> จะแสดงผลเนื้อหาของ src ตามที่ดำเนินการมาตั้งแต่ปี 1992
คุณไม่จำเป็นต้องระบุองค์ประกอบ <source> รายการที่ 2 ด้วย type="image/jpeg" ที่นี่ เนื่องจากคุณจะรองรับรูปแบบ JPEG โดยรวมได้
ไม่ว่าผู้ใช้จะใช้บริบทการท่องเว็บแบบใด ทั้งหมดนี้ทำได้ด้วยการโอนไฟล์เพียงครั้งเดียว และไม่เปลืองแบนด์วิดท์
แหล่งที่มาของรูปภาพที่แสดงผลไม่ได้ นี่ยังเป็นการมองไปข้างหน้า รวมถึงรูปแบบไฟล์ใหม่ที่มีประสิทธิภาพมากกว่าที่จะเพิ่มเข้ามา
ประเภทสื่อของตัวเอง เราจะใช้ประโยชน์จาก picture ได้โดยไม่ต้องใช้ JavaScript และฝั่งเซิร์ฟเวอร์
และความเร็วทั้งหมดของ <img>
อนาคตของรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์
รูปแบบมาร์กอัปทั้งหมดที่พูดถึงในที่นี้มีการปรับปรุงอย่างมากในแง่ของการกำหนดมาตรฐาน นั่นคือ การเปลี่ยนฟังก์ชันการทำงานของ
เป็นสิ่งที่เป็นที่รู้จักและเป็นศูนย์กลางของเว็บเนื่องจาก <img> ไม่ใช่เรื่องเล็กๆ และกลุ่มปัญหาของการเปลี่ยนแปลงเหล่านี้
การแก้ไขนั้นครอบคลุมมาก หากคุณคิดว่ายังมีสิ่งที่ต้องปรับปรุงอีกมากเมื่อใช้ฟีเจอร์เหล่านี้
รูปแบบมาร์กอัปที่คุณพูดถูกแน่นอน มาตรฐานเหล่านี้มีไว้เพื่อเป็นพื้นฐานสำหรับอนาคตตั้งแต่แรกเริ่ม
ที่จะต่อยอดต่อไป
โซลูชันทั้งหมดเหล่านี้ขึ้นอยู่กับมาร์กอัปเสมอ เพื่อที่จะได้รวมอยู่ในเพย์โหลดเริ่มต้นจากเซิร์ฟเวอร์
และก่อนที่เบราว์เซอร์จะขอแหล่งที่มาของรูปภาพ ซึ่งเป็นข้อจำกัดที่ทำให้แอตทริบิวต์ sizes ใช้งานไม่ได้
อย่างไรก็ตาม เนื่องจากฟีเจอร์เหล่านี้เปิดตัวในแพลตฟอร์มเว็บ จึงได้มีการแนะนำวิธีเลื่อนเวลาคำขอรูปภาพแบบเนทีฟ
ระบบจะไม่ขอองค์ประกอบ <img> ที่มีแอตทริบิวต์ loading="lazy" จนกว่าจะทราบเลย์เอาต์ของหน้าเพื่อเลื่อนเวลา
คำขอรูปภาพนอกวิวพอร์ตเริ่มต้นของผู้ใช้จนถึงขั้นตอนการแสดงผลหน้าเว็บในภายหลัง ซึ่งอาจหลีกเลี่ยง
คำขอที่ไม่จำเป็น เนื่องจากเบราว์เซอร์เข้าใจการจัดวางหน้าเว็บในขณะที่ส่งคำขอเหล่านี้
มีการเสนอแอตทริบิวต์ sizes="auto" เป็นส่วนเพิ่มเติมจากข้อกำหนด HTML
เพื่อหลีกเลี่ยงความยุ่งยากของแอตทริบิวต์ sizes ที่เขียนด้วยตนเองในกรณีเหล่านี้
นอกจากนี้ยังมีการเพิ่มองค์ประกอบ <picture> บนเส้นขอบฟ้าด้วยเพื่อให้ตรงกับการเปลี่ยนแปลงที่น่าตื่นเต้นเป็นพิเศษ
ไปจนถึงวิธีที่เราออกแบบเลย์เอาต์หน้าเว็บ แม้ว่าข้อมูลวิวพอร์ตจะเป็นพื้นฐานที่ชัดเจนสำหรับการตัดสินใจเรื่องเลย์เอาต์ในระดับสูง
ทำให้เราไม่สามารถใช้แนวทางระดับคอมโพเนนต์ในการพัฒนา กล่าวคือคอมโพเนนต์ที่อาจถูกนำไปใช้ในการพัฒนา
ส่วนใดส่วนหนึ่งของเลย์เอาต์หน้าเว็บ โดยมีรูปแบบที่ตอบสนองต่อพื้นที่ว่างที่คอมโพเนนต์ใช้อยู่ ความกังวลนี้ทำให้
การสร้างการค้นหาคอนเทนเนอร์ ซึ่งเป็นวิธีการจัดรูปแบบองค์ประกอบ
โดยอิงตามขนาดคอนเทนเนอร์ระดับบนสุด ไม่ใช่วิวพอร์ตเพียงอย่างเดียว
แม้ว่าไวยากรณ์การค้นหาของคอนเทนเนอร์เพิ่งเสถียร และการรองรับเบราว์เซอร์มีข้อจำกัดอย่างมาก
ในขณะที่เขียน การเพิ่มเติมของเทคโนโลยีเบราว์เซอร์ที่เปิดใช้งานจะทำให้องค์ประกอบ <picture> ที่มี
วิธีการทำสิ่งเดียวกัน: แอตทริบิวต์ container ที่เป็นไปได้ที่ช่วยให้มีเกณฑ์การเลือก <source> ตาม
พื้นที่ที่ <img> ขององค์ประกอบ <picture> จะใช้พื้นที่มากกว่าขนาดของวิวพอร์ต
หากฟังดูคลุมเครือสักเล็กน้อย เหตุผลที่ดีก็คือ การสนทนาเกี่ยวกับมาตรฐานของเว็บเหล่านี้ยังคงดำเนินต่อไป แต่ยังคงไม่เป็นที่เรียบร้อย คุณ ยังใช้แอปเหล่านั้นไม่ได้
แม้ว่ามาร์กอัปรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์จะทำงานได้ง่ายขึ้นเมื่อเวลาผ่านไป เช่นเดียวกับเทคโนโลยีเว็บอื่นๆ บริการ เทคโนโลยี และกรอบการทำงานต่างๆ เพื่อช่วยลดภาระในการเขียนมาร์กอัปที่มี ในโมดูลถัดไป เราจะมาดูวิธีผสานรวมทุกอย่างที่ได้เรียนรู้เกี่ยวกับรูปแบบรูปภาพ การบีบอัด และรูปภาพที่ตอบสนองตามอุปกรณ์เข้ากับเวิร์กโฟลว์การพัฒนาที่ทันสมัย