تصاویر DPI بالا برای تراکم پیکسلی متغیر

Boris Smus

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

• تنوع زیاد دستگاه ها با فاکتورهای فرم متفاوت.
• پهنای باند شبکه و عمر باتری محدود.

از نظر تصاویر، هدف توسعه دهندگان برنامه های وب ارائه تصاویر با بهترین کیفیت به بهترین نحو ممکن است . این مقاله چند تکنیک مفید برای انجام این کار امروز و در آینده نزدیک را پوشش می دهد.

در صورت امکان از تصاویر خودداری کنید

قبل از باز کردن این قوطی کرم، به یاد داشته باشید که وب دارای فناوری‌های قدرتمند بسیاری است که تا حد زیادی مستقل از رزولوشن و DPI هستند. به طور خاص، متن، SVG و بسیاری از CSS به دلیل ویژگی مقیاس خودکار پیکسل در وب (از طریق devicePixelRatio ) فقط کار می کنند.

گفته می شود، همیشه نمی توانید از تصاویر شطرنجی اجتناب کنید. به عنوان مثال، ممکن است دارایی هایی به شما داده شود که تکرار آنها در SVG/CSS خالص بسیار سخت است، یا با یک عکس سروکار دارید. در حالی که می‌توانید تصویر را به‌طور خودکار به SVG تبدیل کنید، بردار کردن عکس‌ها منطقی نیست زیرا نسخه‌های کوچک‌شده معمولاً خوب به نظر نمی‌رسند.

پس زمینه

تاریخچه بسیار کوتاهی از تراکم نمایشگر

در روزهای اولیه، نمایشگرهای رایانه دارای تراکم پیکسلی 72 یا 96dpi ( نقطه در هر اینچ ) بودند.

نمایشگرها به تدریج در تراکم پیکسلی بهبود یافتند که عمدتاً به دلیل استفاده از تلفن همراه است که در آن کاربران معمولاً تلفن های خود را به صورت خود نزدیک می کنند و پیکسل ها را بیشتر دیده می شود. تا سال 2008، گوشی‌های 150dpi معمولی جدید بودند. روند افزایش تراکم نمایشگر ادامه یافت و گوشی های جدید امروزی دارای نمایشگرهای 300dpi هستند (با نام تجاری اپل "Retina").

جام مقدس، البته، نمایشگری است که در آن پیکسل ها کاملا نامرئی هستند. برای فاکتور فرم تلفن، نسل فعلی نمایشگرهای Retina/HiDPI ممکن است به آن ایده آل نزدیک باشد. اما کلاس‌های جدید سخت‌افزار و پوشیدنی‌ها مانند Project Glass احتمالاً به افزایش تراکم پیکسلی ادامه خواهند داد.

در عمل، تصاویر با چگالی کم باید در صفحه‌های جدید مانند صفحه‌های قدیمی به نظر برسند، اما در مقایسه با تصاویر واضحی که کاربران با چگالی بالا به دیدن آن عادت کرده‌اند، تصاویر با چگالی کم به نظر می‌رسند و پیکسل‌شده به نظر می‌رسند. در زیر یک شبیه‌سازی تقریبی از نحوه نمایش یک تصویر 1x در نمایشگر 2x ارائه شده است. در مقابل، تصویر 2x بسیار خوب به نظر می رسد.

پیکسل ها در وب

زمانی که وب طراحی شد، 99 درصد نمایشگرها 96dpi بودند (یا وانمود می‌کردند که هستند )، و شرایط کمی برای تغییر در این زمینه در نظر گرفته شد. به دلیل تنوع زیاد در اندازه و تراکم صفحه نمایش، ما به یک روش استاندارد برای خوب جلوه دادن تصاویر در انواع تراکم و ابعاد صفحه نیاز داشتیم.

مشخصات HTML اخیراً با تعریف یک پیکسل مرجع که سازندگان برای تعیین اندازه یک پیکسل CSS از آن استفاده می کنند، این مشکل را حل کرده است.

با استفاده از پیکسل مرجع، سازنده می تواند اندازه پیکسل فیزیکی دستگاه را نسبت به پیکسل استاندارد یا ایده آل تعیین کند. به این نسبت نسبت پیکسل دستگاه می گویند.

