نحوهای توصیفی

در این ماژول، شما یاد خواهید گرفت که چگونه به مرورگر امکان انتخاب تصاویر را بدهید تا بتواند بهترین تصمیم را در مورد اینکه چه چیزی را نمایش دهد، بگیرد. srcset روشی برای جابجایی منابع تصویر در نقاط شکست خاص نیست، و قرار نیست یک تصویر را با تصویر دیگری عوض کنید. این نحو به مرورگر اجازه می دهد تا یک مشکل بسیار دشوار را مستقل از ما حل کند: درخواست و ارائه یکپارچه منبع تصویر متناسب با زمینه مرور کاربر، از جمله اندازه درگاه، تراکم نمایش، ترجیحات کاربر، پهنای باند و عوامل بی شمار دیگر.

این یک سؤال بزرگ است - مطمئناً بیشتر از آن چیزی است که ما می خواهیم وقتی به سادگی یک تصویر را برای وب علامت گذاری می کنیم در نظر بگیریم، و انجام آن به خوبی مستلزم اطلاعات بیشتر از آنچه می توانیم به آن دسترسی داشته باشیم.

توصیف چگالی با x

یک <img> با عرض ثابت، بدون در نظر گرفتن تراکم صفحه نمایش کاربر - تعداد پیکسل های فیزیکی که صفحه نمایش آن ها را می سازد، همان مقدار از درگاه دید را در هر زمینه مروری اشغال می کند. به عنوان مثال، یک تصویر با عرض ذاتی 400px تقریباً کل نمای مرورگر را در Google Pixel اصلی و Pixel 6 Pro بسیار جدیدتر اشغال می کند - هر دو دستگاه دارای یک درگاه دید گسترده پیکسل منطقی 412px هستند.

پیکسل 6 پرو صفحه نمایش بسیار واضح تری دارد، با این حال: 6 پرو دارای وضوح فیزیکی 1440 × 3120 پیکسل است، در حالی که پیکسل 1080 × 1920 پیکسل است - یعنی تعداد پیکسل های سخت افزاری که خود صفحه نمایش را تشکیل می دهند.

نسبت بین پیکسل های منطقی دستگاه و پیکسل های فیزیکی، نسبت پیکسل های دستگاه برای آن نمایشگر (DPR) است. DPR با تقسیم وضوح واقعی صفحه نمایش دستگاه بر پیکسل های CSS یک درگاه نمایش محاسبه می شود.

بنابراین، پیکسل اصلی دارای DPR 2.6 است، در حالی که Pixel 6 Pro دارای DPR 3.5 است.

آیفون 4، اولین دستگاه با DPR بیشتر از 1، نسبت پیکسل دستگاه را 2 گزارش می کند—رزولوشن فیزیکی صفحه دو برابر وضوح منطقی است. هر دستگاهی قبل از آیفون 4 دارای DPR 1 بود: یک پیکسل منطقی به یک پیکسل فیزیکی.

اگر آن تصویر 400px را روی نمایشگری با DPR 2 مشاهده کنید، هر پیکسل منطقی در چهار پیکسل فیزیکی نمایشگر نمایش داده می شود: دو پیکسل افقی و دو پیکسل عمودی. این تصویر از نمایشگر با چگالی بالا بهره نمی‌برد - مانند نمایشگری با DPR 1 به نظر می‌رسد. البته، هر چیزی که توسط موتور رندر مرورگر ترسیم شود - برای مثال، متن، اشکال CSS یا SVGها - مطابق با نمایشگر با چگالی بالاتر ترسیم می شود. اما همانطور که از فرمت های تصویر و فشرده سازی یاد گرفتید، تصاویر شطرنجی شبکه های ثابتی از پیکسل ها هستند. در حالی که ممکن است همیشه به وضوح واضح نباشد، یک تصویر شطرنجی که برای نمایشگر با چگالی بالاتر ارتقا یافته است، در مقایسه با صفحه اطراف، وضوح پایینی به نظر می رسد.

برای جلوگیری از این افزایش مقیاس، تصویر رندر شده باید حداقل 800 پیکسل عرض داشته باشد. هنگامی که برای جا دادن فضایی در یک طرح بندی با عرض 400 پیکسل منطقی کوچک می شود، آن منبع تصویر 800 پیکسلی تراکم پیکسلی دو برابر دارد—در نمایشگری با DPR 2 ، زیبا و واضح به نظر می رسد.

