Cú pháp mô tả

Trong học phần này, bạn sẽ tìm hiểu cách cho phép trình duyệt lựa chọn hình ảnh để trình duyệt có thể đưa ra quyết định tốt nhất về nội dung sẽ hiển thị. srcset không phải là phương thức để hoán đổi nguồn hình ảnh tại các điểm ngắt cụ thể và không phải là để hoán đổi hình ảnh này cho hình ảnh khác. Những cú pháp này cho phép trình duyệt giải quyết một vấn đề rất khó khăn, độc lập với chúng tôi: yêu cầu và hiển thị liền mạch một nguồn hình ảnh phù hợp với ngữ cảnh duyệt web của người dùng, bao gồm kích thước khung nhìn, mật độ hiển thị, lựa chọn ưu tiên của người dùng, băng thông và vô số yếu tố khác.

Đây là một câu hỏi lớn. Chắc chắn là nhiều hơn những gì chúng ta muốn xem xét khi chúng ta chỉ đơn giản là đánh dấu một hình ảnh cho web và để thực hiện tốt việc này, chúng ta cần nhiều thông tin hơn khả năng tiếp cận của chúng ta.

Mô tả mật độ bằng x

<img> có chiều rộng cố định sẽ chiếm cùng một lượng khung nhìn trong mọi ngữ cảnh duyệt web, bất kể mật độ màn hình của người dùng (số lượng pixel vật lý tạo nên màn hình). Ví dụ: một hình ảnh có chiều rộng vốn có là 400px sẽ chiếm gần như toàn bộ khung nhìn của trình duyệt trên cả Google Pixel ban đầu và Pixel 6 Pro mới hơn nhiều — cả hai thiết bị đều có khung nhìn rộng 412px pixel chuẩn.

Tuy nhiên, Pixel 6 Pro có màn hình sắc nét hơn nhiều: Pixel 6 Pro có độ phân giải vật lý là 1440 × 3120 pixel, trong khi Pixel có 1080 × 1920 pixel (tức là số lượng pixel phần cứng tạo nên chính màn hình).

Tỷ lệ giữa pixel logic của một thiết bị và pixel vật lý là tỷ lệ pixel của thiết bị cho màn hình đó (DPR). DPR được tính bằng cách chia độ phân giải màn hình thực tế của thiết bị cho pixel CSS của khung nhìn.

DPR là 2 hiển thị trong cửa sổ bảng điều khiển.

Vì vậy, Pixel ban đầu có DPR là 2,6, trong khi Pixel 6 Pro có DPR là 3,5.

iPhone 4, thiết bị đầu tiên có DPR lớn hơn 1, báo cáo tỷ lệ pixel của thiết bị là 2 – độ phân giải vật lý của màn hình cao gấp đôi độ phân giải logic. Mọi thiết bị trước iPhone 4 đều có DPR là 1: 1 pixel logic trên một pixel vật lý.

Nếu bạn xem hình ảnh rộng hết 400px trên màn hình có DPR là 2, thì mỗi pixel logic sẽ được kết xuất trên 4 pixel thực của màn hình: 2 pixel ngang và 2 pixel dọc. Hình ảnh không được hưởng lợi từ màn hình hiển thị mật độ cao – trông giống như trên màn hình có DPR của 1. Tất nhiên, mọi thứ "vẽ" bằng công cụ kết xuất của trình duyệt (ví dụ: văn bản, hình dạng CSS hoặc SVG) sẽ được vẽ cho phù hợp với màn hình có mật độ hiển thị cao hơn. Tuy nhiên, như bạn đã tìm hiểu trong phần Định dạng và nén hình ảnh, hình ảnh đường quét là các lưới pixel cố định. Mặc dù không phải lúc nào cũng hiển thị rõ ràng, nhưng hình ảnh đường quét được nâng cấp để phù hợp với màn hình có mật độ điểm ảnh cao hơn sẽ có độ phân giải thấp so với trang xung quanh.