محاسبه نسبت پیکسل دستگاه

فرض کنید یک تلفن هوشمند صفحه نمایشی با اندازه پیکسل فیزیکی 180 پیکسل بر اینچ (ppi) دارد. محاسبه نسبت پیکسل دستگاه سه مرحله دارد:

1. فاصله واقعی نگه داشتن دستگاه را با فاصله پیکسل مرجع مقایسه کنید.

   با توجه به مشخصات، می دانیم که در 28 اینچ، ایده آل 96 پیکسل در هر اینچ است. با این حال، از آنجایی که این یک تلفن هوشمند است، مردم دستگاه را به صورت خود نزدیک‌تر از لپ‌تاپ نگه می‌دارند. بیایید این فاصله را 18 اینچ تخمین بزنیم.

2. نسبت فاصله را در برابر چگالی استاندارد (96ppi) ضرب کنید تا تراکم پیکسلی ایده آل برای فاصله داده شده بدست آید.

   idealPixelDensity = (28/18) * 96 = 150 پیکسل در اینچ (تقریبا)

3. نسبت تراکم پیکسل فیزیکی را به تراکم پیکسلی ایده آل در نظر بگیرید تا نسبت پیکسل دستگاه را بدست آورید.

   devicePixelRatio = 180/150 = 1.2

بنابراین در حال حاضر زمانی که یک مرورگر باید بداند که چگونه اندازه یک تصویر را برای مطابقت با صفحه نمایش مطابق با وضوح ایده آل یا استاندارد تغییر دهد، مرورگر به نسبت پیکسل دستگاه 1.2 اشاره می کند - که می گوید، برای هر پیکسل ایده آل، این دستگاه 1.2 پیکسل فیزیکی دارد. . فرمول بین پیکسل های ایده آل (همانطور که توسط مشخصات وب تعریف شده است) و پیکسل های فیزیکی (نقاط روی صفحه دستگاه) به شرح زیر است:

physicalPixels = window.devicePixelRatio * idealPixels

از لحاظ تاریخی، فروشندگان دستگاه تمایل به گرد کردن devicePixelRatios (DPR) داشته اند. آیفون و آیپد اپل DPR را 1 گزارش می کنند و معادل های رتینا آن ها 2 را گزارش می دهند. مشخصات CSS توصیه می کند که

واحد پیکسل به کل تعداد پیکسل های دستگاهی اشاره دارد که به بهترین وجه به پیکسل مرجع نزدیک می شود.

یکی از دلایلی که نسبت های گرد می توانند بهتر باشند این است که ممکن است به آرتیفکت های زیر پیکسل کمتری منجر شوند.

با این حال، واقعیت چشم انداز دستگاه بسیار متنوع تر است و تلفن های اندرویدی اغلب دارای DPR 1.5 هستند. تبلت Nexus 7 دارای DPR ~ 1.33 است که با محاسبه ای مشابه با محاسبه بالا به آن رسیده است. انتظار می رود در آینده دستگاه های بیشتری با DPR های متغیر مشاهده شود. به همین دلیل، هرگز نباید فرض کنید که مشتریان شما دارای DPR عدد صحیح هستند.

مروری بر تکنیک های تصویر HiDPI

تکنیک های زیادی برای حل مشکل نمایش تصاویر با بهترین کیفیت در سریع ترین زمان ممکن وجود دارد که به طور کلی به دو دسته تقسیم می شوند:

1. بهینه سازی تک تصاویر و
2. بهینه سازی انتخاب بین چندین تصویر

رویکردهای تک تصویری: از یک تصویر استفاده کنید، اما کاری هوشمندانه با آن انجام دهید. این رویکردها دارای این اشکال هستند که شما به ناچار عملکرد را قربانی خواهید کرد، زیرا تصاویر HiDPI را حتی در دستگاه های قدیمی با DPI پایین تر دانلود خواهید کرد. در اینجا چند رویکرد برای مورد تک تصویر وجود دارد:

