(这可能已经回答了 – 也找不到答案)
传统的@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; } }
我使用这种技术为一个最近的项目,当你应用这个原则到一个更大的项目,你最终与多个@media查询部分散布在整个css(我到目前为止约20个)。
我很喜欢sass技术,因为它使得更容易遵循覆盖的流程(并且也使它更容易移动的东西)。
但是,我想知道是否有任何缺点,有多个@media部分通过CSS,特别是性能明智?
我试过chrome css profiler,但我看不到任何特定于@media查询。
解决方法
晚了一点晚会,但基于下面的测试,性能影响似乎是最小的。该测试分别显示具有2000个单独和组合的媒体查询的示例页面的呈现时间。
http://aaronjensen.github.com/media_query_test/
主要的好处似乎是文件大小比任何其他 – 这,如果你压缩的CSS生产,将大大减少。
但最终,正如下面的链接帖子所说:
“If you have 2000+ media queries in your CSS,I think that you may want to reconsider your UI development strategy versus using a gem to re-process your CSS.”
详细介绍问题的博客文章:
http://sasscast.tumblr.com/post/38673939456/sass-and-media-queries