از آنجایی که نمایشگری با DPR 1 نمی تواند از افزایش تراکم تصویر استفاده کند، برای مطابقت با نمایشگر، مقیاس آن کاهش می یابد - و همانطور که می دانید، یک تصویر کوچک شده به خوبی به نظر می رسد. در یک نمایشگر با چگالی کم، تصویری که برای نمایشگرهای با چگالی بالاتر مناسب است، مانند هر تصویر با چگالی پایین دیگر به نظر می رسد.

همانطور که در Images and Performance یاد گرفتید، کاربری با صفحه نمایش با چگالی کم که منبع تصویر کوچک شده را تا 400px مشاهده می کند، تنها به منبعی با عرض ذاتی 400px نیاز دارد . در حالی که یک تصویر بسیار بزرگتر از نظر بصری برای همه کاربران کار می کند، یک منبع تصویر بزرگ و با وضوح بالا که بر روی یک صفحه نمایش کوچک و چگالی کم ارائه می شود، مانند هر تصویر کوچک و کم تراکم دیگری به نظر می رسد، اما بسیار کندتر به نظر می رسد .

همانطور که ممکن است حدس بزنید، دستگاه های تلفن همراه با DPR 1 بسیار نادر هستند، اگرچه هنوز در زمینه های مرور "رومیزی" رایج است. بر اساس داده‌های به اشتراک گذاشته شده توسط مت هابز ، تقریباً 18 درصد از جلسات مرور GOV.UK از نوامبر 2022 DPR 1 را گزارش می‌کنند. در حالی که تصاویر با چگالی بالا آنطور که کاربران انتظار دارند به نظر می‌رسند، اما پهنای باند بسیار بالاتری دارند و هزینه پردازش - نگرانی خاصی برای کاربران دستگاه‌های قدیمی‌تر و کم‌قدرت‌تر که همچنان احتمالاً نمایشگرهایی با چگالی پایین دارند.

استفاده از srcset تضمین می‌کند که تنها دستگاه‌هایی با صفحه‌نمایش با وضوح بالا منابع تصویری را به اندازه کافی بزرگ دریافت می‌کنند تا واضح به نظر برسند، بدون اینکه همان هزینه پهنای باند را به کاربرانی که نمایشگرهایی با وضوح پایین‌تر دارند، منتقل کنند.

ویژگی srcset یک یا چند نامزد جدا شده با کاما را برای رندر کردن یک تصویر شناسایی می کند. هر نامزد از دو چیز تشکیل شده است: یک URL، درست مانند آنچه در src استفاده می کنید، و یک نحو که منبع تصویر را توصیف می کند . هر نامزد در srcset با عرض ذاتی آن (" نحو w ") یا چگالی مورد نظر (" نحو x ") توصیف می شود.

دستور x مخفف عبارت "این منبع برای نمایشگری با این چگالی مناسب است" است - یک نامزد به دنبال 2x برای نمایشگر با DPR 2 مناسب است.

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

مرورگرهایی که از srcset پشتیبانی می‌کنند با دو نامزد ارائه می‌شوند: double-density.jpg ، که 2x برای نمایشگرهایی با DPR 2 مناسب است، و low-density.jpg در ویژگی src - نامزد انتخاب می‌شود اگر چیزی مناسب‌تر پیدا نشد. در srcset . برای مرورگرهایی که از srcset پشتیبانی نمی‌کنند، ویژگی و محتویات آن نادیده گرفته می‌شود—محتوای src طبق معمول درخواست می‌شود.

اشتباه کردن مقادیر مشخص شده در ویژگی srcset برای دستورالعمل آسان است. آن 2x به مرورگر اطلاع می دهد که فایل منبع مرتبط برای استفاده در نمایشگری با DPR 2 - اطلاعات مربوط به خود منبع - مناسب است. به مرورگر نمی‌گوید چگونه از آن منبع استفاده کند، فقط به مرورگر اطلاع می‌دهد که چگونه می‌توان از منبع استفاده کرد. این یک تمایز ظریف اما مهم است: این یک تصویر با چگالی دوگانه است، نه تصویری برای استفاده در نمایشگر با چگالی دوگانه.