• تصویر HiDPI به شدت فشرده شده است
• فرمت تصویر کاملاً عالی
• فرمت تصویر پیشرفته

رویکردهای تصویری چندگانه: از چندین تصویر استفاده کنید، اما کاری هوشمندانه انجام دهید تا بارگیری کنید. این رویکردها سربار ذاتی برای توسعه دهنده دارند تا نسخه های متعددی از یک دارایی ایجاد کند و سپس استراتژی تصمیم گیری را مشخص کند. در اینجا گزینه ها وجود دارد:

• جاوا اسکریپت
• تحویل سمت سرور
• جستارهای رسانه ای CSS
• ویژگی های داخلی مرورگر ( image-set() ، <img srcset> )

تصویر HiDPI به شدت فشرده شده است

تصاویر در حال حاضر 60 درصد از پهنای باندی که برای دانلود یک وب سایت متوسط ​​صرف می شود را شامل می شود . با ارائه تصاویر HiDPI به همه مشتریان، این تعداد را افزایش خواهیم داد. چقدر بزرگتر خواهد شد؟

من چند آزمایش انجام دادم که قطعات تصویر 1x و 2x را با کیفیت JPEG در 90، 50 و 20 تولید کردند .

از این نمونه‌گیری کوچک و غیرعلمی، به نظر می‌رسد که فشرده‌سازی تصاویر بزرگ، یک معاوضه کیفیت به اندازه خوب را فراهم می‌کند. برای چشم من، تصاویر 2x به شدت فشرده شده در واقع بهتر از تصاویر 1x فشرده نشده به نظر می رسند.

البته، ارائه تصاویر 2x با کیفیت پایین و بسیار فشرده به دستگاه های 2x بدتر از ارائه تصاویر با کیفیت بالاتر است و رویکرد فوق جریمه کیفیت تصویر را در پی دارد. اگر کیفیت: 90 تصویر را با کیفیت: 20 عکس مقایسه کنید، شاهد افت تردی و افزایش دانه بندی خواهید بود. این مصنوعات ممکن است در مواردی که تصاویر با کیفیت بالا کلیدی هستند (به عنوان مثال، یک برنامه نمایشگر عکس)، یا برای توسعه دهندگان برنامه که مایل به مصالحه نیستند، قابل قبول نباشند.

مقایسه فوق به طور کامل با JPEG های فشرده انجام شده است. شایان ذکر است که معاوضه های زیادی بین فرمت های تصویری که به طور گسترده پیاده سازی شده اند (JPEG، PNG، GIF) وجود دارد که ما را به…

فرمت تصویر کاملاً عالی

WebP یک فرمت تصویر بسیار جذاب است که به خوبی فشرده می شود و در عین حال وفاداری تصویر را بالا نگه می دارد. البته هنوز همه جا اجرا نشده !

یکی از راه‌ها بررسی پشتیبانی WebP از طریق جاوا اسکریپت است. شما یک تصویر 1 پیکسلی را از طریق data-uri بارگیری می‌کنید، منتظر می‌مانید تا رویدادهای بارگیری یا خطا اجرا شوند و سپس بررسی کنید که اندازه آن درست است. Modernizr با چنین اسکریپت تشخیص ویژگی عرضه می شود که از طریق Modernizr.webp در دسترس است.

با این حال، یک راه بهتر برای انجام این کار، مستقیماً در CSS با استفاده از تابع ()image است. بنابراین اگر شما یک تصویر WebP و JPEG دارید، می توانید موارد زیر را بنویسید:

#pic {
  background: image("foo.webp", "foo.jpg");
}

چند مشکل در این رویکرد وجود دارد. اولا، image() اصلاً به طور گسترده پیاده سازی نشده است. ثانیا، در حالی که فشرده‌سازی WebP JPEG را از آب خارج می‌کند، هنوز یک پیشرفت نسبتاً افزایشی است – بر اساس این گالری WebP حدود 30 درصد کوچک‌تر است. بنابراین، WebP به تنهایی برای رفع مشکل DPI بالا کافی نیست.

فرمت های تصویری پیشرفته