Để ngăn việc nâng cấp này, hình ảnh được kết xuất phải có chiều rộng nội tại ít nhất là 800 pixel. Khi được thu nhỏ để vừa với một không gian trong bố cục rộng 400 pixel logic, nguồn hình ảnh 800 pixel đó có mật độ pixel gấp đôi — trên màn hình có DPR là 2, hình ảnh sẽ trông đẹp và sắc nét.

Cận cảnh một cánh hoa cho thấy sự chênh lệch về mật độ.

Vì màn hình có DPR là 1 không thể sử dụng mật độ tăng lên của hình ảnh, nên hình ảnh sẽ bị thu nhỏ để phù hợp với màn hình hiển thị — và như bạn đã biết, hình ảnh thu nhỏ sẽ trông vẫn ổn. Trên màn hình có mật độ điểm ảnh thấp, hình ảnh phù hợp với màn hình có mật độ điểm ảnh cao sẽ trông giống như mọi hình ảnh khác có mật độ điểm ảnh thấp.

Như bạn đã tìm hiểu trong phần Hình ảnh và hiệu suất, người dùng có màn hình mật độ thấp xem nguồn hình ảnh được thu nhỏ về 400px sẽ chỉ cần một nguồn có chiều rộng vốn có là 400px. Mặc dù hình ảnh lớn hơn nhiều sẽ phù hợp với tất cả người dùng về mặt hình ảnh, nhưng nguồn hình ảnh khổng lồ, có độ phân giải cao hiển thị trên màn hình nhỏ và có mật độ thấp sẽ trông giống như bất kỳ hình ảnh nhỏ, có mật độ thấp nào khác, nhưng cảm thấy chậm hơn nhiều.

Như bạn có thể đoán, các thiết bị thiết bị di động có DPR là 1 hiếm gặp, mặc dù vẫn phổ biến trong ngữ cảnh duyệt web trên "máy tính". Theo dữ liệu do Matt Hobbs chia sẻ, khoảng 18% số phiên duyệt web trên GOV.UK từ tháng 11 năm 2022 báo cáo DPR là 1. Mặc dù hình ảnh có mật độ điểm ảnh cao sẽ xuất hiện như những gì người dùng có thể mong đợi, nhưng chúng sẽ có mức băng thông và chi phí xử lý cao hơn nhiều – điều đáng lo ngại đối với những người dùng trên các thiết bị cũ và kém mạnh mẽ hơn vẫn có thể có màn hình với mật độ điểm ảnh thấp.

Việc sử dụng srcset đảm bảo rằng chỉ các thiết bị có màn hình độ phân giải cao mới nhận được các nguồn hình ảnh đủ lớn để trông sắc nét mà không chuyển cùng mức chi phí băng thông đó sang người dùng có màn hình độ phân giải thấp hơn.

Thuộc tính srcset xác định một hoặc nhiều ứng cử viên được phân tách bằng dấu phẩy để hiển thị hình ảnh. Mỗi đề xuất được tạo thành từ 2 thứ: URL, giống như bạn sẽ sử dụng trong src và cú pháp mô tả nguồn hình ảnh đó. Mỗi đề xuất trong srcset được mô tả theo chiều rộng vốn có ("cú pháp w") hoặc mật độ dự định ("cú pháp x").

Cú pháp x là cách viết tắt của "nguồn này phù hợp với màn hình có mật độ này". Đề xuất theo sau là 2x phù hợp với màn hình có DPR là 2.

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

Các trình duyệt hỗ trợ srcset sẽ được đưa ra 2 đề xuất: double-density.jpg (2x mô tả mức độ phù hợp để hiển thị màn hình có DPR là 2 và low-density.jpg trong thuộc tính src). Đề xuất được chọn nếu không tìm thấy đề xuất nào phù hợp hơn trong srcset. Đối với các trình duyệt không hỗ trợ srcset, thuộc tính này và nội dung của thuộc tính đó sẽ bị bỏ qua — nội dung của src sẽ được yêu cầu như thường lệ.

