ไวยากรณ์ที่สื่อความหมาย

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

นี่เป็นคำขอที่สำคัญมาก และแน่นอนว่ามากกว่าที่เราอยากจะพิจารณาเมื่อเรามาร์กอัปรูปภาพสำหรับเว็บ และการทำอย่างเหมาะสมนั้นเกี่ยวข้องกับ ข้อมูลที่เราจะเข้าถึงได้

กำลังอธิบายความหนาแน่นด้วย x

<img> ที่มีความกว้างคงที่จะใช้วิวพอร์ตจำนวนเท่ากันในทุกบริบทการท่องเว็บ โดยไม่คำนึงถึงความหนาแน่นของผู้ใช้ จอแสดงผล — จำนวนพิกเซลจริงที่ทำให้หน้าจอแสดง ตัวอย่างเช่น รูปภาพที่มีความกว้างแฝง 400px จะใช้พื้นที่เกือบ วิวพอร์ตของเบราว์เซอร์ทั้งหน้าใน Google Pixel รุ่นเดิมและ Pixel 6 Pro รุ่นใหม่กว่า อุปกรณ์ทั้ง 2 เครื่องมี 412px มาตรฐาน วิวพอร์ตแบบกว้างสำหรับตรรกะพิกเซล

Pixel 6 Pro มีจอแสดงผลคมชัดกว่ามาก แต่ 6 Pro มีความละเอียดจริง 1440 × 3120 พิกเซล ขณะที่ พิกเซลจะมีขนาด 1080 × 1920 พิกเซล คือจำนวนพิกเซลของฮาร์ดแวร์ที่ประกอบขึ้นเป็นหน้าจอ

อัตราส่วนระหว่างพิกเซลเชิงตรรกะของอุปกรณ์กับพิกเซลจริงคืออัตราส่วนพิกเซลของอุปกรณ์สําหรับจอแสดงผลนั้น (DPR) DPR คือ คำนวณโดยการหารความละเอียดหน้าจอจริงของอุปกรณ์ด้วยพิกเซล CSS ของวิวพอร์ต

DPR 2 รายการแสดงในหน้าต่างคอนโซล

Pixel รุ่นเดิมมีค่า DPR 2.6 ขณะที่ Pixel 6 Pro มี DPR อยู่ที่ 3.5

iPhone 4 ซึ่งเป็นอุปกรณ์เครื่องแรกที่มี DPR สูงกว่า 1 รายงานอัตราส่วนพิกเซลของอุปกรณ์เป็น 2 หรือความละเอียดจริงของหน้าจอเท่ากับ ความละเอียดเชิงตรรกะเป็น 2 เท่า อุปกรณ์ก่อนหน้า iPhone 4 มี DPR เท่ากับ 1: 1 พิกเซลตรรกะต่อพิกเซลจริง 1 รายการ

ถ้าคุณดูรูปภาพขนาด 400px รูปบนจอแสดงผลที่มี DPR เป็น 2 พิกเซลตรรกะแต่ละพิกเซลจะแสดงผลใน 4 จาก พิกเซลจริงของจอแสดงผล: 2 แนวนอนและ 2 แนวตั้ง ภาพที่ได้จะไม่ได้รับประโยชน์จากจอแสดงผลความหนาแน่นสูง แต่จะดูเหมือน เช่นเดียวกับที่แสดงบนจอแสดงผลที่มี DPR เป็น 1 แน่นอนว่าอะไรก็ตามที่ "วาด" โดยใช้เครื่องมือการแสดงผลของเบราว์เซอร์ เช่น ข้อความ รูปร่าง CSS หรือ SVG เช่น จะวาดให้เหมาะกับหน้าจอที่มีความหนาแน่นสูงกว่า แต่ดังที่คุณได้เรียนรู้จากรูปแบบรูปภาพและการบีบอัด รูปภาพแรสเตอร์ได้รับการแก้ไขแล้ว ตารางพิกเซล แม้ว่าอาจจะไม่เห็นได้ชัดเจนอยู่แล้ว แต่รูปภาพแรสเตอร์ที่ปรับคุณภาพให้เหมาะสำหรับจอแสดงผลความหนาแน่นสูง ความละเอียดต่ำเมื่อเทียบกับหน้าโดยรอบ

