CSS预处理器mixin与标记类

我处于项目的早期阶段，随着项目的发展，它将积累大量的样式。我们正在讨论CSS预处理器mixin模式的优点，用于DRY我们的样式代码。当mixin参数化时，好处很明显 - 几乎每个实例都必须手写，所以代码膨胀相对较少，特别是如果不经常使用特定的参数化。CSS预处理器mixin与标记类

但是，对于未参数化的mixin，它有点模糊。以清除为例。

在纯CSS中，我们可能会创建一个cf类，然后在标记中调用它，只要有必要。这个效果很好，但是却带有纯粹的表现类的标记。

在SASS，我们可以通过使用一个mixin做到这一点逃离这个：

//in _mixins.scss 
@mixin clear-fix() { 
    &:before, &:after { 
    content: '\0020'; 
    display: block; 
    clear: both; 
    visibility: hidden; 
    line-height: 0; 
    width: 0; 
    height: 0; 
    } 
} 

//in my_component.scss 
@import 'mixins'; 

.my_component { 
    // styles ... 
    @include clear-fix() 
}

这有集中纯粹的表象关注，使我们的风格代码更易于维护的优点。但不足之处在于，编译后的CSS将会非常不稳定，而clear-fix mixin会在它混入的每个块中逐字重复（将其应用于我们以相同方式使用的任何类似的CSS模式）。

我的问题是在代码中重复混合是否可能导致任何重大问题？还是有另一个我没有想到的解决方案？

来源

2014-06-06 acjay

我认为你给出的例子的主要缺点是你在重复使用clearfix的地方......所以在你的例子中，如果你有100个使用clear-fix类的元素，你会有693额外的CSS不需要的行。

两个建议：

，只有当他们采取的参数和CSS属性真正改变价值，我会用混入。使用“void”mixins似乎效率低下，因为您可以使用普通的旧CSS代替。
查看stubbornella的面向对象的CSS：https://github.com/stubbornella/oocss/wiki。如果抽象出你clear-fix混入到一个可重用的CSS对象，你的方式更干（虽然你还是会重复自己一点点）

来源

2014-06-06 16:26:03 biegel

听起来像一个双赢。关键是要确定少量的实际抽象模式，这些抽象模式恰好需要“清除修复”作为细节。然后，所使用的类仍然具有语义上的意义，并且“clear-fix”可以仅作为mixin定义一次，但重复有限次数。 – acjay

你的其他选择是使用extend。这将是DRYer方法，而不是随时重复使用混合，因为它逗号分隔选择器而不是复制样式。

例

.bacon {  
    color: red; 
} 

.smokey { 
    @extend .bacon; 
} 

// Outputs 
.bacon, .smokey { 
    color: red; 
}

http://css-tricks.com/the-extend-concept/

来源

2014-06-06 16:29:04

谢谢你提醒我'扩展'。虽然如果我保持最高级别的工作流程，而不是拥有包含相同清除修复代码的几十个单独的选择器，那么我会有一个选择器，其中包含数十个逗号分隔的情况。在我看来，这仍然是一个可能的性能问题。 – acjay

CSS预处理器mixin与标记类

回答

相关问题