فرمت‌های تصویر پیشرونده مانند JPEG 2000، Progressive JPEG، Progressive PNG و GIF دارای مزیت (تا حدودی بحث‌برانگیز) دیدن تصویر قبل از بارگذاری کامل هستند. آنها ممکن است مقداری سربار متحمل شوند، اگرچه شواهد متناقضی در این مورد وجود دارد. جف اتوود ادعا کرد که حالت پیشرونده "حدود 20٪ به اندازه تصاویر PNG و حدود 10٪ به اندازه تصاویر JPEG و GIF اضافه می کند". با این حال، Stoyan Stefanov ادعا کرد که برای فایل های بزرگ، حالت پیشرونده (در بیشتر موارد) کارآمدتر است.

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

در حالی که پایان دادن به اتصالات آسان است، راه اندازی مجدد آنها اغلب گران است. برای سایتی با تصاویر زیاد، کارآمدترین روش این است که یک اتصال HTTP را زنده نگه دارید و تا زمانی که ممکن است مجدداً از آن استفاده کنید. اگر اتصال پیش از موعد قطع شود زیرا یک تصویر به اندازه کافی دانلود شده است، مرورگر باید یک اتصال جدید ایجاد کند که در محیط‌های با تأخیر کم می‌تواند واقعاً کند باشد.

یک راه حل برای این کار استفاده از درخواست محدوده HTTP است که به مرورگرها اجازه می دهد محدوده ای از بایت ها را برای واکشی مشخص کنند. یک مرورگر هوشمند می‌تواند یک درخواست HEAD برای دریافت هدر، پردازش آن، تصمیم‌گیری در مورد مقدار واقعی تصویر مورد نیاز و سپس واکشی ارسال کند. متأسفانه محدوده HTTP در سرورهای وب ضعیف پشتیبانی می شود و این رویکرد را غیرعملی می کند.

در نهایت، یک محدودیت آشکار این رویکرد این است که شما نمی توانید انتخاب کنید که کدام تصویر را بارگیری کنید، فقط وفاداری های متفاوت همان تصویر. در نتیجه، این مورد به مورد استفاده « جهت هنری » نمی پردازد.

از جاوا اسکریپت برای تصمیم گیری در مورد بارگیری تصویر استفاده کنید

اولین و واضح ترین رویکرد برای تصمیم گیری برای بارگیری تصویر، استفاده از جاوا اسکریپت در مشتری است. این رویکرد به شما امکان می دهد همه چیز را در مورد عامل کاربر خود بدانید و کار درست را انجام دهید. شما می توانید نسبت پیکسل دستگاه را از طریق window.devicePixelRatio تعیین کنید، عرض و ارتفاع صفحه را دریافت کنید، و حتی به طور بالقوه برخی از اتصالات شبکه را از طریق navigator.connection یا صدور یک درخواست جعلی مانند کتابخانه foresight.js انجام دهید. هنگامی که تمام این اطلاعات را جمع آوری کردید، می توانید تصمیم بگیرید که کدام تصویر را بارگیری کنید.

تقریباً یک میلیون کتابخانه جاوا اسکریپت وجود دارد که کارهایی مانند موارد فوق را انجام می دهند و متأسفانه هیچ یک از آنها به ویژه برجسته نیستند.

یکی از ایرادات بزرگ این رویکرد این است که استفاده از جاوا اسکریپت به این معنی است که بارگذاری تصویر را تا پایان تجزیه‌کننده نگاه به آینده به تاخیر می‌اندازید. این اساساً به این معنی است که تصاویر حتی تا زمانی که رویداد pageload فعال نشود، دانلود نمی‌شوند. بیشتر در این مورد در مقاله جیسون گریگزبی .

تصمیم بگیرید که چه تصویری در سرور بارگذاری شود

می‌توانید با نوشتن کنترل‌کننده‌های درخواست سفارشی برای هر تصویری که ارائه می‌کنید، تصمیم‌گیری را به سمت سرور موکول کنید. چنین کنترل کننده ای پشتیبانی Retina را بر اساس User-Agent (تنها اطلاعاتی که به سرور منتقل می شود) بررسی می کند. سپس، بر اساس اینکه آیا منطق سمت سرور می‌خواهد به دارایی‌های HiDPI سرویس دهد یا خیر، شما دارایی مناسب را بارگیری می‌کنید (نام آن بر اساس برخی قراردادهای شناخته شده).