تفاوت بین نحوی که می گوید "این منبع برای نمایشگرهای 2x مناسب است" و دستوری که می گوید "از این منبع در نمایشگرهای 2x استفاده کنید" در چاپ ناچیز است، اما چگالی نمایش تنها یکی از تعداد زیادی از عوامل مرتبط به هم است که مرورگر از آن استفاده می کند. برای تصمیم گیری در مورد نامزدی که باید ارائه شود، که فقط برخی از آنها را می توانید بدانید. به‌عنوان مثال: به‌صورت جداگانه، این امکان برای شما وجود دارد که تعیین کنید که کاربر یک اولویت مرورگر صرفه‌جویی در پهنای باند را از طریق پرس‌وجو رسانه prefers-reduced-data فعال کرده است، و از آن استفاده کنید تا همیشه کاربران را صرف نظر از چگالی نمایشگرشان به تصاویر با چگالی پایین انتخاب کنید. اما اگر به‌طور مداوم توسط هر توسعه‌دهنده و در هر وب‌سایت پیاده‌سازی نشود، برای کاربر مفید نخواهد بود. آنها ممکن است ترجیح خود را در یک سایت مورد احترام قرار دهند و در سایت بعدی به دیواری از تصاویر که پهنای باند را محو می کند برخورد کنند.

الگوریتم انتخاب منبع به طور عمدی مبهم مورد استفاده توسط srcset / sizes فضایی را برای مرورگرها ایجاد می کند تا تصمیم بگیرند تصاویری با چگالی کمتر با کاهش پهنای باند یا بر اساس ترجیح برای به حداقل رساندن استفاده از داده انتخاب کنند، بدون اینکه ما مسئولیت چگونگی، زمان، یا در چه زمانی را بر عهده بگیریم. آستانه. هیچ معنایی ندارد که مسئولیت‌ها و کارهای اضافی را بپذیرید که مرورگر برای انجام آن‌ها مجهزتر باشد.

توصیف عرض با w

srcset نوع دوم توصیفگر را برای نامزدهای منبع تصویر می پذیرد. این بسیار قدرتمندتر است - و برای اهداف ما، درک آن بسیار آسان تر است. به جای علامت گذاری یک نامزد به عنوان دارای ابعاد مناسب برای یک چگالی نمایش داده شده، نحو w عرض ذاتی هر منبع کاندید را توصیف می کند. باز هم، هر نامزد به جز ابعادشان یکسان است - همان محتوا، برش یکسان و نسبت ابعاد یکسان. اما در این مورد، می‌خواهید مرورگر کاربر بین دو نامزد انتخاب کند: small.jpg، منبعی با عرض ذاتی 600 پیکسل، و large.jpg، منبعی با عرض ذاتی 1200 پیکسل.

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

این به مرورگر نمی‌گوید که با این اطلاعات چه کند - فقط فهرستی از نامزدها را برای نمایش تصویر به آن ارائه می‌دهد. قبل از اینکه مرورگر بتواند تصمیم بگیرد که کدام منبع را رندر کند، باید کمی اطلاعات بیشتری در اختیار آن قرار دهید: توضیحی درباره نحوه رندر شدن تصویر در صفحه. برای انجام این کار، از ویژگی sizes استفاده کنید.

شرح کاربرد با sizes

مرورگرها در انتقال تصاویر عملکرد فوق العاده ای دارند. درخواست‌ها برای دارایی‌های تصویر مدت‌ها قبل از درخواست‌ها برای شیوه نامه یا جاوا اسکریپت آغاز می‌شوند - اغلب حتی قبل از تجزیه کامل نشانه‌گذاری. وقتی مرورگر این درخواست‌ها را انجام می‌دهد، به غیر از نشانه‌گذاری، هیچ اطلاعاتی در مورد خود صفحه ندارد - حتی ممکن است هنوز درخواست‌هایی را برای شیوه‌نامه‌های خارجی شروع نکرده باشد، چه رسد به اعمال آنها. در زمانی که مرورگر نشانه‌گذاری شما را تجزیه می‌کند و شروع به درخواست‌های خارجی می‌کند، فقط اطلاعاتی در سطح مرورگر دارد: اندازه درگاه دید کاربر، تراکم پیکسل صفحه نمایش کاربر، تنظیمات برگزیده کاربر و غیره.

