元素查询：未来的响应式设计

16-12-09 来源：[db:作者]

收藏我要投稿

媒体查询是现代网页设计的重要组成部分，但他并不总是完美的。在这篇文章中，我们将看看许多人一直在争论的关于响应网页设计的未来 “元素查询” 的理念。

前言

Ethan关于响应式设计的文章的出现，改变了我们建立网站的思维方式。受到他的文章的启发，设计师和开发人员迅速采用了这种方式。如 “移动第一”，“桌面第一” 和 “ 设备不可知论者 ” 纷纷涌现，出现了新的设计模式，新的标准，类似如元素的出现，现在我们有了数不清的开发框架，使得自适应网站开发更加容易。

我们不再为一个特定的屏幕尺寸，或者浏览器，或设备而建立单独的网站。相反，我们建立一个网站，使他们在任何设备，任何屏幕尺寸上都能完美展示。提醒一下，我们用 “媒体查询” 的时候，千万不要忘了 meta 标签。

媒体查询

媒体查询的目的是使我们能够创建样式模板，适应各种特定的环境。最常见的媒体查询方式是随着视口宽度的改变，改动样式，来适应不同的设备环境。例如下面的代码，当网站窗口最大宽度是 720 像素的时候，隐藏侧边栏。

.site-sidebar {
    display: flex;
    flex: 1 1 320px;
}
@media ( max-width: 720px ) {
    .site-sidebar {
        display: none;
    }
}

媒体查询，随着设备的演变，有几个附加功能，如屏幕旋转和分辨率。下面的例子展示了我们如何让一张大的图片在高分辨率的显示器中显示。

.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 );
}

在响应式方面，媒体查询已经成为一个主流。通过阅读这些文章, 教程, 和我们以前在Tuts+的帖子，来学习如何使用媒体查询。链接如下：

HTML 和 CSS
A “Readability First” Approach to Media Queries and Layout
Kezz Bracey

Sass
Simplify Your Media Queries with Sass “Breakpoint”
Joren Van Hee

自适应网页设计
Quick Tip: Spare a Thought for Vertical Break Points
Ian Yates

转折

实际上，媒体查询在各种各样的响应网页设计上也不一定就是高招。当然，可能从来也不算。

如今，市场上各种尺寸和特性的大范围出现，模糊了 “移动” 和 “桌面” 之间的界限（听起来像是 “混合笔记本电脑”）。出于这个原因，维护网站的美观，拥有良好的用户体验和性能也更为艰难。

2015 年在 Google IO, 谷歌允许开发人员检查他们的网站超过 100 种不同的设备上

一旦你添加诸如广告，表格和旧内容的东西混进去，情况可能会更糟糕。很快你就会遇到媒体查询的 “不那么好” 的一面。

媒体查询：“不那么好”

考虑下面的例子。我们有一个UI 组件，显示我们的团队成员的个人资料。我们想在我们的网站上几个不同的地方使用这个组件。例子中显示了UI 是如何在780px 视口的宽度中布局的。

在 “个人简介” 页面中，我们把头像放在左边，用户名和一段文字的介绍放在右边。

个人简介页展示

在我们的网站上的 “团队” 页面, 用户头像现在放置在顶部, 和用户名以及个人介绍放在下面。字体大小相对要小一点。

团队页面的个人简介

这种情况可以固定媒体查询。比如，我们可以这样写 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 标准仍然在缓慢的前行。

web社区已经开始行动。RICG(响应式问题的社区组织) , 类似于元素添加到问题列表的组织，同时，开发者开发一个类似 EQCSS的javascript库实现这个功能。

原文：Web communities began initiatives on their own. RICG (Responsive Issue Community Group), the same group that initiated the element, eventually added element queries into their issue list while other developers developed a JavaScript library, like EQCSS, to emulate this functionality.

除了从依赖浏览器视口宽度，改成了依赖于元素尺寸外，元素查询的工作方式和媒体查询几乎是一样的。这使我们能够构建具有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;
    }
}

在这里，我们不关心视口的宽度是什么。你可以看到上面，只要该用户界面被拉伸到 480px 或更宽，我们就在边上显示 .avatar 和 .bio 。当UI宽度逐渐缩小到 480px以下的时候，我们就让 .avatar 和.bio 和内容对齐到中心。

结尾

澄清一下，我不是说使用媒体查询是不好的。媒体查询是极好的，今天建造的许多网站已经证明了这一点。媒体查询和元素查询是可以并存的。而且有很多的地方使用元素查询会比使用媒体查询的设计方案更有意义。

不幸的是，元素查询如果成为一个 Web 标准仍然有很长的路要走; 我们将希望寄托在 RICG的所有善良的人。

在我们等待的同时，我们可以通过一个 JavaScript 库如EQCSS挖掘元素查询的潜力。而这正是我们要在接下来的教程要做的。敬请关注！

点击复制链接与好友分享!回本站首页