关于前端:学习图片11描述性语法

8次阅读

共计 7161 个字符，预计需要花费 18 分钟才能阅读完成。

本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一工夫和你分享前端行业趋势，学习路径等等。
更多开源作品请看 GitHub https://github.com/qq449245884/xiaozhi，蕴含一线大厂面试残缺考点、材料以及我的系列文章。

应用 srcset 和sizes来向浏览器提供无关图像起源和它们如何被应用的信息。

在这个模块中，咱们将学习如何为浏览器提供一系列图像抉择，以便它能够做出最佳的显示决策。srcset不是在特定断点切换图像源的办法，也不是为了将一张图像换成另一张。这些语法容许浏览器独立地解决一个十分艰难的问题：无缝地申请和渲染一个适宜用户浏览上下文的图像源，包含视口大小、显示密度、用户偏好、带宽和一些其余因素。

这是一个微小的要求 – 当咱们只是简略地标记一个图像的时候，它必定超出了咱们的设想范畴，并且做得好须要比咱们可能拜访的信息更多。

一个固定宽度的 <img> 在任何浏览上下文中占据的视口空间雷同，无论用户显示器的密度（屏幕上的物理像素数量）如何。例如，固有宽度为 400px 的图像在原始的 Google Pixel 和较新的 Pixel 6 Pro 上简直占据整个浏览器视口 – 这两个设施都有一个标准化的 412px 逻辑像素宽的视口。

然而，Pixel 6 Pro 具备更清晰的显示：6 Pro 的物理分辨率为 1440×3120 像素，而 Pixel 为 1080×1920 像素，即形成屏幕自身的硬件像素数量。

设施的逻辑像素和物理像素之间的比率是该显示的设施 像素比（DPR）。DPR 是通过将视口的 CSS 像素除以设施的理论屏幕分辨率来计算的。

因而，原始 Pixel 的 DPR 为2.6，而 Pixel 6 Pro 的 DPR 为3.5。

Phone 4 是第一个 DPR 大于 1 的设施，报告的设施像素比为2– 屏幕的物理分辨率是逻辑分辨率的两倍。在 iPhone 4 之前的任何设施的 DPR 为 1：一个逻辑像素对一个物理像素。

如果你在 DPR 为 2 的显示器上查看该 400 像素宽的图像，则每个逻辑像素被出现在显示器的四个物理像素上：两个程度和两个垂直。图像不会从高密度显示中受害 – 它在 DPR 为 1 的显示器上看起来与在 DPR 为 2 的显示器上看起来雷同。

当然，浏览器渲染引擎绘制的任何内容 – 如文本、CSS 形态或 SVG – 都将被绘制以适应高密度显示器。然而，从图像格式和压缩中学到的常识，光栅图像是固定的像素网格。只管可能不总是非常明显，但针对高密度显示放大的光栅图像会与四周页面相比看起来低分辨率。

为了避免这种放大，正在渲染的图像必须具备至多 800 个像素的固有宽度。当放大以适应 400 个逻辑像素宽的布局空间时，该 800 像素图像源具备双倍的像素密度 – 在具备 DPR 为 2 的显示器上，它看起来很清晰。

地址:https://codepen.io/web-dot-dev/pen/QWBGVyo

因为 DPR 为 1 的显示屏无奈利用图像的减少密度，因而图像将被放大以匹配显示屏。如你所知，放大的图像看起来也很好。在低密度显示器上，实用于高密度显示器的图像看起来就像任何其余低密度图像。

在《图像和性能》中所学到的，应用放大到 400px 的图像源的低密度显示器用户只须要一个固有宽度为 400px 的源。尽管更大的图像对所有用户来说都可视，但在小型低密度显示屏上渲染的微小高分辨率图像源将看起来像任何其余小型低密度图像，但速度要慢得多。

具备 DPR 为 1 的挪动设施十分常见，只管在“桌面”浏览环境中依然很常见。依据 Matt Hobbs 共享的数据，约 18% 的 GOV.UK 浏览会话从 2022 年 11 月开始报告 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 的浏览器将渲染两个备选项：high-density.jpg，其中 2x 实用于 DPR 为 2 的显示器，以及 src 属性中的 low-density.jpg，如果在srcset 中找不到更适合的备选项，则抉择该备选项。对于不反对 srcset 的浏览器，将疏忽该属性及其内容，通常会申请 src 的内容。