این چیزی به ما نمی گوید که چگونه یک تصویر در نظر گرفته شده است تا در طرح بندی صفحه نمایش داده شود - حتی نمی تواند از viewport به عنوان یک پروکسی برای کران بالای اندازه img استفاده کند، زیرا ممکن است یک محفظه اسکرول افقی را اشغال کند. بنابراین باید این اطلاعات را در اختیار مرورگر قرار دهیم و این کار را با استفاده از نشانه گذاری انجام دهیم. این تمام چیزی است که ما می توانیم برای این درخواست ها استفاده کنیم.

مانند srcset ، sizes برای در دسترس قرار دادن اطلاعات مربوط به یک تصویر به محض تجزیه نشانه گذاری در نظر گرفته شده است. همانطور که مشخصه srcset مخفف عبارت "اینجا فایل های منبع و اندازه های ذاتی آنها هستند" است، ویژگی sizes مختص "اینجا اندازه تصویر رندر شده در طرح بندی است." روشی که شما تصویر را توصیف می‌کنید نسبت به درگاه دید است - باز هم، اندازه درگاه نمایش تنها اطلاعات طرح‌بندی است که مرورگر هنگام درخواست تصویر در اختیار دارد.

این ممکن است در چاپ کمی پیچیده به نظر برسد، اما درک آن در عمل بسیار ساده تر است:

<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. تصویر متوسط ​​ما 1200 پیکسل عرض دارد: 1200÷800=1.5. بزرگترین تصویر ما 2000 پیکسل عرض دارد: 2000÷800=2.5.

نتایج این محاسبات ( .75 ، 1.5 و 2.5 ) عملاً گزینه‌های DPR هستند که به طور خاص برای اندازه دید کاربر طراحی شده‌اند . از آنجایی که مرورگر اطلاعات مربوط به تراکم نمایشگر کاربر را نیز در اختیار دارد، یک سری تصمیم می گیرد:

در این اندازه نما، کاندید small.jpg صرف نظر از چگالی نمایش کاربر کنار گذاشته می شود - با DPR محاسبه شده کمتر از 1 ، این منبع برای هر کاربری نیاز به ارتقاء مقیاس دارد، بنابراین مناسب نیست. در دستگاهی با DPR 1 ، medium.jpg نزدیک‌ترین تطابق را ارائه می‌کند—این منبع برای نمایش با DPR 1.5 مناسب است، بنابراین کمی بزرگ‌تر از حد لازم است، اما به یاد داشته باشید که کاهش مقیاس یک فرآیند بصری یکپارچه است. در دستگاهی با DPR 2، large.jpg نزدیکترین تطابق است، بنابراین انتخاب می شود.

اگر همان تصویر در یک نمای 600 پیکسلی نمایش داده شود، نتیجه همه این ریاضیات کاملاً متفاوت خواهد بود: 80vw اکنون 480 پیکسل است. وقتی عرض منابع خود را بر آن تقسیم می کنیم، 1.25 ، 2.5 و 4.1666666667 به دست می آید. در این اندازه نمای، small.jpg در دستگاه‌های 1x انتخاب می‌شود و medium.jpg در دستگاه‌های 2x مطابقت دارد.

این تصویر در تمام این زمینه‌های مرور یکسان به نظر می‌رسد: همه فایل‌های منبع ما جدا از ابعادشان دقیقاً یکسان هستند و هر کدام به همان وضوحی که تراکم نمایش کاربر اجازه می‌دهد ارائه می‌شوند. با این حال، به جای ارائه large.jpg به هر کاربر به منظور تطبیق بزرگترین درگاه‌های دید و نمایشگرهای با بالاترین تراکم، کاربران همیشه به کوچک‌ترین نامزد مناسب ارائه می‌شوند. با استفاده از یک نحو توصیفی به جای دستوری، نیازی به تنظیم دستی نقاط انفصال و در نظر گرفتن دیدگاه‌ها و DPRهای آینده ندارید—شما فقط اطلاعاتی را به مرورگر ارائه می‌دهید و به آن اجازه می‌دهید پاسخ‌ها را برای شما تعیین کند.

از آنجا که مقدار sizes ما نسبت به viewport و کاملا مستقل از طرح بندی صفحه است، یک لایه پیچیدگی اضافه می کند. به ندرت تصویری وجود دارد که تنها درصدی از نمای را اشغال کند، بدون هیچ گونه حاشیه با عرض ثابت، بالشتک یا تأثیری از عناصر دیگر در صفحه. شما اغلب نیاز دارید که عرض یک تصویر را با استفاده از ترکیبی از واحدها بیان کنید. درصد، 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 از دو طرف، در ویوپورت‌های بالاتر از 1200 پیکسل - در نماهای کوچک‌تر، تمام عرض درگاه دید را اشغال می‌کند.

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

