将CSS媒体查询分组在一起是否有优势?

(这可能已经回答了-虽然找不到答案)

传统的@media查询替代趋向于将同一尺寸的所有替代替代归入同一括号组。

例如

.profile-pic {
    width:600px;
}
.biography {
    font-size: 2em;
}

@media screen and (max-width: 320px) {
    .profile-pic {
        width: 100px;
        float: none;
    }
    .biography {
        font-size: 1.5em;
    }
}

在Sass中,有一种非常漂亮的方法可以在嵌套声明中编写@media查询覆盖,如下所示:

.profile-pic {
width:600px;
  @media screen and (max-width: 320px) {
    width: 100px;
    float: none;
  }
}

.biography {
    font-size: 2em;
  @media screen and (max-width: 320px) {
    font-size: 1.5em;
  }
}

现在,当编译时,sass不会将@media查询块组合在一起,因此输出最终是这样的:

.profile-pic {
    width:600px;
}
@media screen and (max-width: 320px) {
  .profile-pic {
    width: 100px;
    float: none;
  }
}

.biography {
    font-size: 2em;
}
@media screen and (max-width: 320px) {
  .biography {
    font-size: 1.5em;
  }
}

我在最近的项目中使用了这种技术,当您将该原理应用于更大的项目时,最终在整个CSS中分布了多个@media查询部分(到目前为止,我有20个)。

我非常喜欢sass技术,因为它使跟随替代流程更容易(也使移动内容更加容易)。

但是,我想知道通过CSS设置多个@media节是否有任何不利之处,特别是在性能方面?

我已经尝试了chrome css profiler,但是看不到@media查询特有的内容。

本页更多有关@media in sass的信息

樱小胖Mandy2020/03/20 14:00:48

这次聚会晚了一点,但是根据下面的测试,对性能的影响似乎很小。该测试显示了示例页面分别具有2000个单独和组合媒体查询的呈现时间。

http://aaronjensen.github.com/media_query_test/

主要的好处似乎是文件大小比其他任何东西都大-如果您压缩CSS进行生产,则无论如何都会大大减少文件大小。

但最终,如下面的链接所述:

“如果CSS中有2000多个媒体查询,我认为您可能需要重新考虑UI开发策略,而不是使用gem来重新处理CSS。”

博客文章详细介绍了这个问题:https : //web.archive.org/web/20140802125307/https : //sasscast.tumblr.com/post/38673939456/sass-and-media-queries

斯丁2020/03/20 14:00:48

我认为,只需要运行一次媒体查询检查(然后加载其中的所有样式),就比检查每个选择器的工作量少,但是我没有确凿的证据。如果您获得ChromeCanary版本,则那里提供媒体查询工具。

当你正在使用SASS这篇文章可能是一些利益- http://css-tricks.com/media-queries-sass-3-2-and-codekit/