Bạn có thể nhầm lẫn các giá trị được chỉ định trong thuộc tính srcset cho hướng dẫn. 2x đó thông báo cho trình duyệt rằng tệp nguồn được liên kết sẽ phù hợp để sử dụng trên màn hình có DPR là 2 – thông tin về chính nguồn đó. Phần mềm không cho trình duyệt biết cách sử dụng nguồn đó, chỉ thông báo cho trình duyệt biết cách sử dụng nguồn đó. Đây là một sự khác biệt khó thấy nhưng quan trọng: đây là hình ảnh có mật độ kép, không phải là hình ảnh để sử dụng trên màn hình có mật độ kép.

Sự khác biệt giữa cú pháp cho biết "nguồn này phù hợp với màn hình 2x" và cú pháp cho biết "sử dụng nguồn này trên màn hình 2x" chỉ hơi trong bản in, nhưng mật độ hiển thị chỉ là một trong số rất nhiều yếu tố liên kết mà trình duyệt sử dụng để quyết định về đề xuất hiển thị, chỉ một số yếu tố bạn có thể biết. Ví dụ: riêng lẻ, bạn có thể xác định rằng người dùng đã bật tuỳ chọn trình duyệt tiết kiệm băng thông thông qua truy vấn phương tiện prefers-reduced-data và sử dụng tuỳ chọn đó để luôn chọn người dùng sử dụng hình ảnh có mật độ hiển thị thấp bất kể mật độ hiển thị của họ, nhưng trừ phi mọi nhà phát triển triển khai một cách nhất quán trên mọi trang web, việc này sẽ không mang lại nhiều lợi ích cho người dùng. Có thể họ sẽ tôn trọng lựa chọn ưu tiên của mình trên một trang web nhưng sẽ gặp phải tình trạng hình ảnh bị giảm băng thông ở trang web tiếp theo.

Thuật toán lựa chọn tài nguyên mơ hồ có chủ ý mà srcset/sizes sử dụng sẽ tạo chỗ trống cho các trình duyệt quyết định chọn những hình ảnh có mật độ thấp hơn với mức giảm băng thông hoặc dựa trên ưu tiên để giảm thiểu mức sử dụng dữ liệu mà chúng tôi không chịu trách nhiệm về cách thức, thời điểm hoặc ngưỡng nào. Không có nghĩa là phải đảm nhận trách nhiệm—và công việc bổ sung—mà trình duyệt được trang bị tốt hơn để xử lý bạn.

Mô tả chiều rộng bằng w

srcset chấp nhận loại mã mô tả thứ hai cho các ứng viên nguồn hình ảnh. Đây là công cụ mạnh mẽ hơn nhiều — và đối với mục đích của chúng tôi là rất dễ hiểu hơn nhiều. Thay vì gắn cờ đề xuất là có kích thước thích hợp với mật độ hiển thị nhất định, cú pháp w sẽ mô tả chiều rộng vốn có của mỗi nguồn đề xuất. Xin nhắc lại rằng mỗi đề xuất đều được lưu như nhau cho các kích thước – cùng một nội dung, cùng một đường cắt và cùng một tỷ lệ khung hình. Nhưng trong trường hợp này, bạn sẽ muốn trình duyệt của người dùng chọn giữa hai đề xuất:small.jpg, một nguồn có chiều rộng vốn có là 600px và large.jpg, một nguồn với chiều rộng vốn có là 1200px.

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

Điều này không cho trình duyệt biết việc nên làm với thông tin này mà chỉ cung cấp cho trình duyệt danh sách các đề xuất để hiển thị hình ảnh. Trước khi trình duyệt có thể đưa ra quyết định về nguồn sẽ hiển thị, bạn cần cung cấp thêm thông tin cho trình duyệt: nội dung mô tả về cách hình ảnh hiển thị trên trang. Để làm việc đó, hãy dùng thuộc tính sizes.