รูปภาพที่แสดงผลต้องมีความกว้างภายในอย่างน้อย 800 พิกเซลเพื่อป้องกันไม่ให้เกิดการเพิ่มขนาดดังกล่าว เมื่อปรับขนาดลง เพื่อให้พอดีกับช่องว่างในการจัดวางที่มีความกว้าง 400 พิกเซลตรรกะ แหล่งที่มาของภาพ 800 พิกเซลดังกล่าวมีความหนาแน่นของพิกเซลเป็น 2 เท่าในจอแสดงผลที่มี DPR เป็น 2 ก็จะดูดีและคมชัด

ภาพระยะใกล้ของกลีบดอกไม้ที่แสดงความหนาแน่นของความไม่เท่ากัน

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

ตามที่คุณได้เรียนรู้ในหัวข้อรูปภาพและประสิทธิภาพ ผู้ใช้ที่มีการแสดงผลความหนาแน่นต่ำดูแหล่งที่มาของรูปภาพลดขนาดเป็น 400px จะต้องการเฉพาะแหล่งที่มาที่มีความกว้างแฝง 400px เท่านั้น แม้รูปภาพที่ใหญ่ขึ้นมากจะดูได้ดีสำหรับผู้ใช้ทุกคน แหล่งที่มาของรูปภาพความละเอียดสูงที่แสดงผลในจอแสดงผลความหนาแน่นต่ำจะมีลักษณะเหมือนรูปภาพขนาดเล็กที่มีความหนาแน่นต่ำอื่นๆ แต่จะรู้สึกว่าช้ากว่ามาก

คุณคงเดาได้ว่าอุปกรณ์เคลื่อนที่ที่มี DPR เท่ากับ 1 นั้นหายากอย่างสิ้นเชิง แม้ว่าจะยังพบได้ทั่วไปใน "เดสก์ท็อป" บริบทการท่องเว็บ ตามข้อมูล แชร์โดย Matt Hobbs ประมาณ 18% ของเซสชันการท่องเว็บใน GOV.UK จากเดือนพฤศจิกายน 2022 รายงาน DPR อยู่ที่ 1 ถึงแม้ว่ารูปภาพความหนาแน่นสูงจะดูตามที่ผู้ใช้คาดหวังไว้ แต่รูปภาพความหนาแน่นสูงจะมีแบนด์วิดท์และต้นทุนในการประมวลผลสูงกว่ามาก ข้อกังวลบางอย่างสำหรับผู้ใช้ที่ใช้อุปกรณ์รุ่นเก่าที่มีประสิทธิภาพสูง แต่มีแนวโน้มที่จะมีจอแสดงผลความหนาแน่นต่ำ

การใช้ srcset จะช่วยให้มั่นใจได้ว่าเฉพาะอุปกรณ์ที่มีจอแสดงผลความละเอียดสูงเท่านั้นที่จะได้รับแหล่งที่มาของรูปภาพที่มีขนาดใหญ่พอที่จะดูคมชัดโดยไม่ต้องส่งผ่านค่าเดียวกันนั้น ต้นทุนแบนด์วิดท์สำหรับผู้ใช้ที่มีจอแสดงผลความละเอียดต่ำ

แอตทริบิวต์ srcset ระบุตัวเลือกที่คั่นด้วยคอมมาอย่างน้อย 1 รายการสำหรับการแสดงผลรูปภาพ ผู้สมัครรับเลือกตั้งแต่ละคนประกอบด้วย มี 2 รายการ ได้แก่ URL เหมือนที่คุณใช้ใน src และไวยากรณ์ที่อธิบายแหล่งที่มาของรูปภาพนั้น ผู้สมัครแต่ละคนในsrcset ได้รับการอธิบายโดยใช้ความกว้างที่แท้จริง ("ไวยากรณ์ w") หรือความหนาแน่นตามที่กำหนดไว้ ("ไวยากรณ์ x")

ไวยากรณ์ x เป็นคำย่อสำหรับ "แหล่งที่มานี้เหมาะสำหรับการแสดงผลที่มีความหนาแน่นนี้" - คำที่แนะนำที่ตามด้วย 2x คือ เหมาะสำหรับจอแสดงผลที่มี DPR เป็น 2