متأسفانه، User-Agent لزوماً اطلاعات کافی برای تصمیم گیری در مورد اینکه آیا دستگاه باید تصاویر با کیفیت بالا یا پایین دریافت کند، ارائه نمی دهد. همچنین ناگفته نماند که هر چیزی که مربوط به User-Agent باشد هک است و در صورت امکان باید از آن اجتناب کرد.

از پرس و جوهای رسانه ای CSS استفاده کنید

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

#my-image { background: (low.png); }

@media only screen and (min-device-pixel-ratio: 1.5) {
  #my-image { background: (high.png); }
}

با ترکیب همه پیشوندهای فروشنده کمی پیچیده تر می شود، به خصوص به دلیل تفاوت های دیوانه کننده در قرار دادن پیشوندهای "min" و "max":

@media only screen and (min--moz-device-pixel-ratio: 1.5),
    (-o-min-device-pixel-ratio: 3/2),
    (-webkit-min-device-pixel-ratio: 1.5),
    (min-device-pixel-ratio: 1.5) {

  #my-image {
    background:url(high.png);
  }
}

با این رویکرد، مزایای تجزیه نگاه به آینده را که با راه حل JS از بین رفته بود، دوباره به دست می آورید. شما همچنین انعطاف پذیری انتخاب نقاط شکست پاسخگو خود را به دست می آورید (به عنوان مثال، می توانید تصاویر DPI کم، متوسط ​​و بالا داشته باشید)، که با رویکرد سمت سرور از بین رفت.

متأسفانه هنوز کمی سخت است و منجر به ظاهر عجیب CSS می شود (یا نیاز به پیش پردازش دارد). همچنین، این رویکرد به ویژگی‌های CSS محدود می‌شود، بنابراین راهی برای تنظیم <img src> وجود ندارد و تصاویر شما باید همه عناصر دارای پس‌زمینه باشند. در نهایت، با تکیه کامل بر نسبت پیکسل دستگاه، می‌توانید در موقعیت‌هایی قرار بگیرید که تلفن هوشمند با DPI بالا در حین اتصال EDGE، یک دارایی تصویر عظیم 2 برابری را دانلود کند. این بهترین تجربه کاربری نیست.

از ویژگی های جدید مرورگر استفاده کنید

اخیراً بحث‌های زیادی در مورد پشتیبانی پلتفرم وب برای مشکل تصویر DPI بالا صورت گرفته است. اپل اخیراً وارد این فضا شد و تابع ()css image-set را به WebKit آورد. در نتیجه، هم سافاری و هم کروم از آن پشتیبانی می‌کنند. از آنجایی که یک تابع CSS است، image-set() مشکل تگ های <img> را برطرف نمی کند. srcset@ را وارد کنید، که به این موضوع می پردازد اما (در زمان نوشتن این مقاله) هیچ پیاده سازی مرجعی (هنوز!) ندارد. بخش بعدی بیشتر به image-set و srcset می رود.

ویژگی های مرورگر برای پشتیبانی از DPI بالا

در نهایت، تصمیم گیری در مورد رویکردی که اتخاذ می کنید به نیازهای خاص شما بستگی دارد. با این حال، به خاطر داشته باشید که همه رویکردهای ذکر شده دارای اشکالاتی هستند. با این حال، به محض اینکه image-set و srcset به طور گسترده پشتیبانی شوند، راه حل مناسبی برای این مشکل خواهند بود. در حال حاضر، اجازه دهید در مورد برخی از بهترین شیوه هایی که می توانند ما را تا حد امکان به آن آینده ایده آل نزدیک کنند، صحبت کنیم.