很容易将 srcset 属性中指定的值误会为指令。2x告知浏览器相干源文件实用于 DPR 为 2 的显示器 - 无关源自身的信息。它不通知浏览器如何应用该源，只是告知浏览器该源能够如何应用。这是一个奥妙但重要的区别：这是一个双倍密度图像，而不是用于双倍密度显示器的图像。

指定“此源实用于 2 倍显示器”和指定“在 2 倍显示器上应用此源”之间的语法差别很小，但显示密度只是浏览器用于决定要渲染的备选项的泛滥互相关联因素之一，其中只有一些你可能晓得。

例如：独自地，咱们能够确定用户通过 prefers-reduced-data 媒体查问启用了节俭带宽的浏览器偏好设置，并应用它来始终抉择低密度图像，而不思考其显示密度 - 但除非每个开发人员在每个网站上都统一地施行它，否则对用户来说没有多大用处。他们可能会在一个网站上尊重他们的偏好，并在下一个网站上遇到一个毁坏带宽的图像墙。

srcset / sizes应用的成心含糊的资源抉择算法为浏览器留出了空间，以决定抉择低密度图像以实现带宽降落，或基于最小化数据应用的偏好而抉择。咱们不须要对如何、何时以及在什么阈值下承担责任。承当浏览器更适宜为咱们解决的责任和额定工作是没有意义的。

srcset 能够承受第二种类型的描述符，用于图像源候选项。这是一种更加弱小的描述符，而且对于咱们的目标来说，更容易了解。与标记候选项具备适当尺寸以适应给定显示密度不同，w 语法形容每个候选源的固有宽度。同样，每个候选项都是雷同的，除了它们的尺寸 – 雷同的内容，雷同的裁剪和雷同的纵横比。但在这种状况下，你心愿用户的浏览器在两个候选项之间进行抉择：具备固有宽度为 600px 的 small.jpg，和具备固有宽度为 1200px 的 large.jpg。

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

这并没有通知浏览器如何解决这些信息 – 只是提供了一个显示图像的候选项列表。在浏览器能够决定渲染哪个源之前，你须要提供更多的信息：一个形容图像在页面上将如何渲染的阐明。为此，请应用 sizes 属性。

在传输图像方面，浏览器体现出极高的性能。对于图像资源的申请将在样式表或 JavaScript 的申请之前启动 – 通常甚至在标记语言被齐全解析之前就曾经开始了。当浏览器发动这些申请时，除了标记语言之外，它对页面自身没有任何信息 – 它甚至可能尚未启动对外部样式表的申请，更别提利用它们了。在浏览器解析你的标记语言并开始收回内部申请的时候，它只有浏览器级别的信息：用户视口的大小，用户显示器的像素密度，用户偏好等等。

这并没有通知咱们无关图像在页面布局中应该如何渲染的任何信息 – 它甚至不能将视口用作 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%”。

示例：https://codepen.io/web-dot-dev/pen/PoBWLYP

作为开发人员，咱们的工作曾经实现了。咱们曾经精确地形容了 srcset 中候选源列表和 sizes 中图像的宽度，就像在 srcset 中的 x 语法一样，剩下的就由浏览器来解决了。

然而为了充沛了解这些信息是如何应用的，让咱们花点工夫来剖析用户浏览器在遇到这些标记时做出的决策：

咱们通知浏览器，这个图像将占用可用视口的 80%。因而，如果咱们在一个宽度为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 提供了最靠近的匹配——该源实用于 1.5 的 DPR 显示，因而它比必要的稍大，但请记住，放大是一个视觉上无缝的过程。在一个 DPR 为 2 的设施上，抉择 large.jpg 作为最靠近的匹配项。

如果同一图像在 600 像素宽的视口上渲染，所有这些数学计算的后果将齐全不同：80vw 当初是 480px。当咱们把咱们的源的宽度除以它时，咱们失去1.25、2.5 和4.1666666667。在这个视口大小下，小型 small.jpg 将在 1x 设施上抉择，而medium.jpg 将在 2x 设施上匹配。

这张图片在所有浏览上下文中看起来都是雷同的：咱们的所有源文件除了尺寸之外都完全相同，每一个都会被渲染成用户的显示密度所容许的尽可能锐利的图像。然而，与其为了适应最大的视口和最高密度的显示器向每个用户提供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 属性，而后利用指定的值。