Mô tả mức sử dụng bằng sizes

Các trình duyệt hoạt động cực kỳ hiệu quả trong việc truyền hình ảnh. Yêu cầu về thành phần hình ảnh sẽ được bắt đầu từ rất sớm trước khi các yêu cầu về biểu định kiểu hoặc JavaScript – thường là ngay cả trước khi mã đánh dấu được phân tích cú pháp đầy đủ. Khi thực hiện những yêu cầu này, trình duyệt sẽ không có thông tin về trang đó, ngoài thẻ đánh dấu. Trình duyệt thậm chí có thể chưa gửi yêu cầu nào cho các biểu định kiểu bên ngoài, chứ chưa áp dụng chúng. Tại thời điểm trình duyệt phân tích cú pháp thẻ đánh dấu và bắt đầu đưa ra yêu cầu bên ngoài, trình duyệt chỉ có thông tin ở cấp trình duyệt: kích thước khung nhìn của người dùng, mật độ pixel trên màn hình của người dùng, lựa chọn ưu tiên của người dùng, v.v.

Điều này không cho chúng ta biết bất cứ điều gì về cách kết xuất hình ảnh trong bố cục trang, thậm chí không thể dùng khung nhìn làm proxy cho giới hạn trên của kích thước img, vì hình ảnh có thể chiếm vùng chứa cuộn theo chiều ngang. Vì vậy, chúng ta cần cung cấp thông tin này cho trình duyệt và thực hiện bằng mã đánh dấu. Đó là tất cả những gì chúng tôi có thể sử dụng cho những yêu cầu này.

Giống như srcset, sizes được dự định sẽ cung cấp thông tin về một hình ảnh ngay sau khi mã đánh dấu được phân tích cú pháp. Cũng giống như thuộc tính srcset, viết tắt của "đây là các tệp nguồn và kích thước vốn có", thuộc tính sizes là viết tắt của "đây là kích thước của hình ảnh được kết xuất trong bố cục". Cách bạn mô tả hình ảnh có liên quan đến khung nhìn. Xin nhắc lại, kích thước khung nhìn là thông tin bố cục duy nhất mà trình duyệt có khi yêu cầu hình ảnh được thực hiện.

Điều này nghe có vẻ hơi phức tạp nhưng thực tế thì sẽ dễ hiểu hơn:

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

Ở đây, giá trị sizes này cho trình duyệt biết rằng không gian trong bố cục mà img chiếm có chiều rộng là 80vw — 80% khung nhìn. Hãy nhớ rằng đây không phải là hướng dẫn mà là mô tả về kích thước của hình ảnh trong bố cục trang. Câu này không nói "tạo hình ảnh này chiếm 80% khung nhìn", nhưng "hình ảnh này sẽ chiếm 80% khung nhìn sau khi trang kết xuất".

Là nhà phát triển, công việc của bạn đã hoàn thành. Bạn đã mô tả chính xác danh sách các nguồn đề xuất trong srcset cũng như chiều rộng của hình ảnh trong sizes, và cũng giống như với cú pháp x trong srcset, phần còn lại tuỳ thuộc vào trình duyệt.

Tuy nhiên, để hiểu rõ cách thông tin này được sử dụng, hãy dành chút thời gian xem qua các quyết định mà trình duyệt của người dùng đưa ra khi gặp mã đánh dấu này:

Bạn đã thông báo cho trình duyệt rằng hình ảnh này sẽ chiếm 80% khung nhìn có sẵn. Vì vậy, nếu chúng ta kết xuất img này trên một thiết bị có khung nhìn rộng 1.000 pixel, hình ảnh này sẽ chiếm 800 pixel. Sau đó, trình duyệt sẽ lấy giá trị đó và chia theo chiều rộng của từng đề xuất nguồn hình ảnh mà chúng ta đã chỉ định trong srcset. Nguồn nhỏ nhất có kích thước vốn có là 600 pixel, chẳng hạn như: 600÷800=0,75. Hình ảnh trung bình của chúng tôi có chiều rộng 1200 pixel: 1200 ÷ 800=1,5. Hình ảnh lớn nhất của chúng tôi có chiều rộng 2000 pixel: 2000 ÷ 800=2,5.