اگر نمای کاربر بزرگتر از 1200 پیکسل باشد، 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 یا syntax sizes هرگز درخواست منبعی با ابعاد کوچک‌تر از منبعی را که کاربر قبلاً در حافظه پنهان مرورگر خود دارد، آزار نمی‌دهد. وقتی مرورگر می تواند منبع تصویری را که قبلاً در اختیار دارد، به طور یکپارچه کاهش دهد، درخواست جدید برای منبعی که به نظر یکسان باشد، چه فایده ای دارد؟ اما اگر کاربر برای جلوگیری از افزایش مقیاس، نمای خود را تا جایی که به یک تصویر جدید نیاز است، تغییر دهد، آن درخواست همچنان انجام می‌شود، بنابراین همه چیز همانطور که انتظار دارید به نظر می‌رسد.

این عدم کنترل صریح می‌تواند در ظاهر کمی ترسناک به نظر برسد، اما از آنجایی که شما از فایل‌های منبع با محتوای یکسان استفاده می‌کنید، به احتمال زیاد نسبت به یک src تک منبعی، تجربه‌ای «شکسته» به کاربران ارائه نمی‌کنیم. ، صرف نظر از تصمیمات اتخاذ شده توسط مرورگر.

استفاده از sizes و srcset

این اطلاعات زیادی است - هم برای شما، هم برای خواننده و هم برای مرورگر. srcset و sizes هر دو نحوی متراکم هستند که مقدار تکان دهنده ای از اطلاعات را با کاراکترهای نسبتا کمی توصیف می کنند. یعنی، خوب یا بد، با طراحی: کم‌تر بودن این نحوها – و تجزیه آسان‌تر توسط ما انسان‌ها – می‌تواند تجزیه آنها را برای مرورگر دشوارتر کند. هرچه پیچیدگی بیشتری به یک رشته اضافه شود، پتانسیل بیشتری برای خطاهای تجزیه کننده یا تفاوت های ناخواسته در رفتار از یک مرورگر به مرورگر دیگر وجود دارد. با این حال، یک نکته مثبت در اینجا وجود دارد: نحوی که توسط ماشین‌ها راحت‌تر خوانده می‌شود، نحوی است که به راحتی توسط آنها نوشته می‌شود.

srcset یک مورد واضح برای اتوماسیون است. به ندرت پیش می‌آید که چندین نسخه از تصاویر خود را برای یک محیط تولید ایجاد کنید، در عوض فرآیند را با استفاده از یک Task Runner مانند Gulp، یک باندلر مانند Webpack، یک CDN شخص ثالث مانند Cloudinary یا عملکردی که قبلاً در شما تعبیه شده است، خودکار کنید. CMS انتخابی با توجه به اطلاعات کافی برای تولید منابع ما در وهله اول، یک سیستم اطلاعات کافی برای نوشتن آنها در یک ویژگی srcset قابل اجرا خواهد داشت.

خودکار کردن sizes کمی دشوارتر است. همانطور که می دانید، تنها راهی که یک سیستم می تواند اندازه یک تصویر را در یک طرح رندر شده محاسبه کند، رندر کردن طرح است. خوشبختانه، تعدادی از ابزارهای توسعه‌دهنده ظاهر شده‌اند تا فرآیند ویژگی‌های sizes دست‌نویس را انتزاعی کنند - با کارایی که هرگز نمی‌توانید با دست مطابقت دهید. به عنوان مثال، respImageLint یک قطعه کد است که برای بررسی ویژگی های sizes شما از نظر دقت و ارائه پیشنهادهایی برای بهبود در نظر گرفته شده است. پروژه Lazysizes با به تعویق انداختن درخواست‌های تصویر تا پس از ایجاد طرح‌بندی، سرعت را برای کارایی به خطر می‌اندازد و به جاوا اسکریپت اجازه می‌دهد تا مقادیر sizes را برای شما ایجاد کند. اگر از یک چارچوب رندر کاملاً سمت کلاینت مانند React یا Vue استفاده می‌کنید، راه‌حل‌های متعددی برای نوشتن و/یا ایجاد ویژگی‌های srcset و sizes وجود دارد که در CMS و Frameworks در مورد آنها بیشتر بحث خواهیم کرد.