<img src="low-density.jpg" srcset="double-density.jpg 2x" alt="...">

เบราว์เซอร์ที่รองรับ srcset จะแสดงตัวเลือก 2 รายการ ได้แก่ double-density.jpg ซึ่ง 2x อธิบายไว้ตามความเหมาะสม สำหรับจอแสดงผลที่มี DPR เป็น 2 และ low-density.jpg ในแอตทริบิวต์ src ซึ่งเป็นตัวเลือกที่เลือกหากไม่มีความเหมาะสมมากกว่า พบใน srcset สำหรับเบราว์เซอร์ที่ไม่รองรับ srcset ระบบจะไม่สนใจแอตทริบิวต์และเนื้อหาของแอตทริบิวต์ดังกล่าว - เนื้อหาของ src ตามปกติ

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

ความแตกต่างระหว่างไวยากรณ์ที่ระบุว่า "แหล่งที่มานี้เหมาะสำหรับจอแสดงผล 2x" และอีกรายการที่ระบุว่า "ใช้แหล่งที่มานี้บนจอแสดงผล 2x" ความหนาแน่นของการแสดงผลเล็กน้อย แต่ความหนาแน่นของการแสดงผลเป็นเพียงหนึ่งในปัจจัยจำนวนมากที่เชื่อมโยงกัน ที่เบราว์เซอร์ใช้ในการพิจารณาผู้สมัคร เพื่อแสดงผล เฉพาะบางส่วนที่คุณทราบ ตัวอย่างเช่น คุณสามารถระบุได้ว่าผู้ใช้รายหนึ่งได้เปิดใช้ ค่ากำหนดเบราว์เซอร์แบบประหยัดแบนด์วิดท์ผ่านคำค้นหาสื่อ prefers-reduced-data และใช้ค่ากำหนดนี้เพื่อเลือกให้ผู้ใช้ใช้รูปภาพความหนาแน่นต่ำเสมอ โดยไม่คำนึงถึงความหนาแน่นของการแสดงผล แต่ถ้าไม่มีการดำเนินการอย่างสม่ำเสมอโดยนักพัฒนาซอฟต์แวร์ทุกรายในเว็บไซต์ทั้งหมด ก็จะไม่มีประโยชน์มากนักสำหรับผู้ใช้ พวกเขาอาจจะถูกเอาใจใส่ในเว็บไซต์หนึ่ง และเจอกับอุปสรรคแย่งชิงแบนด์วิดท์ของรูปภาพในอีกไซต์หนึ่ง

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

กำลังอธิบายความกว้างด้วย w

srcset ยอมรับตัวบ่งชี้ประเภทที่ 2 สำหรับตัวเลือกแหล่งที่มาของรูปภาพ ซึ่งมีประสิทธิภาพมากกว่าเดิมมาก และสำหรับวัตถุประสงค์ของเรา เข้าใจง่ายขึ้นมาก แทนที่จะแจ้งว่าผู้สมัครมีขนาดที่เหมาะสมสำหรับความหนาแน่นของการแสดงผลที่ระบุ ไวยากรณ์ w จะอธิบายความกว้างโดยธรรมชาติของแหล่งที่มาของตัวเลือกแต่ละรายการ เช่นเดียวกัน ผู้สมัครแต่ละคนจะบันทึกมิติข้อมูลของตนเหมือนกัน เนื้อหา การครอบตัดเดียวกัน และมีสัดส่วนภาพเท่ากัน แต่ในกรณีนี้ คุณต้องการให้เบราว์เซอร์ของผู้ใช้เลือกตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้ Small.jpg แหล่งที่มาที่มีความกว้างปกติ 600px และ large.jpg เป็นแหล่งข้อมูลที่มีความกว้างปกติ 1200px

srcset="small.jpg 600w, large.jpg 1200w"

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

กำลังอธิบายการใช้งานด้วย sizes

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

ซึ่งไม่ได้บอกอะไรเลยเกี่ยวกับวิธีแสดงรูปภาพในเลย์เอาต์ของหน้า รูปภาพใช้วิวพอร์ตไม่ได้ เป็นพร็อกซีสำหรับขอบเขตบนของขนาด img เนื่องจากอาจใช้คอนเทนเนอร์ที่เลื่อนในแนวนอน เราจึงต้อง ให้ข้อมูลนี้แก่เบราว์เซอร์และใช้มาร์กอัป คำขอเหล่านี้มีเพียงเท่านี้

