【问题标题】:SASS Placeholder for media query?用于媒体查询的 SASS 占位符?
【发布时间】:2013-07-11 06:23:42
【问题描述】:

我发现这种方法可以使用 mixin 轻松添加 @media 块:

@mixin phone() {
    @media only screen and (max-width: 480px) {
        @content;
    }
}

要使用它,只需输入如下内容:

p {
    @include phone { ... }
    span {
        @include phone { ... }
    }
}

问题在于真正的 CSS 输出:

@media only screen and (max-width: 480px) {
  p { ... }
}
@media only screen and (max-width: 480px) {
  p span { ... }
}

复制 @media ... 部分,这会使 CSS 膨胀。

有没有办法让 mixin 像占位符一样工作?所以它将合并所有@content 并将其放在同一个@media ... 块下。

所以结果会是这样的

@media only screen and (max-width: 480px) {
    p { ... }
    p span { ... }
}

我知道我可以将@include phone 放在文件末尾并在该块中写入所有必要的样式。

但是在原始样式之外编写媒体查询样式会更容易阅读和组织。

谢谢

【问题讨论】:

    标签: sass compass-sass


    【解决方案1】:

    Sass 目前没有该功能。您唯一的选择是在单个媒体查询中手动对样式进行分组(或使用具有该功能的第 3 方 CSS 压缩器)。

    https://github.com/nex3/sass/issues/116

    【讨论】:

    • 很高兴知道 sass 仍然无法支持这一点。我做了很多尝试,但都失败了
    【解决方案2】:

    您只需要调整嵌套即可。因为 mixin 会将您的所有内容放入媒体查询中,所以您只想使用一次 mixin 并将所有相关样式放入其中(以避免多个媒体查询)。

    @include phone {
      p {
        span { ... }
      }
    }
    

    如果您尝试为各种媒体查询组合

    的样式,则不可避免地会在预处理或输出代码中出现一些样式分离。

    例如:

    p {
      ...
      span { ... }
      @include phone {
        ...
        span { ... }
      }
    }
    

    希望对您有所帮助。即使您最终得到的输出感觉“效率较低”,它实际上也不应该减慢浏览器的渲染速度,所以我会说优先编写感觉可维护的代码以进行开发。

    【讨论】:

      【解决方案3】:

      SASS 不能将扩展与媒体查询结合使用**,因此当您采用这种代码风格时,目前不可避免地会出现重复的媒体查询。

      您可以在顶层使用媒体查询来构建代码(即按媒体查询对代码进行分组),但这通常是个坏主意。 Eric Meyer,这里的 CSS 大师之一,says(以及许多其他前端爱好者会同意)你永远不应该这样做。我自己在一个项目上尝试过这种方法,我确认你的项目越大,这种代码结构就越痛苦。 SMACSS 和其他代码结构方法也建议不要这样做。

      这种代码结构被广泛使用的地方是 CMS 基础主题(主题模板,也就是初学者工具包)。但它们旨在让用户快速覆盖默认样式,而不是从头开始构建。

      问题是duplicate media queries don't really matter。尽管@cimmanon 可能不同意我的观点,但只有源代码 (SASS) 的可读性和可维护性才是重要的,因为每个现代 Web 服务器都为 CSS 代码提供压缩 (gzip),它只能由机器读取。

      当然,有很多方法可以通过使 CSS 变得异常庞大来破坏您的 CSS。使用非语义 CSS 框架就是其中之一。明智地应用大量本地媒体查询块并非如此。

      【讨论】:

      • 您好,非常感谢。我将继续使用这种方法。我喜欢 Eric Meyer 的观点,即“媒体查询应尽可能靠近”
      • 如果要表达意见,请使用 cmets。看到有人从其他正确答案之一复制/粘贴并粘贴您的意见然后获得接受,这是非常糟糕的。
      • 对不起,@cimmanon 先生,我不是故意冒犯你的。事实上,我既没有在我的答案中复制粘贴一行,也没有认为引用一位出版关于该主题的书籍的专家来表达意见。另外,您的回答已被接受,所以我不明白您为什么抱怨。
      • '重复的媒体查询并不重要' - 您是否碰巧有任何来源表明性能影响可以忽略不计?
      • @wheresrhys, 引用 Snugug 的话:对于它的价值,在断点问题队列 (github.com/canarymason/breakpoint) 上,我们讨论了合并与分散媒体查询是否对性能产生影响,并得出结论结论是差异虽然丑陋,但在最坏的情况下是最小的,在最好的情况下基本上不存在。 github.com/nex3/sass/issues/116#issuecomment-10047925
      猜你喜欢
      • 1970-01-01
      • 2016-08-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-08-13
      相关资源
      最近更新 更多