Kết quả của các phép tính đó (.75, 1.52.5) là một cách hiệu quả, các lựa chọn DPR được điều chỉnh riêng cho phù hợp với kích thước khung nhìn của người dùng. Vì trình duyệt cũng có thông tin về mật độ hiển thị của người dùng, trình duyệt sẽ đưa ra một loạt các quyết định sau:

Ở kích thước khung nhìn này, đề xuất small.jpg sẽ bị loại bỏ bất kể mật độ hiển thị của người dùng – với DPR được tính toán thấp hơn 1, nguồn này sẽ yêu cầu nâng cấp cho mọi người dùng, vì vậy, nguồn này không phù hợp. Trên thiết bị có DPR là 1, medium.jpg là nguồn phù hợp nhất. Nguồn đó phù hợp để hiển thị ở DPR là 1.5, vì vậy, DPR sẽ lớn hơn một chút so với mức cần thiết, nhưng hãy nhớ rằng việc giảm quy mô là một quá trình liền mạch về mặt hình ảnh. Trên thiết bị có DPR là 2, large.jpg là kết quả khớp nhất nên sẽ được chọn.

Nếu cùng một hình ảnh được kết xuất trên một khung nhìn rộng 600 pixel, thì kết quả của tất cả phép toán đó sẽ hoàn toàn khác: 80vw giờ đây là 480px. Khi chia chiều rộng của các nguồn theo giá trị đó, chúng ta nhận được 1.25, 2.54.1666666667. Ở kích thước khung nhìn này, small.jpg sẽ được chọn trên các thiết bị 1x và medium.jpg sẽ khớp trên các thiết bị 2x.

Hình ảnh này sẽ trông giống hệt nhau trong tất cả các ngữ cảnh duyệt web này: tất cả các tệp nguồn của chúng tôi đều giống hệt nhau về kích thước và mỗi tệp được hiển thị sắc nét như mật độ hiển thị của người dùng cho phép. Tuy nhiên, thay vì phân phát large.jpg cho mọi người dùng để phù hợp với khung nhìn lớn nhất và màn hình có mật độ hiển thị cao nhất, người dùng sẽ luôn được phân phát cho đề xuất nhỏ nhất phù hợp. Bằng cách sử dụng cú pháp mô tả thay vì cú pháp quy định, bạn không cần đặt các điểm ngắt và xem xét các khung nhìn và DPR trong tương lai theo cách thủ công. Bạn chỉ cần cung cấp thông tin cho trình duyệt và cho phép trình duyệt xác định câu trả lời cho bạn.

Vì giá trị sizes của chúng ta tương ứng với khung nhìn và hoàn toàn độc lập với bố cục trang, nên sẽ thêm một lớp chức năng. Hiếm khi có một hình ảnh chỉ chiếm một tỷ lệ phần trăm khung nhìn, không có lề có chiều rộng cố định, khoảng đệm hoặc bị ảnh hưởng từ các phần tử khác trên trang. Bạn thường xuyên cần biểu thị chiều rộng của hình ảnh bằng cách sử dụng kết hợp các đơn vị; phần trăm, em, px, v.v.

May mắn là bạn có thể sử dụng calc() tại đây – mọi trình duyệt có hỗ trợ gốc cho hình ảnh thích ứng cũng sẽ hỗ trợ calc(), cho phép chúng tôi kết hợp các đơn vị CSS – ví dụ: một hình ảnh chiếm toàn bộ chiều rộng của khung nhìn của người dùng, trừ đi lề 1em ở hai bên:

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

Mô tả điểm ngắt