اولاً، این دو چگونه با هم تفاوت دارند؟ خب، image-set() یک تابع CSS است که برای استفاده به عنوان مقدار خاصیت پس‌زمینه CSS مناسب است. srcset یک ویژگی خاص برای عناصر <img> با نحو مشابه است. هر دوی این تگ‌ها به شما امکان می‌دهند اعلان‌های تصویر را مشخص کنید، اما ویژگی srcset به شما این امکان را می‌دهد تا بر اساس اندازه ویوپورت، تصویر بارگیری را نیز پیکربندی کنید.

بهترین شیوه ها برای مجموعه تصویر

تابع CSS image-set() با پیشوند -webkit-image-set() موجود است. نحو بسیار ساده است، با گرفتن یک یا چند اعلان تصویر جدا شده با کاما، که شامل یک رشته URL یا تابع url() به دنبال وضوح مرتبط است. به عنوان مثال:

background-image:  -webkit-image-set(
  url(icon1x.jpg) 1x,
  url(icon2x.jpg) 2x
);

چیزی که این به مرورگر می گوید این است که دو تصویر برای انتخاب وجود دارد. یکی از آنها برای نمایشگرهای 1x و دیگری برای نمایشگرهای 2x بهینه شده است. اگر مرورگر به اندازه کافی هوشمند باشد (تا آنجا که من می دانم در حال حاضر پیاده سازی نشده است) سپس مرورگر بر اساس عوامل مختلفی که ممکن است شامل سرعت شبکه نیز باشد، انتخاب می کند که کدام یک را بارگیری کند.

مرورگر علاوه بر بارگذاری تصویر صحیح، آن را نیز بر اساس آن مقیاس می کند. به عبارت دیگر، مرورگر فرض می کند که 2 تصویر دو برابر بزرگتر از تصاویر 1x هستند و بنابراین تصویر 2x را با ضریب 2 کاهش می دهد، به طوری که اندازه تصویر در صفحه یکسان به نظر می رسد.

به جای تعیین 1x، 1.5x یا Nx، می‌توانید تراکم پیکسلی دستگاه را بر حسب dpi نیز مشخص کنید.

این به خوبی کار می کند، به جز در مرورگرهایی که از ویژگی image-set پشتیبانی نمی کنند، که اصلاً تصویری را نشان نمی دهد! این به وضوح بد است، بنابراین باید از یک بازگشت (یا یک سری از بازگشت‌ها) برای رفع آن مشکل استفاده کنید:

background-image: url(icon1x.jpg);
background-image: -webkit-image-set(
  url(icon1x.jpg) 1x,
  url(icon2x.jpg) 2x
);
/* This will be useful if image-set gets into the platform, unprefixed.
    Also include other prefixed versions of this */
background-image: image-set(
  url(icon1x.jpg) 1x,
  url(icon2x.jpg) 2x
);

موارد بالا دارایی مناسب را در مرورگرهایی که از مجموعه تصویر پشتیبانی می کنند بارگیری می کند و در غیر این صورت به دارایی 1x می رسد. هشدار آشکار این است که در حالی که پشتیبانی مرورگر image-set() کم است، اکثر عوامل کاربر دارایی 1x را دریافت خواهند کرد.

این نسخه نمایشی از image-set() برای بارگذاری تصویر صحیح استفاده می‌کند و اگر این تابع CSS پشتیبانی نشود، به دارایی 1x می‌رسد.

در این مرحله، ممکن است تعجب کنید که چرا فقط polyfill (یعنی یک شیم جاوا اسکریپت برای) image-set() نمی سازیم و آن را یک روز صدا نمی کنیم؟ همانطور که مشخص است، پیاده سازی polyfills کارآمد برای توابع CSS بسیار دشوار است. (برای توضیح دقیق چرایی، به این بحث www-style مراجعه کنید).

تصویر srcset

در اینجا یک نمونه از srcset آورده شده است:

<img alt="my awesome image"
  src="banner.jpeg"
  srcset="banner-HD.jpeg 2x, banner-phone.jpeg 640w, banner-phone-HD.jpeg 640w 2x">

