(这可能已经回答了-虽然找不到答案)
传统的@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查询特有的内容。
这次聚会晚了一点,但是根据下面的测试,对性能的影响似乎很小。该测试显示了示例页面分别具有2000个单独和组合媒体查询的呈现时间。
http://aaronjensen.github.com/media_query_test/
主要的好处似乎是文件大小比其他任何东西都大-如果您压缩CSS进行生产,则无论如何都会大大减少文件大小。
但最终,如下面的链接所述:
博客文章详细介绍了这个问题:https : //web.archive.org/web/20140802125307/https : //sasscast.tumblr.com/post/38673939456/sass-and-media-queries