Nếu đã dành nhiều thời gian làm việc với bố cục thích ứng, bạn có thể nhận thấy thiếu một điều gì đó trong các ví dụ sau: không gian một hình ảnh chiếm trong bố cục rất có khả năng thay đổi trên các điểm ngắt của bố cục. Trong trường hợp đó, bạn cần chuyển thêm một chút chi tiết cho trình duyệt: sizes chấp nhận một tập hợp các đề xuất được phân tách bằng dấu phẩy cho kích thước hiển thị của hình ảnh, giống như srcset chấp nhận các đề xuất được phân tách bằng dấu phẩy cho nguồn hình ảnh. Các điều kiện đó sử dụng cú pháp truy vấn phương tiện quen thuộc. Cú pháp này là kiểu khớp đầu tiên: ngay khi điều kiện nội dung đa phương tiện khớp, trình duyệt sẽ ngừng phân tích cú pháp thuộc tính sizes và giá trị đã chỉ định sẽ được áp dụng.

Giả sử bạn có một hình ảnh chiếm 80% khung nhìn, trừ đi một em khoảng đệm ở hai bên, trên các khung nhìn trên 1200px — trên các khung nhìn nhỏ hơn, hình ảnh đó chiếm toàn bộ chiều rộng của khung nhìn.

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

Nếu khung nhìn của người dùng lớn hơn 1200px, thì calc(80vw - 2em) sẽ mô tả chiều rộng của hình ảnh trong bố cục. Nếu điều kiện (min-width: 1200px) không khớp, trình duyệt sẽ chuyển sang giá trị tiếp theo. Vì không có điều kiện cụ thể nào về nội dung đa phương tiện gắn với giá trị này, nên 100vw được dùng làm mặc định. Nếu bạn phải viết thuộc tính sizes này bằng các truy vấn phương tiện 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="...">

Bằng ngôn từ đơn giản: "(max-width: 1200px) có khớp không? Nếu không, hãy tiếp tục. Giá trị tiếp theo calc(80vw - 2em) không có điều kiện đủ điều kiện nào, vì vậy, đây là giá trị đã chọn.

Sau khi cung cấp cho trình duyệt tất cả thông tin này về phần tử img – các nguồn tiềm năng, chiều rộng vốn có và cách bạn dự định hiển thị hình ảnh cho người dùng – trình duyệt sẽ sử dụng một bộ quy tắc mờ để xác định việc cần làm với thông tin đó. Nếu điều đó nghe có vẻ mơ hồ, thì đó là bởi vì nó như vậy – theo thiết kế. Thuật toán lựa chọn nguồn được mã hoá trong thông số kỹ thuật HTML rõ ràng không rõ ràng về cách chọn nguồn. Sau khi phân tích cú pháp nguồn, mã mô tả và cách hình ảnh được hiển thị, trình duyệt có thể tự do làm bất cứ điều gì muốn — bạn không thể biết chắc trình duyệt sẽ chọn nguồn nào.

Cú pháp có nội dung "sử dụng nguồn này trên màn hình có độ phân giải cao" sẽ có thể dự đoán được nhưng sẽ không giải quyết được vấn đề cốt lõi với hình ảnh trong bố cục thích ứng: tiết kiệm băng thông người dùng. Mật độ pixel của màn hình chỉ liên quan trực tiếp đến tốc độ kết nối Internet, nếu có. Nếu đang sử dụng máy tính xách tay hàng đầu nhưng duyệt web bằng kết nối có đồng hồ đo, được chia sẻ Internet với điện thoại hoặc sử dụng kết nối wifi trên máy bay bị rung, bạn có thể muốn chọn không sử dụng nguồn hình ảnh có độ phân giải cao, bất kể chất lượng màn hình của bạn như thế nào.

