媒体查询 响应式
媒体查询是现代网页设计的重要组成部分,但并不总是完美的。 在本文中,我们将探讨“元素查询”的概念; 许多人认为响应式网页设计的未来。
在一开始的时候
Ethan关于响应式Web设计的文章永远改变了我们构建网站的方式。 他的文章启发了网页设计师和开发人员,并Swift被其采用。 已经出现了诸如“ 移动优先 ”,“桌面优先”和“ 设备不可知 ”之类的方法,自此开发了设计模式 ,引入了诸如<picture>
元素之类的新标准,并且我们现在拥有无数的框架选择使开发响应式网站更加容易。
我们不再为特定的屏幕尺寸,浏览器或设备构建网站。 相反,我们构建它们以使它们在任何设备上和任何屏幕尺寸下都同样令人愉悦。 我们使用“媒体查询”来做到这一点-不会忘记视口meta标签 。
媒体查询
媒体查询旨在使我们能够将样式规则塑造为特定的环境。 媒体查询的最常见用途之一是在特定的视口宽度范围内更改样式。 例如,下面的代码在通过最大720px宽的视口访问网站时隐藏侧边栏。
.site-sidebar {
display: flex;
flex: 1 1 320px;
}
@media ( max-width: 720px ) {
.site-sidebar {
display: none;
}
}
媒体查询与设备一起发展,并增加了一些新功能,例如orientation
和resolution
。 以下示例显示了我们如何使用这些功能之一在高分辨率屏幕上提供更大的图像尺寸。
.site-logo a {
display: inline-block;
background: url( images/logo.png ) no-repeat;
}
@media screen and ( min-resolution: 2dppx ) {
background: url( images/logo@2x.png );
}
然而
媒体查询并不是响应式Web设计中每种情况的灵丹妙药,实际上,从来没有这样。
如今,市场上有各种尺寸和特征的设备种类繁多,模糊了“移动”和“台式”之间的界限(我正在为您介绍“混合笔记本电脑”)。 因此,保持网站的美观性,出色的用户体验和性能从未如此困难。
一旦将广告,表格和旧内容等内容添加到组合中,情况可能会更糟。 很快,您将遇到媒体查询的“不太好”方面。
媒体查询:“不太好”
考虑以下示例。 我们有一个UI组件来显示我们的团队成员资料。 我们想在我们网站的几个不同位置使用这个确切的组件。 本示例说明如何以780px
视口宽度布置UI。
在“用户个人资料”页面中,我们在左侧显示用户头像,在右侧显示用户名和个人简介。
但是,在我们网站的“团队”页面上,布局发生了变化; 现在,用户头像图片位于顶部,用户名以及个人简介都位于下方。 字体大小也可能会更小。
这种情况可以通过媒体查询来解决。 例如,我们可以编写CSS,如下所示:
/**
* Profile
*/
.team-profile {
text-align: center;
}
.team-profile .bio {
margin-top: 20px;
font-size: 14px;
}
@media ( min-width: 480px ) {
.team-profile {
text-align: left;
display: flex;
}
.team-profile .avatar {
flex: 0 0 120px;
}
.team-profile .bio {
font-size: 16px;
flex: 0 1 580x;
}
}
/**
* Profile card.
*/
.team-profile-card {
text-align: center;
}
.team-profile-card .bio {
margin-top: 20px;
font-size: 14px;
}
/**
* Probably, some overrides
*/
.page .team-profile-card { ... }
只要我们使用其他一些识别类: .user-profile
和.user-profile-card
,它就可以修复。
但是,它也不利于我们的UI是可重用的组件。 可以放在网站上任何地方的UI,可以适应周围的环境。
在此示例中,我们希望组件的布局在被小容器包裹时能够适应,而不是在被浏览器视口挤压时适应。 因此,为什么不依靠浏览器视口的大小来移动布局,为什么我们不能在元素级别上这样做呢?
元素(容器)查询
元素查询的想法大约在2012年初出现。 响应式Web设计成为主流方法论之后的几年。 不幸的是,当时并没有太多令人信服的理由将其作为网络标准提出来-世界仍在习惯于再次变得松软。
@ianstormtaylor是的,“元素查询” 不时出现
— Paul Irish(@paul_irish) 2012年1月24日
网络社区自行启动了计划。 RICG (响应性问题社区组)是发起<picture>
元素的同一组,最终将元素查询添加到其问题列表中,而其他开发人员开发了JavaScript库(例如EQCSS )以模仿此功能。
元素查询的工作方式与媒体查询类似; 除了他们用元素大小代替浏览器视口之外,还使用其他元素。 这使我们能够使用DRY-er代码库构建真正的模块化UI系统。 给定相同的示例,我们可以使用EQCSS重写UI组件的样式,如下所示:
.team-profile {
text-align: center;
}
.team-profile .bio {
margin-top: 20px;
font-size: 14px;
}
@element ".team-profile" and ( min-width: 480px ) {
.team-profile {
display: flex;
}
.team-profile .avatar {
flex: 1 1 120px;
}
.team-profile .bio {
text-align: left;
font-size: 16px;
flex: 1 1 580x;
}
}
这里我们不在乎视口宽度是多少。 如您在上方看到的,只要将UI拉伸到480px
或更宽,我们.bio
并排显示.avatar
和.bio
。 当UI宽度缩小到480px
以下480px
我们将.avatar
和.bio
堆叠起来并将内容与中心对齐。
结语
只是为了澄清,我并不是说使用媒体查询是不好的,一点也没有。 媒体查询非常棒,我们已经在当今建立的许多网站上见证了这一点。 媒体查询和元素查询当然可以共存。 但是,在许多设计方案中,使用元素查询比使用媒体查询更有意义。
不幸的是,在元素查询最终成为Web标准之前,还有很长的路要走。 我们的希望在于RICG的所有优秀人才。
等待期间,我们可以通过EQCSS之类JavaScript库来探索元素查询的潜力。 这正是我们在下一个教程中要做的。 敬请关注!
进一步阅读
媒体查询 响应式