ไวยากรณ์ที่กําหนดไว้ล่วงหน้า

องค์ประกอบ <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> จะใช้พื้นที่มากกว่าขนาดของวิวพอร์ต

หากฟังดูคลุมเครือสักเล็กน้อย เหตุผลที่ดีก็คือ การสนทนาเกี่ยวกับมาตรฐานของเว็บเหล่านี้ยังคงดำเนินต่อไป แต่ยังคงไม่เป็นที่เรียบร้อย คุณ ยังใช้แอปเหล่านั้นไม่ได้

แม้ว่ามาร์กอัปรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์จะทำงานได้ง่ายขึ้นเมื่อเวลาผ่านไป เช่นเดียวกับเทคโนโลยีเว็บอื่นๆ บริการ เทคโนโลยี และกรอบการทำงานต่างๆ เพื่อช่วยลดภาระในการเขียนมาร์กอัปที่มี ในโมดูลถัดไป เราจะมาดูวิธีผสานรวมทุกอย่างที่ได้เรียนรู้เกี่ยวกับรูปแบบรูปภาพ การบีบอัด และรูปภาพที่ตอบสนองตามอุปกรณ์เข้ากับเวิร์กโฟลว์การพัฒนาที่ทันสมัย