Việc đưa ra phản hồi cuối cùng cho trình duyệt cho phép cải thiện hiệu suất nhiều hơn so với những gì chúng tôi có thể quản lý bằng một cú pháp quy định nghiêm ngặt. Ví dụ: trong hầu hết các trình duyệt, một img dùng cú pháp srcset hoặc sizes sẽ không bao giờ bận tâm đến việc yêu cầu một nguồn có kích thước nhỏ hơn nguồn mà người dùng đã lưu trong bộ nhớ đệm của trình duyệt. Điều gì sẽ xảy ra khi thực hiện một yêu cầu mới cho một nguồn trông giống hệt nhau, khi trình duyệt có thể thu nhỏ nguồn hình ảnh một cách liền mạch đã có? Tuy nhiên, nếu người dùng mở rộng khung nhìn của họ đến mức cần hình ảnh mới để tránh việc nâng cấp hình ảnh, thì yêu cầu đó vẫn sẽ được thực hiện, vì vậy mọi thứ trông giống như bạn mong đợi.

Tình trạng thiếu khả năng kiểm soát rõ ràng này nghe có vẻ hơi đáng sợ nhưng xét về mặt giá trị, tuy nhiên vì bạn đang sử dụng các tệp nguồn có nội dung giống nhau, nên chúng tôi khó có thể đem lại cho người dùng trải nghiệm "hỏng" như khi sử dụng src nguồn đơn, bất kể quyết định của trình duyệt là gì.

Đang sử dụng sizessrcset

Đây là rất nhiều thông tin – cho cả bạn, người đọc và cho trình duyệt. srcsetsizes đều là cú pháp dày đặc, mô tả một lượng thông tin gây sốc bằng tương đối ít ký tự. Hay nói cách khác, đó là về mặt thiết kế: việc làm cho những cú pháp này trở nên ngắn gọn hơn và được con người chúng tôi phân tích cú pháp dễ dàng hơn — có thể khiến trình duyệt khó phân tích cú pháp hơn. Chuỗi càng phức tạp, thì càng có nhiều khả năng xảy ra lỗi phân tích cú pháp hoặc sự khác biệt ngoài ý muốn về hành vi giữa các trình duyệt. Tuy nhiên, có một nhược điểm ở đây: cú pháp mà máy đọc dễ dàng hơn là cú pháp dễ được máy viết hơn.

srcset là một trường hợp rõ ràng cho việc tự động hoá. Hiếm khi bạn tạo thủ công nhiều phiên bản hình ảnh cho một môi trường sản xuất, thay vì tự động hoá quy trình bằng cách sử dụng trình chạy tác vụ như Gulp, một trình đóng gói như Webpack, CDN của bên thứ ba như Cloudinary hoặc chức năng đã được tích hợp sẵn vào CMS mà bạn chọn. Được cung cấp đủ thông tin để tạo nguồn ngay từ đầu, hệ thống sẽ có đủ thông tin để ghi chúng vào một thuộc tính srcset khả thi.

sizes hơi khó tự động hoá hơn một chút. Như bạn đã biết, cách duy nhất để một hệ thống có thể tính toán kích thước của một hình ảnh trong bố cục được kết xuất là kết xuất bố cục đó. May mắn là một số công cụ cho nhà phát triển đã xuất hiện để tóm tắt quy trình viết tay các thuộc tính sizes với hiệu quả mà bạn không bao giờ có thể so khớp theo cách thủ công. Ví dụ: respImageLint là một đoạn mã nhằm kiểm tra độ chính xác của các thuộc tính sizes và đưa ra đề xuất cải thiện. Dự án Lazysizes làm giảm một số tốc độ để đạt được hiệu quả bằng cách trì hoãn các yêu cầu hình ảnh cho đến sau khi thiết lập bố cục, cho phép JavaScript tạo các giá trị sizes cho bạn. Nếu bạn đang sử dụng một khung kết xuất hình ảnh phía máy khách hoàn chỉnh (chẳng hạn như React hoặc Vue), thì có một số giải pháp để tạo và/hoặc tạo thuộc tính srcsetsizes. Chúng ta sẽ thảo luận thêm về những giải pháp này trong Hệ thống quản lý nội dung và Khung (framework).