sizes มีเจตนาสร้างข้อมูลเกี่ยวกับรูปภาพทันทีที่แยกวิเคราะห์มาร์กอัป เช่นเดียวกับ srcset เหมือนกับ srcset เป็นชื่อย่อสำหรับ "ต่อไปนี้คือไฟล์ต้นฉบับและขนาดแฝง" แอตทริบิวต์ sizes ย่อมาจาก "here" คือขนาดของรูปภาพที่แสดงในเลย์เอาต์" วิธีที่คุณอธิบายรูปภาพนั้นสัมพัทธ์กับวิวพอร์ต ซึ่งขอแนะนำอีกครั้งคือวิวพอร์ต ขนาดคือข้อมูลเลย์เอาต์เพียงรายการเดียวที่เบราว์เซอร์มีเมื่อมีการส่งคำขอรูปภาพ

การพิมพ์อาจดูซับซ้อนเล็กน้อย แต่ในทางปฏิบัติจะเข้าใจได้ง่ายกว่ามาก

<img
 
sizes="80vw"
 
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
 
src="fallback.jpg"
 
alt="...">

ในส่วนนี้ ค่า sizes นี้จะบอกให้เบราว์เซอร์ทราบว่าพื้นที่ในเลย์เอาต์ที่ img ใช้มีความกว้าง 80vw—80% ของ วิวพอร์ต อย่าลืมว่านี่ไม่ใช่วิธีการ แต่เป็นคำอธิบายขนาดของรูปภาพในเลย์เอาต์หน้าเว็บ ไม่ได้เขียนว่า "ทำอันนี้ ใช้พื้นที่ 80% ของวิวพอร์ต" แต่ "ภาพนี้จะใช้พื้นที่ 80% ของวิวพอร์ตเมื่อแสดงผลหน้าเว็บแล้ว"

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

แต่เพื่อให้แน่ใจถึงวิธีที่เราใช้ข้อมูลนี้ โปรดใช้เวลาสักครู่เพื่อทำความเข้าใจการตัดสินใจที่ ที่เบราว์เซอร์ของผู้ใช้สร้างเมื่อพบมาร์กอัปนี้

คุณแจ้งเบราว์เซอร์ว่ารูปภาพนี้จะใช้พื้นที่ 80% ของวิวพอร์ตที่พร้อมใช้งาน ดังนั้นถ้าเราจะแสดงผล img นี้ใน อุปกรณ์ที่มีวิวพอร์ตกว้าง 1000 พิกเซล รูปภาพนี้จะใช้พื้นที่ 800 พิกเซล เบราว์เซอร์จะนำค่านั้นมาหารด้วย ความกว้างของตัวเลือกแหล่งที่มาของรูปภาพแต่ละรายการที่เราระบุไว้ใน srcset แหล่งที่มาที่เล็กที่สุด มีขนาดตามปกติ 600 พิกเซล ดังนั้น: 600÷800=.75 ภาพขนาดกลางของเรากว้าง 1,200 พิกเซล: 1200÷800=1.5 ภาพที่ใหญ่ที่สุดของเรามีความกว้าง 2,000 พิกเซล: 2000÷800=2.5

ผลของการคำนวณดังกล่าว (.75, 1.5 และ 2.5) เป็นตัวเลือกที่มีประสิทธิภาพสำหรับ DPR ให้ตรงตามความต้องการของผู้ใช้ ขนาดวิวพอร์ต เนื่องจากเบราว์เซอร์มีข้อมูลของความหนาแน่นในการแสดงผลของผู้ใช้ด้วย เบราว์เซอร์จึงทำการตัดสินใจต่างๆ ดังนี้