假如你有一张图片，心愿在 1200 像素以上的视口上占据视口宽度的 80%，左右各有一个em 的内边距，在较小的视口上则占据视口的全副宽度。

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

示例：https://codepen.io/web-dot-dev/pen/RwBoYRx

如果用户的视口大于 1200px，calc(80vw - 2em) 形容了咱们布局中图片的宽度。如果 (min-width: 1200px) 条件不匹配，浏览器就会转到下一个值。因为没有一个特定的媒体条件与这个值相分割，所以 100vw 被作为默认值应用。如果你应用 max-width 媒体查问来编写这个 sizes 属性：”

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

示例：https://codepen.io/web-dot-dev/pen/BaPQOzO

简略来说，(max-width: 1200px)是否匹配？如果不匹配，持续。下一个值 calc（80vw - 2em）没有限定条件，因而这是被选中的。

当初，咱们曾经向浏览器提供了对于图像元素的所有这些信息 – 潜在起源、外在宽度以及打算向用户渲染图像的形式 – 浏览器应用含糊的规定来确定如何解决这些信息。

在 HTML 标准中编码的源抉择算法在抉择源的形式上是明确含糊的。一旦源、它们的描述符和图像的渲染形式都被解析了，浏览器就能够自在地做任何它想做的事件，咱们不能确定浏览器会抉择哪个源。

一种语法，它说“在高分辨率显示器上应用此源”，可能是可预测的，但它不会解决响应式布局中图像的外围问题：保留用户带宽。屏幕像素密度只与互联网连贯速度有较弱的相关性，如果有的话。如果你应用顶级笔记本电脑，但通过计量连贯、通过你的手机连贯或应用不稳固的飞机 WiFi 连贯浏览网络，你可能想抉择低分辨率的图像源，无论你的显示器品质如何。

把最终决定留给浏览器容许进行比咱们通过严格的预约语法进行的性能改良更多的性能改良。例如：在大多数浏览器中，应用 srcset 或sizes语法的 img 永远不会申请比用户曾经在浏览器缓存中领有的源更小的尺寸的源。当浏览器能够无缝地放大它曾经领有的图像源时，为什么要为一个看起来雷同的源收回新申请呢？然而，如果用户将其视口缩放到须要新图像能力防止缩放的水平，那么仍将进行该申请，以便所有看起来合乎咱们的冀望。

尽管这种不足明确控制权可能听起来有点可怕，然而因为咱们正在应用具备雷同内容的源文件，与浏览器的决策无关，咱们不太可能向用户渲染“破碎”的体验，就像单源 src 一样。

信息量有点多了。srcset和 sizes 都是密集的语法，用绝对较少的字符形容了大量信息。也就是说，无论好坏如何，这是通过设计的：使这些语法不那么简洁，更容易被咱们人类解析，可能会使它们更难被浏览器解析。字符串中增加的复杂性越多，就越有可能呈现解析器谬误或不同浏览器之间行为意外不同的状况。然而，这里有一个益处：对机器来说更容易浏览的语法对它们来说也更容易编写。

对于 srcset 来说，这是一个明确的自动化案例。很少有人会手工制作多个版本的图像以用于生产环境，而是应用相似 Gulp 这样的工作运行器、Webpack 这样的捆绑器、第三方 CDN（如 Cloudinary）或曾经内置在您抉择的 CMS 中的性能来自动化该过程。只有提供足够的信息来生成咱们的资源，零碎就有足够的信息将它们写入可行的 srcset 属性中。

对于 sizes 来说，自动化要艰难一些。零碎计算图像在渲染布局中的大小的惟一办法是已渲染布局。侥幸的是，呈现了许多开发人员工具，将手写 sizes 属性的过程抽象化，效率远远超过手动编写。例如，respImageLint 是一段代码片段，旨在审核咱们的 sizes 属性是否精确，并提供改良倡议。

Lazysizes 我的项目通过推延图像申请直到布局建设后，容许 JavaScript 为咱们生成 sizes 值，以效率为代价实现了一些速度。如果你正在应用齐全客户端党建框架（如 React 或 Vue），则有许多解决方案可用于编写和 / 或生成 srcset 和sizes属性，咱们将在 CMS 和框架中进一步探讨这些解决方案。

代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。