共计 29150 个字符，预计需要花费 73 分钟才能阅读完成。
自从驰名设计师 Ethan Marcotte（@beep）在 A List Apart 上发表了一篇名为《Responsive Web Design》的文章之后，响应式网页设计（RWD，即 Responsive Web Design）的身影就呈现在了公众背后。自此就有了响应式 Web 设计这个概念。从提出这个概念到明天曾经有十多年的工夫了。在这十多年来，CSS 也产生了微小的变动，新增了很多新的个性，近两年尤其如此，近两年尤其如此（具体请参阅《2022 年的 CSS》一文）。这些变动，对于响应式 Web 设计的开发也有较大的扭转。Una Kravets（@Una）大神，在 2021 的 Google I/O 大会上的分享，提出 新的响应式：组件驱动式 Web 设计。Web 生态行将进入响应式 Web 设计的新时代，并转变咱们对其含意的认识，也为会 Web 设计带来新的变动。组件式驱动 Web 设计（或开发）也被称为是下一代响应式 Web 设计（或开发）。如果你对这方面话题感兴趣的话，请持续往下浏览。
文章链接：
《Responsive Web Design》
《2022 年的 CSS》
《新的响应式：组件驱动式 Web 设计》
响应式 Web 设计的倒退历程
既然要聊响应式 Web 设计，那么咱们就花一点篇幅和工夫简略地理解一下其倒退历程。家喻户晓，自从 Tim Berners-Lee 创立第一个 Web 页面（大概在 1991 年 8 月份左右）到 90 年代末，Web 页面都是十分简陋的：
直到 90 年代末 20 年代初，Web 设计和用户体验随着 CSS 的到来才缓缓地有了美感，Web 页面看起来开始像咱们明天应用的网站：
正如上图所示，越往后，Web 的 UI 越来越丰盛，越来越丑陋。这也让 Web 开发人员不得不在布局、设计和排版等方面破费更多的工夫。尽管 Web 开发人员为 Web 布局破费不少工夫，但在这个过程中，也积攒了很多不同的布局办法。在晚期，Web 开发人员次要采纳 固定宽度 和 流式布局 两种布局计划来实现 Web 页面的布局。特地是流式布局，自 Glenn Davis 提出和推广之后，堪称是轰动一时，并且长期以来，都认为流式布局就是响应式 Web 布局。流式布局（Liquid Layout）能够调整 Web 页面尺寸以适应不同的显示器分辨率或浏览器窗口的大小。来看一个流式布局的简略示例：
Liquid Page Layout Example@nickpettitCodePen
但流式布局并不是完满的。应用流式布局的 Web 页面上，内容可能会溢出，在较小的屏幕上文字可能会换行，在较大的屏幕上可能会有很多不用的空白。
大多数流体布局在 800px x 600px 到 1280px 宽或更大的屏幕分辨率下看起来还不错。然而，如果咱们能把它宰割得更细一些，比方为 800px ~ 1024px、1024px ~ 1280px 以及 1280px 以上的分辨率提供不同的定制布局，那成果会更佳。同样，对于 640px ~ 800px、320px ~ 640px、240px ~ 320px 以及 240px 以下的分辨率也能够定制不同的布局。
大概在 2004 年的时候，Cameron Adams（@themaninblue）在他的博文《Resolution dependent layout》提出了基于屏幕分辨率来动静构建 Web 布局，即 应用 JavaScript 依据浏览器窗口大小加载不同 CSS 文件。
<!-- Narrow style sheet -->
<link rel="alternate stylesheet" type="text/css" href="css/narrow.css"
title="narrow"/>
<!-- Default style sheet -->
<link rel="stylesheet" type="text/css" href="css/normal.css" title="default"/>
<!-- Wide style sheet -->
<link rel="alternate stylesheet" type="text/css" href="css/wide.css"
title="wide"/>
<!-- Included JavaScript to switch style sheets -->
<script src="scripts/dynamiclayout.js" type="text/javascript"></script>留神，在所有 <link> 标签上 title 属性的值别离为 narrow、default 和 wide，并且在 dynamiclayout.js 中有一个 DynamicLayout() 函数，将会依据 <link> 标签的 title 属性的值来调用不同的样式表：
function dynamicLayout(){var browserWidth = getBrowserWidth();
// Narrow CSS rules
if (browserWidth < 640){changeLayout("narrow");
}
// Normal (default) CSS rules
if ((browserWidth >= 640) && (browserWidth <= 960)){changeLayout("default");
}
// Wide CSS rules
if (browserWidth > 960){changeLayout("wide");
}
}@Kevin Hale 的博文《Dynamic Resolution Dependent Layouts》具体介绍该技术。
这种布局技术起初就以 Cameron Adams 博客文章题目命名，被称为 分辨率相干的布局。这种布局技术尽管会额定减少开发者（开发者须要为不同定制的布局提供不同样式表）工作量，但在 CSS 媒体查问风行之前还是很受欢迎的。它也被称为是晚期的 CSS 媒体查问（通过 JavaScript 查问断点）。
尽管这种依赖动静分辩率布局的计划能够在不同的分辨率下提供更佳的体验，但随着 2005 年 08 月 10 日 Opera 软件公司推出 Opera Mini 和 2007 年 01 月 09 是第一台 iPhone 手机的呈现，市场上不同品牌，不同分辨率的挪动端以及品牌商本人的 Web 浏览器就越来越多。
在这种环境之下，基于动静分辨率加载不同的样式表已不太事实，Web 开发者不得不想出其余的计划来适应不同的屏幕尺寸。在很长一段时间，甚至到今日，为了适应不同屏幕的尺寸适配，为挪动端独自创立一个网站，即 挪动子域名网站。比方 Facebook 的桌面版本和挪动端版本，采纳两个不同的域名来拜访：
如此一来，开发人员要开发两个版本，相应的工作量就更大了，特地对于要疾速响应和试错的 Web 利用来说，难度变得更大。
Web 开发人员为了能改善这种景象，在 2010 年的时候，Ethan Marcotte（@beep）基于 John Allsopp（@johnallsopp）的《网页设计的道（A Dao of Web Design）》，提出响应式 Web 设计思路（《Responsive Web Design》）。从此响应式 Web 设计（Responsive Web Design，简称 RWD）的身影就呈现在了公众背后。
Ethan Marcotte（@beep）在《Responsive Web Design》中提到，响应式这个词源自于建筑学畛域，本来指的是建筑物自身会“响应”理论的应用状况，来自我调整。在 Web 开发畛域，“响应式”的意思就变成了，咱们开发的 Web 页面会“响应”用户的设施尺寸而主动调整布局。在这篇文章中提到过，咱们能够基于 流体网格（Fluid Grids）、灵便的图片（Flexible Images）和媒体查问（Media Queries）三种技术来构建一个响应式 Web 网站或 Web 利用。
另外，Ethan Marcotte（@beep）构建了第一个具备响应式的 Web 网页，能够说是响应式 Web 设计经典案例之一（只惋惜当初打不开了）：
那通过这个示例，大家对响应式 Web 设计是什么样的有了一个初步的理解了。其实，Ethan Marcotte 在他的文章中就提到：
将来咱们应该这样，随着拜访网页的设施减少咱们不会为每个设施独自设计，而只会做一份设计，把每个设施作为这份设计要关照的一个方面。
也就是说，每个设施上都会去谋求最佳的用户体验，设计会主动适应各个设施。在过来的时代，设计师准确的晓得本人的媒介材质，比方一张 A4 纸张，一个名片，或者一张海报。然而在咱们这个多屏时代，Web 设计必须有这样的思维，咱们要为“任意尺寸”而去设计。
自 Ethan Marcotte 提出响应式 Web 设计思路以及基于不同断点（CSS 媒体查问代替 JavaScript 查问设施屏幕分辨）实现不同终端设备屏幕分辨率布局已有十多年了。大家都说，每十年就会看到一个生态系统迅速的倒退，其中 CSS 也不另外。尤其是这两年，CSS 新增了很多新的个性，比方大家最为期待的容器查问个性 @container、级联分层 @layer 以及 CSS 作用域 @scope 等。
正如 Una Kravets (@Una) 在 2021 的 Google I/O 大会上的分享所说：
随着用户偏好查问、容器查问以及其余设施类型查问的呈现（CSS 新个性），Web 社区行将进入响应式 Web 设计的新时代，并扭转咱们对其含意的认识。
换句话说，下一代响应式 Web 设计行将到来，或者说曾经来到了咱们身边。
响应式 Web 设计的现状
在聊一下代响应式 Web 设计之前，咱们就要对响应式 Web 设计的现状有所理解。咱们别离从两种不同角色（Web 设计师和 Web 开发者）的角度来看响应式 Web 设计的现状。先从 Web 设计师的角色来聊。
时至今日，尽管已是挪动终端的天下，但如果要给不同终端提供设计稿的话，Web 设计师还是会仍旧为不同的设施终端提供不同的设计稿。比方，为不同的设施视窗尺寸（如手机，平板和桌面端）提供不同的设计稿：
咱们来看下简化后的不同版本的设计线框图，如下所示：
在上图中，设计师为卡片（Card）提供了三种不同的 UI 成果。尽管卡片在不同设施视窗下有着不同的 UI 成果，但他们形成的元素是雷同，都有卡片容器、卡片缩略图、卡片题目 和 卡片形容等：
作为 Web 设计师，你曾经应用了多个版本的布局来展现同一个组件三种不同状态下的 UI 变动。能够说把足够多的信息传递给了 Web 开发者！到这一步，Web 设计师已给 Web 开发者提供了具备响应式的 Web 设计稿。
接下来，再从另一种角色（Web 开发者）来看响应式 Web 设计的现状。对于 Web 开发者而言，要实现上图中三种状态下的卡片 UI 成果非常简单。借助 CSS 媒体查问个性，在不同断点下调整 CSS 款式规定即可：
/* Mobile First */
.card {
display: flex;
flex-wrap: wrap;
gap: 10px;
}
/* Tablet */
@media (min-width: 700px) {
.card {gap: 20px}
}
/* Laptop and Desktop */
@media (min-width: 1024px) {
.card {position: relative}
.card__thumb {
position: absolute;
inset: 0;
}
}这种形式只能适宜于同一组件独立存在于不同版本下。就示例的设计稿来看，在桌面端有两种成果的卡片，为了满足该设计成果，咱们须要额定增加一些类名，在不同状态下为卡片解决不同的 UI 成果：
CSS 款式代码可能会是像上面这样：
/* Mobile First */
.card {
display: flex;
flex-wrap: wrap;
gap: 10px;
}
/* Tablet */
@media (min-width: 700px) {
.card--vertical {gap: 20px}
}
/* Laptop and Desktop */
@media (min-width: 1024px) {
.card--featured {position: relative}
.card--featured .card__thumb {
position: absolute;
inset: 0;
}
}看上去是不错，但问题是，只有当视窗宽度大于一个特定的值时（常指的分辨率断点值），相应的组件变体才会失效，比方当视窗宽度大于 700px 时，.card–vertical 卡片 UI 成果才失效；当视窗宽度大于 1024px 时，.card–featured 卡片 UI 成果才失效。换句话说，如果要在平板端看到.card–featured 卡片成果就无奈看到，因为它的媒体查问在 1024px 或更大的视窗宽度下才会失效。
不仅如此，Web 的内容是动静的，有的时候输入的内容可能和设计预约的卡片数量不相符合，那么在这种状况之下，要么会有一个空的空间，要么卡片会扩大以填补容器的残余（或可用）空间。比方咱们这个示例中，在视窗宽度为 700px 或更大的视窗宽度中，.card–vertical 和 .card–featured 都有可能呈现这样的场景。
针对这样的场景，Web 设计师可能更心愿有额定的 UI 成果给卡片。这部分咱们放到下一节来聊。简略地说，目前的响应式 Web 设计次要计划还是利用 CSS 媒体查问个性在不同的终端上提供布局的切换。尽管他能满足 Web 页面布局大部分场景，但也绝对丢失了一些其余能力，比如说将响应式的款式注入到组件自身的能力。换句话说，基于视窗宽度查问构建的响应式 Web 页面，尤其是响应式组件，其能力是无限的。
CSS 媒体查问的有余
在上一节中咱们一起探讨了 Web 开发者能够借助于 CSS 媒体查问个性来查问视窗宽度（或设施其余个性）为 Web 页面在不同终端提供差异化的布局。但也暴露出很多不足之处，甚至是显著的能力有余。就拿后面示例来说，卡片组件有三种差异化的 UI 成果，这些差异化的 UI 成果是取决于浏览器视窗宽度，也就意味着卡片组件不能依据其父容器宽度去调整 UI 格调。这就限度了开发者 只能在视窗宽度大于某个特定值时（断点）应用一个组件的特定款式。例如视窗宽度达到 700px 或大于 700px 时，卡片组件从默认的.card（程度）状态切换到垂直（.card–vertical）状态。也就是说，如果咱们想在小于 700px 宽度的视窗下，应用垂直状态（.card–vertical）卡片成果是不行的：
另外一点就是当服务端吐出的数据和设计师预设的数量不统一时，最终的 Web 成果有可能不是设计师冀望的。比方只有一张卡片、两张、三张或更多，而设计稿中蕴含三张，这种状况之下，Web 开发的实现的成果可能会像下图这样：
正如上图所示，如果只有一张卡片数据吐出的时候，整个卡片宽度会扩大与容器宽度相等（拉伸）。此时，卡片宽度太宽导致用于卡片上的缩略图被拉抻，有可能会使缩略图变得含糊。事实上呢？这只是 Web 开发者的两厢情愿，设计师真正的用意可能是像下图这样：
在这种场景之下，应用 CSS 媒体查问个性实现起来会比拟辣手，但应用 CSS 容器查问个性，就会容易地多，咱们能够通过查问卡片父容器来决定如何显示卡片去解决这些问题。
如果用一然话来概述的话：
尽管 Web 开发者能够应用全局的视窗信息来设置组件的款式，但组件依然不能领有自已的款式，而且当咱们的设计零碎基于组件而不是基于页面时，那么媒体查问就无能为力！
庆幸的是，生态系统正在扭转，而且这两年尤其突出。比如说，咱们始终冀望的容器查问个性就如约而至。如果咱们将组件本身的响应式款式思路从查问视窗转换到查问其先人容器，是不是后面的问题就能够轻易解决。除此之外，晚期的 CSS 媒体查问只能查问视窗宽度和媒体个性，但不能查问用户对设施爱好的设置。不过，这两年 CSS 媒体查问个性也有微小的变动，咱们除了查问媒介（设施）个性之外，也能够查问用户偏好设置。
正如 Una Kravets 所言：
Web 生态再一次让 CSS 腾飞，这些新的个性将会让响应式 Web 设计注入新的能力。咱们也将进入响应式设计的新时代，并转变咱们对其含意的认识。
下一代响应式 Web 设计
当媒体查问被使用于 CSS 中时，“响应式 Web 设计”（Responsive Web Design）一词就被 Ethan Marcotte 在 2010 年发明进去。从那时起，Web 设计师和开发人员就开始应用响应式 Web 设计的办法来设计和开发一个沉迷式的 Web 页面或 Web 利用，以实时适配当今看上去无底洞的终端设备。
明天，当咱们提到响应式 Web 设计时，首先想到的是 Ethan Marcotte（@beep）的《Responsive Web Design》博文中提到过的基于 流体网格（Fluid Grids）、灵便的图片（Flexible Images）和媒体查问（Media Queries）三种技术来构建一个适应不同屏幕尺寸或不同挪动终端设备的 Web 页面。
Web 开发者应用 CSS 媒体查问来扭转整个页面的布局，并从上到下调整挪动手机、平板电脑和桌面端的设计尺寸。这种办法很无效，而且成果很好，但它有一个显著的缺点，即 整个屏幕同时响应，或者说整个页面同时响应。尽管该响应形式的确对用户的体验有一些较大的影响，但不能响应个别用户的需要，也不足将响应式注入组件自身。
好消息是，生态系统正在扭转，而且提高十分迅速。Web 设计师和 Web 平台的工程师正在开始用一种新的响应式技术计划来构建 Web 页面，这种计划被称为组件驱动式 Web 设计（Component-Driven Web Design）。
组件驱动式 Web 设计
咱们明天应用的响应式 Web 设计办法很快就会被认为是过期的，就像咱们从 90 年代最后的基于表格的 HTML 开发过渡到当初的感觉一样。
Web 设计师当初要克服的挑战是，目前的响应式 Web 设计办法实质上是一种一刀切的办法，把整个页面和用户体验当作一个整体，没有任何个性化。
基于视窗的媒体查问（CSS 媒体查问）给咱们提供了许多媒体查问的能力，但短少为咱们的 Web 设计提供精密度的能力，并发明一个对用户、他们的环境和他们在页面上采取的口头来说是独特的体验。咱们也不足将响应式款式注入组件自身的能力。
这里所说的组件是 Web 上的元素，能够由其余设计元素的汇合或分组组成。如果咱们把组件看成是由积木组成的，并把这个概念利用到像幻灯片、卡片或内容块这样的常见 UI 元素的结构中，就会更容易了解，在不久的某一天，咱们可能会把响应式设计款式注入单个组件或积木中，以定制和调整用户的体验，而不是把一套固定的款式和规定利用于整个页面的布局。
咱们能够应用全局视窗信息来管制元素的字体大小和最大宽度等款式，或者调整这些组件的背景图像和布局，但它们依然无法控制领有本人的款式。当咱们的响应式设计零碎是基于组件的，而不是基于页面的时候，这种限度就更难了。
好消息是，全世界的 Web 设计师和开发人员正在致力扭转响应式 Web 设计的生态系统。只管为了扭转咱们对响应式设计的思考形式以及组件如何适应其周围环境，须要进行根本的设计思维过程的扭转，但响应式设计业余人员解决响应式 Web 设计的形式正在疾速变动。
当初为翻新之火火上浇油的是 CSS 和灵便布局的疾速倒退，比方增加了一些新的查问规定、Flexbox 和 Grid 布局。这里所获得的提高正在迅速迎来一个新的响应式 Web 设计的时代，而这个时代就在地平线之外。
CSS 生态疾速的倒退，行将彻底改变响应式 Web 设计的概念！
当初，在咱们被引入响应式 Web 设计这个激进的新概念的十多年后，咱们又一次见证了响应式设计生态系统的演变，即 CSS 新增的个性将间接基于组件而不是基于页面注入款式响应能力。这种能力被称为 组件驱动 Web 设计（Component-Driven Web Design），基于组件驱动的开发将会成为一种真正风行的开发模式。
为了了解这种开发模式的转变，并为行将到来的变动浪潮做好筹备，让咱们看看在响应式 Web 设计静止中咱们能够期待的变动，以及这可能会如何扭转咱们看待响应式设计的概念。
响应用户的需要
你可能对基于视窗可视区域大小的媒体查问（通过 min-width、max-width、min-height、max-height、orientation 和 aspect-ratio 等）比拟相熟，比方：
@media (max-width: 45rem) {/* 视窗小于 45rem */}
@media (min-width: 45rem) {/* 视窗大这只是 CSS 的 @media 最根底的一部分规定，事实上，@media 规定大概蕴含了 24 个可供查问的个性，其中大概 19 个查问规定失去较好的反对，具体的能够浏览《图解 CSS: CSS 媒体查问》一文。在这些新增的查问个性中是用来改善用户体验的，比方 Media Queries Level 5 标准中的第十一部分，可能让你依据用户本身的特定偏好和需要来设计 Web 体验。
也意味着这些新增的媒体查问个性容许你依据用户的偏好来调整用户的体验。
当初很多设施提供了一些用户偏好的设置。比方在 Mac 电脑上，用户能够依据本人爱好做一些设置：
CSS 媒体查问提供了一些用户爱好的查问个性，这些个性能够辨认出用户在零碎上的偏好设置，帮忙 Web 开发者构建更加强壮和个性化的 Web 体验，特地是对于那些具备可拜访性需求的用户。
prefers-reduced-motion
Web 页面或利用不免少不了用一些动效来装点，但有些用户不喜爱这些动画成果，甚至对于多数用户来说，这些动效会让他们身材不适。这就是为什么当初大多数设施都反对一种办法让用户依据本人的爱好来做设置。
应用 prefers-reduced-motion 媒体查问用于检测用户的零碎是否被开启了动画削弱性能。比方上面的这个示例，将会展现一组令人心烦的动画，不过当你开启了零碎的“缩小静止”后就能看到动画削弱的成果了。
.pulse {animation: pulse 2s infinite;}
@media screen and (prefers-reduced-motion: reduce) {
.pulse {animation: none;}
}示例成果演示的是 prefers-reduced-motion 媒体个性如何让 animation 进行，其实 CSS 的 transition 也能够实现动画成果，加上并不是所有设施对动效都有一个很好的性能反对（毕竟动效是较耗性能的），因而，咱们能够像上面这样来写 CSS：
@media screen and (prefers-reduced-motion: reduce), (update: slow) {
* {
animation-duration: 0.001ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.001ms !important;
}
}这段代码强制所有应用动画持续时间或过渡持续时间申明的动画以人眼无奈觉察的速度完结。当用户要求缩小动画体验，或者设施屏幕刷新率较低时，比方便宜智能手机，它就能工作。
另外，Eric Bailey 在他的文章《Revisiting prefers-reduced-motion, the reduced motion media query》中提出了一个观点：
“并不是每一个能够拜访网络的设施都能够出现动画，或者流畅地出现动画。”
对于刷新率低的设施来说，可能会导致动画呈现问题，比方动画卡顿。这样的话，删除动画可能是更好的抉择。咱们能够将 prefers-reduced-motion 和 update 联合在一起应用：
@media screen and (prefers-reduced-motion: reduce), (update: slow) {
* {
animation-duration: 0.001ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.001ms !important;
}
}这段代码强制所有应用 animation-duration 或 transition-duration 申明的动画以人眼难以觉察的速度完结。当一个人要求缩小动效体验，或者设施有一个刷新率较低的屏幕，比方电子墨水或便宜的智能手机，它就能发挥作用。
但须要留神的是，应用动静削弱并不意味着“没有动效”，因为动效在 Web 页面中传播信息能起到至关重要的作用。相同，你应该应用一个松软的、去除非必须的动效根底体验去疏导这些用户，同时逐渐加强没有此项偏好设置的其余用户的体验。
如果你对削弱动效成果这方面技术感兴趣的话，还能够浏览：
Revisiting prefers-reduced-motion, the reduced motion media query
Meeting“2.2.2 Pause, Stop, Hide”with prefers-reduced-motion
Respecting Users’Motion Preferences
Designing With Reduced Motion For Motion Sensitivities
Accessible Web Animation: The WCAG on Animation Explained
Accessible Animations in React
prefers-color-scheme
你可能晓得了，macOS 零碎和 iOS13 之后，苹果设施具备 Dark Mode 成果，就是用户能够依据本人的爱好来抉择零碎提供的色系：
应用 prefers-color-scheme 查问个性能够让你对用户是否关上了设施上 Dark Mode 来做出响应。换句话说，给 Web 页面或利用增加 Dark Mode 只须要几行代码即可。首先咱们默认加载的主题是亮色系，咱们能够在 :root 中申明亮色系所须要的色彩，比方：
:root {
--text-color: #444;
--background-color: #f4f4f4;
}而后通过媒体查问 prefers-color-scheme: dark 为暗色系重置所须要的色彩：
@media screen and (prefers-color-scheme: dark) {
:root {--text-color: rgba(255,255,255,.8);
--background-color: #121212;
}
}应用 prefers-color-scheme 来定制不同外观主题时，还能够和 theme-color 以及 color-scheme 联合起来应用。这将能控制系统利用的（比方浏览器）主题色彩：
而 color-scheme 这个 CSS 属性和 <meta> 的 name 为 theme-color 是雷同的。它们都是让开发者更容易依据用户的爱好设置来管制 Web 利用或页面的主题，即 容许开发者依据用户爱好设置增加特定的主题款式。其实 color-scheme 属性和 相应的 <meta> 标签与 prefers-color-scheme 相互作用，它们在一起能够施展更好的作用。最重要的一点是，color-scheme 齐全决定了默认的外观，而 prefers-color-scheme 则决定了可款式化的外观。
假如你有上面这样的一个简略页面：
<head>
<meta name="color-scheme" content="dark light">
<style>
fieldset {background-color: gainsboro;}
@media (prefers-color-scheme: dark) {
fieldset {background-color: darkslategray;}
}
</style>
</head>
<body>
<p>
Lorem ipsum dolor sit amet, legere ancillae ne vis.
</p>
<form>
<fieldset>
<legend>Lorem ipsum</legend>
<button type="button">Lorem ipsum</button>
</fieldset>
</form>
</body>页面上 <style> 中的 CSS 代码，把 <fieldset> 元素的背景色彩设置为 gainsboro，如果用户更喜爱暗色模式，则依据 prefers-color-scheme 媒体查问，将 <fieldset> 的背景色彩设置为 darkslategray。
通过 <meta name=”color-scheme” content=”dark light”> 元数据的设置，页面通知浏览器，它反对深色（dark）和亮色（light）主题，并且优先选择深色主题。
依据操作系统是设置为深色还是亮色模式，整个页面在深色上显示为浅色，反之亦然，基于用户代理样式表。开发者没有额定提供 CSS 来扭转段落文本或页面的背景色彩。
请留神，<fieldset> 元素的背景色彩是如何依据是否启用了深色模式而扭转的，它遵循了开发者在页面上提供的内联样式表的规定。它要么是 gainsboro，要么是 darkslategray。
上图是亮色模式（light）下，由开发者和用户代理指定的款式。依据用户代理的样式表，文本是彩色的，背景是红色的。<fieldset> 元素的背景色彩是 gainsboro，由开发者在内联的式表中指定的色彩。
上图是暗色模式（dark）下，由开发者和用户代理指定的款式。依据用户代理的样式表，文本是红色的，背景是彩色的。<fieldset> 元素的背景色是 darkslategray，由开发者在内联样式表中指定的色彩。
按钮 <button> 元素的外观是由用户代理样式表管制的。它的色彩被设置为 ButtonText 零碎色彩，其背景色彩和边框色彩被设置为 ButtonFace 零碎色彩。当初留神 <button> 元素的边框色彩是如何变动的。border-top-color 和 border-bottom-color 的计算值从 rgba(0,0,0,.847)（偏黑）切换到 rgba(255, 255, 255, .847)（偏白），因为用户代理依据色彩计划动静地更新 ButtonFace。同样实用于 <button> 元素的 color 属性，它被设置为相应的零碎色彩 ButtonText。
看上去不错，但这也引出另一个新的概念，零碎色彩。
有对于零碎色彩这方面的不在这里具体论述，如果你感兴趣的话能够浏览：
零碎偏好设置的那些事儿
Windows High Contrast Mode, Forced Colors Mode And CSS Custom Properties
Styling for Windows high contrast with new standards for forced colors
Operating System and Browser Accessibility Display Modes
prefers-reduced-data
不是每个人都能幸运地领有疾速、牢靠或有限的数据（流量）套餐。
你可能有过出差旅行的经验，也可能碰到了手机数据不够用，那么拜访一个重图片的网站是很蹩脚的（尽管说当初流量对于大家来说不是很大的事件，花钱总是能摆平的）。不过，一旦 prefers-reduced-data 失去反对，那么这个头痛的事件就能够防止了，也能够帮用户省下肯定的费用。因为，该个性能够让用户跳过大图或高分辨率的图像。
.image {background-image: url("images/heavy.jpg");
}
@media (prefers-reduced-data: reduce) {
.image {background-image: url("images/light.avif");
}
}当用户在设施上开启了“Low Data Mode”（低数据模式），会加载占流量更低的 light.avif 图像，能够帮忙 iPhone 上的应用程序缩小网络数据的应用：
插个题外话，下面提到的这三个媒体查问个性次要是使用于 CSS 中，但它们还能够和 HTML 的 <picture> 元素的 <source> 标签元素联合起来应用。能够依据用户对设施的偏好设置来抉择不同的图片源：
<!-- 依据 prefers-color-scheme 为不同模式抉择不同图片 -->
<picture>
<source srcset="dark.png" media="(prefers-color-scheme: dark)">
<source srcset="light.png" media="(prefers-color-scheme: light)">
<img src="light.png" alt="" />
</picture>
<!-- 依据 prefers-reduced-motion 为用户出现动图或动态图 -->
<picture>
<source srcset="animation.jpg" media="(prefers-reduced-motion: reduce)">
</source>
<img srcset="animation.gif" alt="" />
</picture>
<!-- 依据 prefers-reduced-data 为用户抉择不同的图片 -->
<picture>
<source srcset="light.jpg" media="(prefers-reduced-data: reduce)" />
<img src="heavy.jpg" alt=""srcset="heavy@2x.jpg 2x" />
</picture>prefers-contrast
prefers-contrast 媒体查问次要用于检测用户是否要求零碎减少或缩小相邻色彩之间的对比度。比方一些喜爱浏览电子书的用户，在浏览与文本背景对比度相差不大的文本时会遇到困难，他们更喜爱较大的对比度，利于浏览。
比方像上面这个示例：
.contrast {
background-color: #0958d8;
color: #fff;
}
@media (prefers-contrast: high) {
.contrast {background-color: #0a0db7;}
}其余与用户偏好无关的媒体个性
从 W3C 标准中不难发现，标准中提供了六个有对于用户偏好的媒体查问个性：
咱们来看一个 forced-colors 的示例，该示例来自于 Eric 的《Windows High Contrast Mode, Forced Colors Mode And CSS Custom Properties》一文：
Modal dialog with Forced Color mode tweaks@smashingmagCodePen
提取应用 forced-colors 的示例代码：
// SCSS
.c-dialog__content {background-color: var(--dialog-color-background);
box-shadow: 0 1rem 2rem 0 #00000099;
outline: var(--dialog-border-width) solid var(--dialog-border-color);
padding: var(--dialog-padding-outer);
width: min(90vw, 38rem);
z-index: 1;
@media (forced-colors: active) {--dialog-border-width: var(--size-300);
}
}在 forced-colors 媒体查问个性中从新定义了 –dialog-border-width 的值。这样做的起因是一个十分有意思的调整。它把细的焦点框（outline）变成了一个粗的。这样调整有助于显示模态框的外部边界，并传播它是沉没在页面其余内容之上的信息。强制色调模式删除了模态框的盒子暗影（box-shadow），所以咱们不能在这种专门的浏览模式下依赖这种视觉效果：
如果你对下面提到的媒体查问个性感兴趣的话，能够深刻浏览上面这几篇文章：
Media features
CSS 媒体查问新个性
零碎偏好设置的那些事儿
图解 CSS: CSS 媒体查问
响应容器的需要
CSS 的 媒体查问引发了一场响应式设计的反动，为开发者提供了一种办法来查问用户代理或设施环境的各个方面，比方视窗的大小或用户偏好来扭转 Web 页面的格调。直到现在，媒体查问还做不到让元素的款式能依据一个最近的容器的大小来扭转款式格调。也正因而，大家始终期待的容器查问来了。
很难设想，从基于页面的响应式设计（媒体查问）到基于容器的响应式设计（容器查问）的转变，对设计生态系统的倒退会起到什么作用？
为了答复这个问题，接下来咱们分几个方面来介绍，心愿能给大家带来肯定的思考，从而失去本人想要的答案。
容器查问的倒退历程
正如我在《2022 年的 CSS》一文中所提到的那样。始终以来，CSS 容器查问都是大家期待的一个个性，在这几年的 CSS 倒退报告中，他始终位居第一：
自 2010 年 @Ethan Marcotte 首次提出 响应式 Web 设计（RWD）的设计理念（概念），Web 设计就进入古代 Web 布局时代。开发者能够依据 CSS 媒体查问个性（通常是视窗宽度、媒体设施个性等）来为 Web 页面定制不同的表现形式，比方能够依据用户浏览内容的设施个性来出现不同的布局、不同的字体大小和不同的图片等。
但对于 Web 设计师或 Web 开发者来说，在古代 Web 设计或布局中依然短少一个性，页面的设计不可能响应其容器的宽度（或其余个性）。也就是说，如果 Web 开发者可能依据容器宽度来扭转 UI 款式，那就更好了。容器查问将在很大水平上帮忙 Web 开发者更好的实现他们的工作，在为 Web 开发基于组件代码时，其脱漏（容器查问个性的缺失）是一个微小的限度。
正因而，有对于容器查问的个性在社区中的探讨就没有进行过。
早在 2019 年底，@Zach Leatherman 在寻找容器查问起源时，找到的最早有对于容器查问的解决方案是 @Andy Hume 的基于 JavaScript 的选择器查问和响应式容器的解决方案。
2015 年，@Mat‘Wilto’Marquis 在响应式图片社区小组引入了 <picture> 元素，将响应式图片带到了响应式 Web 设计的世界，他在《Container Queries: Once More Unto the Breach》一文中概述了元素查问的挑战和应用案例演示了容器查问的个性。
而后，在 2017 年，@Ethan Marcotte 写了一篇对于容器查问相干的文章，并提出了这样的认识：
在他最后关注的响应式 Web 设计的文章之后的几年里，Web 设计师和开发人员的工作越来越集中在组件上，而不是整个页面，这使得媒体查问不那么现实。
从那时起，尽管有很多人主张应用媒体查问，但容器查问向前推动的速度还是不够现实。@L. David Baron 在《Thoughts on an implementable path forward for Container Queries》中简明扼要地解释了容器查问向前推动慢的问题出在哪？
容器查问要求款式取决于组件的大小，但思考到 CSS 的工作原理，组件中的款式会影响其大小。任意突破这个循环，既会产生奇怪的后果，又会烦扰浏览器的工作，还会减少浏览器优化的老本。
除了 @David Baron 之外，2018 年 6 月，@Greg Whitworth 在荷兰阿姆斯特丹举办的 CSS Day + UX Special 流动上的主题分享《Over the moon for container queries》中也解释了容器查问在 Web 平台上推动慢的相干起因。更重要的是，@Greg Whitworth 还提供了应用新的 JavaScript API 和 CSS 的新技术来实现容器查问的个性。@David Barrrron 也提出了一个能够防止这种窘境的策略，更重要的是 @Miriam Suzanne 在 @David Baron 的策略根底上提出了 @container 办法。
@container 办法通过对被查问的元素利用大小和布局的限度来实现。任何具备尺寸和布局限度的元素都能够通过一个新的 @container 规定进行查问，其语法与现有的媒体查问相似。
这个提议曾经被 W3C 的 CSS 工作组驳回，并曾经增加到 CSS Containment Module Level 3 模块中。有对于该性能的相干问题和各网格平台推动进度，能够点击这里查阅。
尽管 CSS Containment Module Level 3 还是 FPWD 版本，标准中所形容的语法不是最终版本，直到写这篇文章，其语法规定还在变，因而文章中所展现的语法有可能会变以及相干的示例有一天就有效了：
什么是容器查问
CSS 容器查问最大的特点是：
容器查问容许开发者定义任何一个元素为蕴含上下文，查问容器的后辈元素能够依据查问容器的大小或计算款式的变动来扭转格调！
换句话说，一个查问容器是通过应用容器类型属性（container-type 或 container）指定要能的查问类型来建设的。实用于其后辈的款式规定能够通过应用 @container 条件组规定对其进行查问来设定条件。
容器查问为响应式设计提供了一种更加动静的办法。这意味着，如果你将此卡片组件放在侧边栏或放在页面主体外部的网格中，则该组件自身依据容器而不是视口进行响应式的信息展现。
首先，把卡片放到一个容器元素中，比方.card__container：
<!-- HTML -->
<div class="card__container">
<div class="card">
<img src="https://picsum.photos/2568/600?random=1" width="2568" height="600" alt=""class="card__thumbnail" />
<div class="card__badge">Must Try</div>
<h3 class="card__title">Best Brownies in Town</h3>
<p class="card__describe">High quality ingredients and best in-class chef. Light, tender, and easy to make~</p>
<button class="card__button">Order now</button>
</div>
</div>也就是说，当卡片组件被放在一个容器中时，代表着它被蕴含在该容器中，比方下面代码中的.card__container。这也意味着，咱们能够应用 CSS 的 container 来查问.card__container 的宽度，并在 @container 对 .card 设置不同的款式规定。从而达到设计师真正的用意：
比方，容器宽度（.card__container）别离在 >400px、>550px 和 >700px 时为.card 设置不同款式：
代码可能像上面这样：
/* Default */
.card {// ...}
/* CSS Container Queries*/
.card__container {container-type: inline-size;}
/* container's width > 400px*/
@container size(width > 400px) {
.card {// ...}
}
/* container's width > 550px*/
@container size(width > 550px) {
.card {// ...}
}
/* container's width > 700px*/
@container size(width > 700px) {
.card {// ...}
}Untitled@airenCodePen
拖动卡片右下角的滑块，扭转 .card__container 容器大小，你能够看到卡片组件（.card）UI 成果的变动。
@container 规定，其工作形式与应用 @media 的媒体查问相似，但相同，@container 查问父容器以获取信息，而不是视口和浏览器的 UserAgent。
容器查问的应用
到目前为止，CSS 容器查问的语法规定曾经经验了多个版本更新，下面示例中展现是最新的应用形式。上面这几篇文章中能够索引到其每个版本的应用形式的差别：
初探 CSS 容器查问
容器查问给设计带来的变动
容器查问中的 container 和 @container
接下来，通一个容器查问卡片的示例来向大家展现如何应用 CSS 容器查问。
定义一个蕴含性上下文
要应用 CSS 容器查问个性，首先要定义一个蕴含性上下文（Containment Context）。这个有点相似于应用 Flexbox 和 Grid 布局（定义 Flexbox 或 Grid 上下文应用的是 display 属性），只不过，定义一个蕴含性的上下文应用的不是咱们熟知的 display 属性，而是一个新的 CSS 属性，即 container。
在一个元素上显式应用 container 能够通知浏览器当前要针对这个容器进行查问，以及具体如何查问该特定的容器。比方，下面演示的示例中，咱们在 .card__container 元素上（.card 的父容器）显式设置了 container-type 的值为 inline-size：
.card__container {container-type: inline-size}下面的代码通知浏览器，能够基于.card__container 容器的内联轴（Inline Axis）方向尺寸变动进行查问。也就是说，当.card__container 容器宽度大小变动到指定的某个值时，其后辈元素的款式就能够进行调整。
container-type 是 container 属性中的一个子属性，另外，还能够显式应用 container-name 来命名你的容器，即给一个蕴含性上下文指定一个具体的名称：
.card__container {container-name: card}这种形式对于同一个上下文中有多个蕴含性上下文时十分有意义，能够更明确地晓得哪些查问会影响元素。
你能够应用简写属性 container，只不过须要在 container-type 和 container-name 之间增加斜杠宰割符 /：
.card__container {
container-type: inline-size;
container-name: card;
}
/* 等同于 */
.card__container {container: inline-size / card;}如果一个容器查问被利用到一个没有定义的蕴含先人元素上，查问将无奈利用。也就是说，无论是 body 还是 html 元素，都没有默认的回退蕴含上下文。另外，定义蕴含上下文名称时不能是 CSS 的关键词，比方 default、inherit、initial 等。
留神：container-name 能够省略，如果省略将会应用其初始值 none，但 container-type 不可省略，如果省略的话则示意未显式申明蕴含性上下文！
定义一个容器查问
当初咱们晓得应用 container（或其子属性 container-type 和 container-name）对一个元素显式申明蕴含上下文（对一个元素利用蕴含性）。
有了这个蕴含性上下文之后，就能够应用 CSS 的 @ 规定 @container 来对利用了蕴含性元素进行查问，即对容器进行查问。@container 规定的应用和 @media 以及 @supports 类似：
@container containerName size(width > 45rem) {/* 利用了蕴含性上下文后辈元素的 CSS */}
@container size(width > 45rem) {/* 利用了蕴含性上下文后辈元素的 CSS */}这两种形式都是正确的应用姿态，第一个示例中的 containerName 指的是 container-name 显式申明的蕴含性上下文的名称。如果在 @container 中没有指定查问的容器名称，那么这个查问将是针对离款式变动最近的申明了蕴含性上下文的元素进行查问。比方：
@container size(width > 30em) {
.card {border-radius: 20px;}
}示意这个查问将是针对 .card 元素最近的显式申明了蕴含性上下文的元素进行查问。代码中的 size() 函数是容器查问中的新语法规定。这也是容器查问语法变动之一，即 对查问类型进行了更明确的规定。因为标准曾经进步到不仅能够依据尺寸（size）属性查问，还能够依据款式（style）属性进行查问。
正如 Terrible Mia（容器查问标准设计者）在 Twitter 上分享的一样，能够应用 style() 函数对款式进行查问：
@container style(--card: large) {/* CSS Style */}
@container size(width > 30em) and style(--card: large) {/* CSS Style */}到写这篇文章的时候，还没有浏览器反对对款式进行查问。另外，示例中用于 @container 的查问条件(width > 30em) 相当于 (min-width: 30em)。应用数学表达式要比应用 min-width 或 max-width 更易于了解，自 Media Queries Level 4 开始，在 @media 规定中，也能够应用咱们相熟的数学表达式，比方 >=、<= 等来代替以往不易于了解的 min- 和 max-：
下面示例代码中同时呈现 container 和 @container，但他们并不是指的同一个属性，前者是一个 CSS 属性，后者是一个 CSS 代码块。而且两者有实质的区别：container 是 container-type 和 container-name 的简写属性，用来显式申明某个元素是一个查问容器，并且定义查问容器的类型（能够由 container-type 指定）和查问容器的名称（由 container-name 指定）。@container（带有 @规定），它相似于条件 CSS 中的 @media 或 @supports 规定，是一个条件组规定，其条件是一个容器查问，它是大小（size）和（或）款式（style）查问的布尔组合。只有当其条件为真（true），@container 规定块中的款式都会被用户代理使用，否则将被视为有效，被用户代理疏忽。
容器查问卡片
我想大家对容器查问的实践和概念有了一个初步的意识。接下来，咱们把这些货色放到一起，来具体看看后面展现的容器卡片示例是如何实现的。
自从响应式 Web 设计的呈现以及挪动终端设备越来越多，在设计中也有挪动端优先（Mobile First）还是桌面端优先（Desktop First）的争执：
如果你对这方面探讨感兴趣，能够浏览 Ahmad Shadeed 的《The State Of Mobile First and Desktop First》一文。
就我集体而言，到目前为止，在开发跨组件状态的“断点”时，将容器查问与思考“挪动端优先”的设计是最有意义的。也就是说，将最窄的视图作为默认款式，而后通过容器查询处理更大宽度的款式更新。
如上图所示，咱们从左往右来实现卡片不同状态断点下的 UI 成果。先从最窄的卡片开始（最左侧，Default 状态）。构建这个卡片组件，所须要的 HTML 构造如下：
<div class="card__container">
<div class="card">
<img src="https://picsum.photos/2568/600?random=1" width="2568" height="600" alt=""class="card__thumbnail" />
<h3 class="card__title">Container Queries Rule</h3>
<p class="card__describe">Lorem ipsum dolor, sit amet consectetur adipisicing elit. Quis magni eveniet natus nulla distinctio eaque?</p>
<button class="card__button">Order now</button>
</div>
</div>咱们通过 CSS Grid 来实现卡片的布局。先从最窄的开始，增加上面 CSS 代码：
.card {
display: grid;
gap: 1rem;
margin: 5vh auto;
border-radius: 0.5rem;
box-shadow: 0 0.25rem 0.5rem -0.15rem hsla(0 0% 0% / 55%);
background-color: #fff;
}
.card__thumbnail {
max-width: 100%;
aspect-ratio: 16 / 9;
height: auto;
object-fit: cover;
border-radius: 0.5rem 0.5rem 0 0;
}
.card__title {
font-weight: 700;
font-size: clamp(1.2rem, 1.2rem + 3vw, 1.5rem);
padding: 0 20px;
white-space: nowrap;
text-overflow: ellipsis;
overflow: hidden;
}
.card__describe {
color: #666;
line-height: 1.4;
padding: 0 20px;
display: -webkit-box;
-webkit-box-orient: vertical;
-webkit-line-clamp: 3;
overflow: hidden;
}
.card__button {
display: inline-flex;
justify-content: center;
align-items: center;
border: none;
border-radius: 10rem;
background-color: #feca53;
padding: 10px 20px;
color: #000;
text-decoration: none;
box-shadow: 0 3px 8px rgb(0 0 0 / 7%);
transition: all 0.2s linear;
font-weight: 700;
justify-self: end;
margin: 0 20px 20px 0;
cursor: pointer;
}
.card__button:hover {background-color: #ff9800;}卡片组件能够随着其容器（.card__container）宽度主动变动，在窄屏下成果看上去还不错，但在宽屏下，成果看上去有点怪怪的。不过不必放心，这仅是最后的成果。咱们冀望的是通过容器查问的个性，在容器不同断点下扭转卡片组件的布局。依照后面所介绍的，咱们须要先创立一个蕴含性上下文，即在 .card__container 上应用 container 显式申明该元素是一个包容性上下文。
.card__container {container: inline-size;}Untitled@airenCodePen
能够尝试拖动卡片右下角滑块扭转卡片容器宽度。
有了这样一个卡片组件之后，如果将其放在不同的地位，即便是同一页面，同一视窗断点下，也会依据其容器断点主动匹配最为适宜的布局（或 UI 成果）。
Untitled@airenCodePen
尝试调整下面示例中视窗的大小
媒体查问 vs. 容器查问
通过下面的示例的介绍，我想你对容器查问个性曾经有了一个较清晰的意识了。从应用角度来看，容器查问和媒体查问是十分的类似，那么有人可能会问，有了容器查问是不是就不再须要媒体查问个性了呢？在答复这个问题之前，咱们简略的来看两者的差别。
家喻户晓，媒体查问查问的浏览器视窗宽度（当然还有其余查问个性），而容器查问查问的是组件其父容器（具备蕴含性上下文的先人元素）的宽度（或款式）。下图可能能够清晰的论述两者的差别：
就我集体认为，两者不是谁代替谁的关系，更应该是两者共存的关系。容器查问个性的呈现，咱们能够不再局限于视窗断点来调整布局或 UI 款式，还能够基于容器断点来调整布局或 UI。换句话说，媒体查问是一种宏观的布局（Macro Layout），能够用于整体页面布局；而容器查问能够调整组件的每个元素，创立了一种宏观的布局（Micro Layout）。
容器查问解决的是什么问题？
家喻户晓，响应式设计的概念的外围是 CSS 媒体查问的呈现，它容许开发者依据浏览器视窗的尺寸来设置各种款式规定。也正因而，响应式设计和 CSS 媒体查问开启了更多的 Web 布局解决方案，以及多年来围绕响应视窗尺寸创立的最佳实际。而且，近些年来，设计零碎和组件库也失去了更宽泛的遍及。对于更多开发者而言，更大的冀望是：
一次建成，随地部署！
这也意味着一个独自开发的 Web 组件能够在任何状况下工作，以使建设简单的界面更加无效和统一。只不过，这些组件会组合在一起，造成一个 Web 页面或 Web 利用界面。目前，在只有媒体查问的状况下，往往须要额定的一层来协调跨视窗大小变动的组件的渐变。在这些状况下，你可能不得不在更多的断点下应用更多的类名来设置不同的款式规定。甚至更惨的是，即便这样做依然很多状况之下也无奈达到最现实的 UI 外表。
很多时候，响应式 Web 设计不是对于浏览器视窗尺寸而是对于容器的尺寸大小，比方：
庆幸的是，CSS 容器查问的呈现，使咱们超过了只思考浏览器视窗尺寸的范畴，并容许任何组件或元素对定义的容器尺寸做出响应。因而，尽管你可能依然应用响应式来给 Web 页面布局，但 Web 页面的任何一个组件都可能通过容器查问来定义本人的款式变动。而后，它能够依据它是在一个窄的还是宽的容器中显示，来调整它的款式。
容器查问使咱们不再只思考浏览器视窗尺寸大小，而是容许任何组件或元素对定义的容器尺寸做出响应！
也就是说，有了 CSS 容器查问，你就能以一种十分准确和可预测的形式定义一个组件的全副款式。
设计时思考容器查问
尽管响应式设计给 Web 设计师带来了更多的可有性，但响应式设计还是有很多的局限性。对于 Web 设计师而言，更期待的是可能依据组件容器尺寸来提供不同的设计格调。仍旧拿卡片组件来举例：
也就是说，CSS 容器查问个性来了之后，作为一名 Web 设计师，在设计 Web 页面（或组件）时，就须要基于容器尺寸思考如何设计。这样一来，能够向 Web 开发人员提供组件的细节和变动，Web 开发人员也能够基于这些细节进行编码（进行开发）。
不过，这并不意味着容器查问个性之后响应式设计是就失去了意义。在将来，容器查问和响应式设计是共存的，简略地说，Web 设计师在设计组件时可能会将组件分为以下几个局部：
基于视窗（CSS 媒体查问）基于容器（CSS 容器查问）通用型（不受影响的组件）比方：
在将来，Web 设计师给 Web 开发者投喂的设计稿可能就会像下图这样了：
或者因为容器查问的到来，设计师在设计 Web 的时候，也可能会做出相应的调整。投喂给 Web 开发的设计稿也可能会和以往的模式有所差别。那么这个时候，Web 开发者就须要具备正确理解设计师的用意了。比方，Web 设计师可能在将来的设计中会提供向下图的卡片组件设计：
作为 Web 开发人员，看到上图设计成果，须要扭转以往对设计图用意的了解，不能持续执着于基于视窗尺寸来调整组件 UI。
上图是基于视窗的一种开发模式，须要为卡片组件设置不同的类名，并且基于视窗尺寸，在相应的类名下调整卡片组件 UI。有了容器个性时，咱们能够基于古代的 Web 布局技术，比方 Flexbox 或 Grid 布局，让卡片组件基于其容器来调整其 UI：
正如上图所示，能够基于视窗大小采纳 CSS 媒体查问个性，Flexbox 或 Grid 布局等技术扭转卡片容器.card__container 的大小，从而让卡片组件依据其容器尺寸大小做出相应响应。领有一个能依据其父容器尺寸做出响应（UI 调整）的组件是十分有用的，正如你看到的，咱们能够只构建一个组件，就能够满足不同视窗布局下的设计诉求！
容器查问不应该让组件变得复杂化
组件是有由很多个元素组合在一起形成的：
尽管容器查问个性到来，能够让组件依据其容器尺寸来做出响应，但要记住的是，做出响应变动应该要有一个度。如果适度设计的话，对于 Web 开发人员而言，与其应用容器查问个性来实现 UI 响应，还不如从新构建一个独立的全新组件。拿用户信息组件（UserProfile）为例，组件内部结构放弃不变，或者至多不会减少新的构造，只需稍加调整，比方调整布局就能够实现不同的 UI 成果，或者让外部元素显示暗藏切换等。在这种情景之中，采纳容器查问个性能力浮现其魅力：
作用域款式
为了欠缺容器查问个性，CSS 工作组还在踊跃探讨作用域款式（Scoped Styles），以帮忙为组件提供适当的命名空间来防止抵触。
作用域款式容许传递和特定于组件的款式，以防止命名抵触，许多框架和插件（如 CSS 模块）曾经容许咱们在框架内这样做。这个标准当初容许咱们用可读的 CSS 为组件编写本机封装的款式，而无需调整标记。
/* @scope (<root>#) [to (<boundary>#)]? {…} */
@scope (.tabs) to (.panel) {
:scope {/* targeting the scope root */}
.light-theme :scope .tab {/* contextual styles */}
}我本人对作用域款式也理解的不怎么多，所以在这里不做过多论述，免得谬误一直。
作用域款式能够通过不同命名空间款式传递给特定的组件，以防止命名抵触。其实在 CSS 中另一个与容器查问同样被受期待的个性，级联分层，即 @layer 也能够用来解决命名抵触，款式抵触的问题。该个性已失去了 Safari 和 Chrome 浏览器反对。如果你对该话题感兴趣的话，能够浏览《初探 CSS 的级联层（@layer）》一文。
响应形状的需要
新一代响应式 Web 设计除了响应用户需要，容器需要之外，还有另一个响应需要，那就是形状的响应需要。
什么是形状响应需要呢？
折叠设施在市场上曾经存在了近三年，你可能曾经接触过像下图这样的一些设施：
大抵次要分为两种类型，双屏可折叠设施（如 Microsoft Surface Duo）和单屏可折叠设施（如 Huawei Mate XS）：
在多屏幕或可折叠设施上，Web 利用或 Web 页面在这些设施上的关上姿态也将会有所不同，利用能够单屏显示，也能够跨屏显示：
换句话说，咱们的利用或页面要具备这种逾越屏幕的能力，也要具备响应这种逾越的能力，以及还可能须要具备逻辑分隔内容的能力等。
能够说，多屏幕或折叠屏设施开启了更广大的屏幕空间以及用独特的姿态将用户带入到另一个世界。针对于这种设施，除了用户之外，对于 UI 设计师，用户体验师和 Web 开发人员都须要从新面临解锁前所未有的 Web 体验。这也将是近十年来，Web 开发带来最大的变动之一，以及开发人员所要面临的最大挑战之一。
在这里咱们针对多屏幕和折叠屏设施的响应，就称之为响应形状的需要。这也是响应式 Web 设计的一部分。
因为可折叠设施相对来说是新型设施，面对这些新型设施时很多开发者并没有做好相应的常识储备，甚至是不晓得从何动手。事实上呢？有些 Web 开发者曾经开始在为咱们制订这方面的 API，除了文章结尾提到的三星（Samsung）的 @Diego González，英特尔（Intel Corporation）的 @Kenneth Rohde Christiansen 之外还有微软（Microsoft）的 @Bogdan Brinza、@Daniel Libby 和 @Zouhir Chahoud。只不过对于 Web 开发者来说，当初这些制订的标准（CSS 相干的个性）和 Web API（JavaScript API）还很新，不确定因素过多，甚至差异性也比拟大。
到目前为止次要分为两个局部。其中一个局部是《可用于双屏幕和折叠屏的 Web API》介绍的相干 API，它是由微软（Microsoft）的 @Bogdan Brinza、@Daniel Libby 和 @Zouhir Chahoud 一起制订的，更实用于“有缝”的折叠处设施；另一部分是目前处于 W3C 标准 ED 阶段的 屏幕折叠 API，它更实用于“无缝”的折叠设施。
@argyleink 在 Github 上发动了一个应用 CSS 媒体个性来检测折叠屏的探讨。也就是说，Web 开发者能够应用 @media 相干的个性来辨认折叠屏，为折叠屏的类型（比方“有缝”和“无缝”）提供相应的媒体查问。
比方，咱们能够应用 screen-spanning 这个个性能够用来帮忙 Web 开发人员检测“根视图”是否逾越多个相邻显示区域，并提供无关这些相邻显示区域配置的详细信息。
也能够应用 screen-fold-posture 和 screen-fold-angle 两个媒体查问来对无缝设施进行查问：
还能够应用 horizontal-viewport-segments 和 vertical-viewport-segments 查问视口的数量：
horizontal-viewport-segments 和 vertical-viewport-segments 是最新的两个查问个性，它们将代替最后的 screen-spanning 这个媒体查问个性！
除此之外，还能够通过一些折叠姿态来进行查问：
除了 CSS 媒体查问之外，还引入了六个新的 CSS 环境变量，以帮忙开发者计算显示区域的几何形态，计算铰链区域被物理特色遮挡的几何形态：
上图中展现的这六个 CSS 环境变量将代替以前的 env(fold-top)、env(fold-left)、env(fold-width) 和 env(fold-height)。
对于 Web 开发者来说，咱们能够像上面这样来应用：
// 有缝折叠
@media (spanning: single-fold-vertical) {// CSS Code...}
// 无缝折叠
@media (screen-fold-posture: laptop){// CSS Code...}
// 折叠角度查问
@media (max-screen-fold-angle: 120deg) {// CSS Code...}
// 视口数量查问
@media (horizontal-viewport-segments: 2) {// CSS Code...}
@media (vertical-viewport-segments: 2) {// CSS Code...}在古代布局中，将这些媒体查问个性、CSS 环境变量和 CSS Grid 布局联合在一起，就能够很轻易的满足形状响应的需要变动。比方：
:root {--sidebar-width: 5rem;}
@media (spanning: single-fold-vertical) {
:root {--sidebar-width: env(viewport-segment-left 0 0);
}
}
main {
display: grid;
grid-template-columns: var(--sidebar-width) 1fr;
}Stephanie 在她的最新博文《Building Web Layouts For Dual-Screen And Foldable Devices》中也向大家提供了一个示例，演示了按屏幕数量（horizontal-viewport-segments: 2）查问的示例：
.recipe {
display: grid;
grid-template-columns: repeat(3, 1fr);
grid-template-rows: minmax(175px, max-content);
grid-gap: 1rem;
}
.recipe-meta {grid-column: 1 / 4;}
img {grid-column: 1 / 4;}
.recipe-details__ingredients {grid-row: 3;}
.recipe-details__preparation {
grid-column: 2 / 4;
grid-row: 3;
}
@media (horizontal-viewport-segments: 2) {
.recipe {grid-template-columns: env(viewport-segment-width 0 0) 1fr 1fr;
grid-template-rows: repeat(2, 175px) minmax(175px, max-content);
}
.recipe-meta {grid-column: 1 / 2;}
img {
grid-column: 2 / 4;
grid-row: 1 / 3;
}
.recipe-details__ingredients {grid-row: 2;}
.recipe-details__preparation {
grid-column: 2 / 4;
grid-row: 3;
}
}下面是从示例中截取的有对于布局的要害代码。
如果你对多屏或折叠屏这方面技术感兴趣的话，还能够浏览：
聊聊安卓折叠屏给交互设计和开发带来的变动
可折叠 Web 可能会给咱们带来的变动
可用于双屏幕和折叠屏的 Web API
折叠屏相干的 Web API
Foldable CSS and JavaScript update for web developers
Building Web Layouts For Dual-Screen And Foldable Devices
技术的改革是永无止境的，咱们未来要面对的用户终端也绝不会仅现于目前能看到的终端设备和媒介，就好比当初使用于游戏行业的 VR（虚拟现实）和 AR（加强事实）设施。尽管当初 VR 和 AR 用于其余行业的场景还很少见，但咱们能够预感，在 VR 和 AR 设施越来越成熟和更多的设施公布之后，咱们就能看到 VR 和 AR 就像咱们曾经看到几十年前的触摸屏设施一样。或者有一天，你设计（或开发）的 Web 页面或利用就须要能在 VR 和 AR 设施上有一个较好的出现。
上图来自于《UX Case Study: Metaverse Banking VR / AR Design Concept of the Future》一文。UXDA 的业余金融用户体验架构师和设计师团队向您介绍第一个混合事实银行概念，包含 VR 和 AR 银行设计、平板电脑、可穿戴设施、桌面和挪动银行 UI / UX。
在这里，我想表白的是，将来的响应式 Web 设计要响应的形状需要可能会更丰盛，更简单。
总结
响应式 Web 设计曾经将 Web 带到了明天人们所能接触到的每一个连贯的屏幕上。Web 设计师和创意开发者用创造性的思维、大胆的想法和某种无畏的精力摸索、测试和迭代他们的想法，使在线体验更有吸引力、更容易拜访和更智能，推动了设计办法的倒退。就好比这里所提到的 组件驱动式 Web 设计。
组件驱动式 Web 设计的到来或者说 CSS 容器查问、作用域款式、级联层管制等个性的呈现，这些先进的个性使咱们有机会从页面布局、全局款式和用户款式中孤立组件款式，从而实现更具弹性的响应式设计。这意味着你当初能够应用基于页面的媒体查问设计宏观布局，包含多屏或折叠屏的轻微差别；同时应用基于容器查问给组件设计宏观上布局，并增加基于用户偏好的媒体查问，来实现基于用户的独特偏好和需要的定制化体验。
这就是下一代响应式 Web 设计，也就是 组件驱动式 Web 设计（或开发）。它联合了宏观布局和宏观布局，最重要的是，也将用户定制化和尺寸形状都思考到了。
这些变动中的任何一个都将形成咱们对 web 设计形式的重大转变。但它们联合在一起，意味着咱们甚至在概念化响应性设计方面的一个微小转变。是时候思考不止步于视口大小的响应性设计了，并开始思考所有这些新方向，来取得更好的基于组件和定制化的体验。
也就是说。如果咱们将这些组件驱动的性能纳入设计零碎，并从整体上扭转咱们看待 Web 设计的形式，咱们就能够利用这些性能以及更多的性能来改善每一个登陆你网站的访问者的用户体验。咱们能够为他们提供真正个性化的体验，进步参与度和转化率，并最终进步用户对你的品牌的感知。
咱们不再是为用户群体设计。咱们对 “ 受众 ” 一词的了解将发生变化，因为内容和体验将为一个人而不是许多人的受众而变得高度集中。
组件驱动的响应式 Web 设计将使 Web 真正的可移植，并能适应甚至还没有创造的设施。与其在明天的技术范畴内追赶和设计，咱们将只为用户设计。
最初，心愿文章中提到的概念和技术对你有所帮忙。