เมื่อใช้วิวพอร์ตนี้ ระบบจะทิ้งตัวเลือก small.jpg โดยไม่คำนึงถึงความหนาแน่นของการแสดงผลของผู้ใช้ โดยคำนวณ DPR ต่ำกว่า 1 แหล่งที่มานี้จะต้องมีการเพิ่มขนาดสำหรับผู้ใช้ ดังนั้นจึงไม่เหมาะสม medium.jpg บนอุปกรณ์ที่มี DPR เป็น 1 ที่ใกล้เคียงที่สุด—แหล่งที่มาดังกล่าวเหมาะสมสำหรับการแสดงที่ DPR ที่ 1.5 ดังนั้นจึงมีขนาดใหญ่กว่าที่จำเป็นเล็กน้อย แต่โปรดทราบว่าการปรับลดขนาดระดับทรัพยากรนั้น ด้วยกระบวนการที่ดูราบรื่น ในอุปกรณ์ที่มี DPR 2 รายการ large.jpg มีค่าใกล้เคียงที่สุด ระบบจึงเลือกไว้

หากรูปภาพเดียวกันแสดงผลในวิวพอร์ตแบบกว้าง 600 พิกเซล ผลการคำนวณทั้งหมดจะต่างออกไปโดยสิ้นเชิง นั่นคือ 80vw เปลี่ยนเป็น 480 พิกเซล เมื่อเราแบ่งแหล่งที่มา ความกว้างจะตัดกับค่านั้น เราจะได้ 1.25, 2.5 และ 4.1666666667 ระบบจะเลือก small.jpg ในขนาดวิวพอร์ตนี้ บนอุปกรณ์ 1 เท่า และ medium.jpg จะจับคู่กับอุปกรณ์ 2 เท่า

ภาพนี้จะดูเหมือนกันในบริบทการเรียกดูเหล่านี้ทั้งหมด ไฟล์ต้นฉบับทั้งหมดของเรามีขนาดเท่ากันทุกประการ และแต่ละการแสดงผลจะแสดงผลได้ชัดเจนเท่าที่ความหนาแน่นของการแสดงผลของผู้ใช้จะอนุญาต แต่แทนที่จะแสดง large.jpg ต่อผู้ใช้ทุกคน เพื่อรองรับวิวพอร์ตที่ใหญ่ที่สุดและความหนาแน่นของการแสดงผลสูงสุด ผู้ใช้จะได้รับตัวเลือกที่เหมาะสมน้อยที่สุดเสมอ ด้วยการใช้ไวยากรณ์ที่สื่อความหมายแทนที่จะใช้รูปแบบที่กำหนดไว้ล่วงหน้า คุณจะไม่ต้องตั้งค่าเบรกพอยท์ด้วยตนเองและพิจารณาวิวพอร์ตในอนาคตและ DPR คุณเพียงแค่ให้ข้อมูลแก่เบราว์เซอร์และอนุญาตให้ระบุคำตอบสำหรับคุณ

เนื่องจากค่า sizes ของเราสัมพันธ์กับวิวพอร์ตและไม่เกี่ยวข้องกับเลย์เอาต์หน้าเว็บโดยสมบูรณ์ จึงจะเพิ่มข้อมูลแทรกอีกชั้นหนึ่ง ไม่บ่อยนักที่จะมีรูปภาพที่เฉพาะใช้สัดส่วนของวิวพอร์ตโดยไม่มีระยะขอบความกว้างคงที่ ระยะห่างจากขอบ หรืออิทธิพลต่อมุมมอง จากองค์ประกอบอื่นๆ บนหน้าเว็บ บ่อยครั้งที่คุณจะต้องแสดงความกว้างของรูปภาพโดยใช้หน่วยต่างๆ ร่วมกัน เปอร์เซ็นต์, em, px และอื่นๆ

โชคดีที่คุณสามารถใช้ calc() ที่นี่ เบราว์เซอร์ใดๆ ก็ตามที่รองรับภายในระบบสำหรับรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์จะสนับสนุน calc() ด้วยเช่นกัน ทำให้เราสามารถ หน่วย CSS ผสมและจับคู่ เช่น รูปภาพที่มีความกว้างเต็มของวิวพอร์ตของผู้ใช้ ลบระยะขอบ 1em ด้านใดด้านหนึ่ง

<img
   
sizes="calc(100vw-2em)"
   
srcset="small.jpg 400w, medium.jpg 800w, large.jpg 1600w, x-large.jpg 2400w"
   
src="fallback.jpg"
   
alt="...">

การอธิบายเบรกพอยท์