همانطور که می بینید، علاوه بر اعلان های x که image-set ارائه می کند، عنصر srcset مقادیر w و h را نیز می گیرد که مطابق با اندازه ویوپورت است و سعی می کند مرتبط ترین نسخه را ارائه دهد. موارد بالا banner-phone.jpeg را برای دستگاه‌هایی با عرض دید کمتر از 640 پیکسل، banner-phone-HD.jpeg برای دستگاه‌های DPI با صفحه نمایش کوچک، banner-HD.jpeg برای دستگاه‌های DPI بالا با صفحه‌نمایش بزرگ‌تر از 640 پیکسل و banner.jpeg ارائه می‌کند. به هر چیز دیگری

استفاده از مجموعه تصاویر برای عناصر تصویر

از آنجا که ویژگی srcset در عناصر img در اکثر مرورگرها اجرا نمی شود، ممکن است وسوسه انگیز باشد که عناصر img خود را با <div> با پس زمینه جایگزین کنید و از رویکرد مجموعه تصاویر استفاده کنید. این با اخطارها کار خواهد کرد. اشکال در اینجا این است که تگ <img> دارای ارزش معنایی طولانی مدت است. در عمل، این بیشتر به دلیل خزنده‌های وب و دلایل دسترسی مهم است.

اگر در نهایت از -webkit-image-set استفاده کنید، ممکن است وسوسه شوید که از ویژگی پس‌زمینه CSS استفاده کنید. اشکال این روش این است که شما باید اندازه تصویر را مشخص کنید، که اگر از یک تصویر غیر 1x استفاده می کنید ناشناخته است. به جای انجام این کار، می توانید از ویژگی CSS محتوا به صورت زیر استفاده کنید:

<div id="my-content-image"
  style="content: -webkit-image-set(
    url(icon1x.jpg) 1x,
    url(icon2x.jpg) 2x);">
</div>

این به طور خودکار تصویر را بر اساس devicePixelRatio مقیاس می کند. این مثال از تکنیک بالا را در عمل مشاهده کنید، همراه با یک بازگشت مجدد به url() برای مرورگرهایی که image-set پشتیبانی نمی کنند.

srcset Polyfilling

یکی از ویژگی های مفید srcset این است که دارای یک بازگشت طبیعی است. در مواردی که ویژگی srcset پیاده سازی نشده باشد، همه مرورگرها می دانند که ویژگی src را پردازش کنند. همچنین، از آنجایی که این فقط یک ویژگی HTML است، امکان ایجاد polyfills با جاوا اسکریپت وجود دارد.

این پلی پر با تست های واحد ارائه می شود تا اطمینان حاصل شود که تا حد امکان به مشخصات نزدیک است. علاوه بر این، بررسی هایی وجود دارد که از اجرای کدهای polyfill در صورتی که srcset به صورت بومی پیاده سازی شود، جلوگیری می کند.

در اینجا یک نسخه ی نمایشی از polyfill در عمل آمده است.

نتیجه گیری

هیچ گلوله جادویی برای حل مشکل تصاویر با DPI بالا وجود ندارد.

ساده ترین راه حل این است که به طور کامل از تصاویر اجتناب کنید و به جای آن SVG و CSS را انتخاب کنید. با این حال، این همیشه واقع بینانه نیست، به خصوص اگر تصاویری با کیفیت بالا در سایت خود داشته باشید.

رویکردها در JS، CSS و استفاده از سمت سرور همگی نقاط قوت و ضعف خود را دارند. با این حال، امیدوار کننده ترین رویکرد، استفاده از ویژگی های جدید مرورگر است. اگرچه پشتیبانی مرورگر برای image-set و srcset هنوز ناقص است، اما امروزه گزینه‌های جایگزین منطقی برای استفاده وجود دارد.

به طور خلاصه، توصیه های من به شرح زیر است:

• برای تصاویر پس‌زمینه، از مجموعه تصاویر با بازگردانی مناسب برای مرورگرهایی که از آن پشتیبانی نمی‌کنند استفاده کنید.
• برای تصاویر محتوا، از یک srcset polyfill استفاده کنید یا از مجموعه تصاویر استفاده کنید (به بالا مراجعه کنید).
• برای موقعیت‌هایی که می‌خواهید کیفیت تصویر را قربانی کنید، استفاده از تصاویر 2x به شدت فشرده شده را در نظر بگیرید.