หากคุณใช้เวลาไปกับการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์ไปนานแล้ว คุณอาจพบว่ามีบางอย่างขาดหายไปจากตัวอย่างต่อไปนี้ พื้นที่ที่รูปภาพใช้ในเค้าโครงมีแนวโน้มที่จะเปลี่ยนแปลงไปตามเบรกพอยท์ของเลย์เอาต์ของเราอย่างมาก ในกรณีดังกล่าว คุณจำเป็นต้อง เพื่อส่งรายละเอียดเพิ่มเติมเล็กน้อยไปยังเบราว์เซอร์: sizes ยอมรับชุดตัวเลือกที่คั่นด้วยเครื่องหมายจุลภาคสำหรับขนาดที่แสดงผล เช่นเดียวกับ srcset ยอมรับคำที่แนะนำที่คั่นด้วยคอมมาสำหรับแหล่งที่มาของรูปภาพ เงื่อนไขเหล่านั้นจะใช้ไวยากรณ์คิวรี่สื่อที่คุ้นเคย ไวยากรณ์นี้มีการจับคู่ครั้งแรก: ทันทีที่เงื่อนไขสื่อตรงกัน เบราว์เซอร์จะหยุดแยกวิเคราะห์แอตทริบิวต์ sizes และค่า ที่ระบุไว้

สมมติว่าคุณมีรูปภาพที่ใช้พื้นที่ 80% ของวิวพอร์ต ลบด้วยระยะห่างจากขอบทั้งสองด้าน em สำหรับวิวพอร์ตที่เกิน 1,200 พิกเซล วิวพอร์ตมีขนาดเล็กลงและใช้พื้นที่เต็มความกว้างของวิวพอร์ต

  <img
     
sizes="(min-width: 1200px) calc(80vw - 2em), 100vw"
     
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
     
src="fallback.jpg"
     
alt="...">

หากวิวพอร์ตของผู้ใช้มีขนาดใหญ่กว่า 1, 200 พิกเซล calc(80vw - 2em) จะอธิบายความกว้างของรูปภาพในเลย์เอาต์ของเรา หาก เงื่อนไข (min-width: 1200px) ที่ไม่ตรง เบราว์เซอร์จะไปยังค่าถัดไป เนื่องจากไม่มี เงื่อนไขสื่อที่เชื่อมโยงกับค่านี้ ระบบจะใช้ 100vw เป็นค่าเริ่มต้น หากคุณเขียนแอตทริบิวต์ sizes นี้โดยใช้ คิวรี่สื่อ max-width รายการ:

  <img
     
sizes="(max-width: 1200px) 100vw, calc(80vw - 2em)"
     
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
     
src="fallback.jpg"
     
alt="...">

เป็นภาษาที่อ่านง่าย: "(max-width: 1200px) ตรงกันไหม หากไม่ใช่ ให้ดำเนินการต่อ ค่าถัดไป calc(80vw - 2em) ไม่มีเงื่อนไขที่เข้าเกณฑ์ นี่คือรายการที่เลือก

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

ไวยากรณ์ที่ระบุว่า "ใช้แหล่งที่มานี้บนจอแสดงผลความละเอียดสูง" ก็คาดการณ์ได้ แต่ก็ไม่ได้ช่วยแก้ปัญหาหลัก ด้วยรูปภาพในการจัดวางที่ปรับเปลี่ยนตามอุปกรณ์: ประหยัดแบนด์วิดท์ของผู้ใช้ ความหนาแน่นของพิกเซลของหน้าจอมีความเกี่ยวข้องกับอินเทอร์เน็ตเป็นเส้นสัมผัสเท่านั้น ความเร็วในการเชื่อมต่อหรือไม่เลย หากคุณกำลังใช้แล็ปท็อปชั้นนำ แต่ท่องเว็บโดยใช้การเชื่อมต่อแบบจำกัดปริมาณอินเทอร์เน็ต กับโทรศัพท์ หรือใช้การเชื่อมต่อ Wi-Fi บนเครื่องบินที่สั่นไหว คุณอาจต้องเลือกไม่ใช้แหล่งที่มาของภาพความละเอียดสูง ไม่ว่า คุณภาพของการแสดงผล

การไม่ละทิ้งคำพูดสุดท้ายต่อเบราว์เซอร์จะทำให้มีการปรับปรุงประสิทธิภาพมากกว่าที่เราจะจัดการด้วยคำสั่งที่เคร่งครัด ไวยากรณ์ ตัวอย่างเช่น ในเบราว์เซอร์ส่วนใหญ่ img ที่ใช้ไวยากรณ์ srcset หรือ sizes จะไม่รบกวนการขอแหล่งที่มาที่มีขนาดเล็ก มากกว่ามิติข้อมูลที่ผู้ใช้มีอยู่ในแคชของเบราว์เซอร์แล้ว อะไรคือจุดประสงค์ในการส่งคำขอใหม่สำหรับแหล่งที่มา ที่จะมีลักษณะเหมือนกันเมื่อเบราว์เซอร์สามารถลดขนาดแหล่งที่มาของรูปภาพที่มีอยู่แล้วอย่างราบรื่นได้อย่างไร แต่หากผู้ใช้ปรับขนาด วิวพอร์ตจนถึงจุดที่จำเป็นต้องใช้รูปภาพใหม่เพื่อหลีกเลี่ยงการเพิ่มขนาด คำขอนั้นจะยังคงเกิดขึ้น ดังนั้นทุกอย่าง ในแบบที่คุณคาดหวัง

การที่ไม่มีการควบคุมที่ชัดเจนนั้นอาจฟังดูน่ากลัวเล็กน้อยแต่เป็นเพราะคุณกำลังใช้ไฟล์ต้นฉบับที่มีไฟล์ที่เหมือนกัน เราก็ไม่มีแนวโน้มที่จะนำเสนอโฆษณา "เสีย" แก่ผู้ใช้อีก มากกว่าที่เรามักได้รับจาก src แหล่งที่มาเดียว ไม่ว่า การตัดสินใจบนเบราว์เซอร์

กำลังใช้ sizes และ srcset

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

srcset คือกรอบการทำงานอัตโนมัติที่ไม่เคยมีมาก่อน คุณจะสร้างสรรค์รูปภาพหลายๆ เวอร์ชันด้วยตัวเองเพื่อใช้ สภาพแวดล้อมเวอร์ชันที่ใช้งานจริง โดยทำให้กระบวนการเป็นแบบอัตโนมัติโดยใช้ตัวเรียกใช้งานอย่าง Gulp ซึ่งเป็น Bundler อย่าง Webpack ซึ่งเป็นบุคคลที่สาม CDN อย่างเช่น Cloudential หรือฟังก์ชันที่มีอยู่ใน CMS ที่คุณเลือกอยู่แล้ว มีข้อมูลเพียงพอที่จะสร้างแหล่งที่มา ตั้งแต่แรก ระบบก็จะมีข้อมูลเพียงพอที่จะเขียนเป็นแอตทริบิวต์ srcset ที่ใช้งานได้

sizes ทำงานอัตโนมัติได้ยากขึ้นเล็กน้อย อย่างที่คุณทราบ วิธีเดียวที่ระบบจะสามารถคำนวณขนาดของรูปภาพใน การแสดงผลคือการแสดงผลเลย์เอาต์ โชคดีที่มีเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์จำนวนมากปรากฏขึ้น กระบวนการเขียนแอตทริบิวต์ sizes ด้วยลายมือที่มีประสิทธิภาพที่ไม่เคยมีใครทำได้ ตัวอย่างเช่น respImageLint เป็นข้อมูลโค้ดที่ใช้เพื่อตรวจสอบแอตทริบิวต์ sizes เพื่อความถูกต้องและให้คำแนะนำในการปรับปรุง โปรเจ็กต์ Lazysizes ถูกบุกรุก ประสิทธิภาพโดยการเลื่อนคำขอรูปภาพไปจนกว่าจะสร้างเลย์เอาต์ ทำให้ JavaScript สามารถ สร้างค่า sizes ให้คุณ หากคุณใช้เฟรมเวิร์กการแสดงผลฝั่งไคลเอ็นต์อย่างเต็มรูปแบบ เช่น React หรือ Vue มี จำนวนโซลูชันสำหรับการสร้างและ/หรือสร้างแอตทริบิวต์ srcset และ sizes ซึ่งเราจะอธิบายเพิ่มเติมใน CMS และเฟรมเวิร์ก