BEM

编写模块化CSS:BEM

你是否做过多页面的大型网站或者其中一部分?如果你做过,你可能会意识到 CSS 架构不够强大所带来的恐惧。你可能还会研究如何编写可维护的 CSS。由于我们的行业很棒,我们有很多推荐的解决方案。因为专家们的纷纷加入,于是我们有 BEM,OOCSS,SMACSS,Atomic Design 等许多选择。现在,问题不是痛苦 “我不知道该怎么办”,而是: “有这么多的方法,我应该尝试哪个?”我是不是应该把所有的都用一遍,是不是只有一种方法才适合我,或者我是不是应该参考它们做一个自己的架构?。我开始只用一种方法。然后,当我尝试不同的方法时,我开始把我认为有意义的东西包含在我的探索过程中。 在这篇文章中,我想和大家分享一下我如何构建 CSS 以及为什么我这样做。 希望它可以帮助你找到你喜欢的方法。

如何更好的使用BEM

BEM是由Yandex团队提出的一种CSS Class 命名方法,旨在更好的创建CSS/Sass模块。他需要遵循一些特殊规定,有些人认为这些规定很冗余,但是我发现他们对于理解DOM有着很大的帮助。你可以去查看我之前的文章去了解为什么BEM如此伟大。或者你可以去查看这几篇中文文章来了解BEM(《BEM的定义》《为什么我们需要BEM》)。今天这篇文章,是我在假设你对BEM和Sass已经有所了解甚至熟悉的基础上完成的。

关于BEM中常见的十个问题以及如何避免

不管你是刚刚才接触BEM还是已经是一名老手,对于它的思想你是不是都十分的赞美?如果你还没有接触过BEM,在阅读这篇文章之前我建议你先到BEM官方网站进行了解,因为我将对其进行分类表述我对这种CSS理念的观点。

CSS分层

随着CSS的发展,使用CSS有语义化的命名约定和CSS层的分离,将有助于它的可扩展性,性能的提高和代码的组织管理。在我前面的文章中讨论很多关于CSS的问题都可以通过使用一个适当的CSS策略来避免。在这篇文章里,我将着重于讨论使用一种方法或者一个命名规则所带来的好处。这里有很多可供使用的前端方法和命名规则,每个都有自己的优缺点。在几乎所有的案例中CSS被分割成更易于管理的代码“块”。CSS的这种分割方式定义了每一种方法。

BEM在Sass3.4中的提升

BEM在Sass3.3中就已经实现,很容易使用,不过他还是受到一定的限制。Sass3.4的出现,其选择器功能上做了进一步的优化,所以在Sass3.3中使用BEM受到的限制在这里将不在是问题,可以通过自定义的Function做一定的处理,让BEM在Sass中更为强大。

BEM修饰符:多类名 VS Sass @extend

在编写HTML结构时,多类名的运用大家都应该有使用过,虽然这样使用能给制作带来极大的方便,但也存在一定的风险。为了更好的区分,很多时候在使用BEM的命名方式,以有让多类名在同一个元素中变得更独立性,不至于覆盖样式。但在Sass中运用BEM的时候,很多时候提倡使用@extend来扩展。那么是使用多类名更好呢?还是使用@extend扩展更强呢?

崇拜CSS

公认的拥有一个编写和管理CSS的方法比什么都要更好。尽管如此,一些开发人员的实践是不利于语义化质量和长期的可维护性。我们要讨论一些被提倡的"CSS框架方法”的问题和作为Web开发人员,我们如何可以更好的解决这些问题。今天最流行的CSS开发框架技术当属OOCSS,尽管还有其他类似的技术存在,如BEM。这些方法试图对CSS采用面向对象的编程原则。尽管样式语言和面向对象的软件设计原则在概念之间存在一定的问题,这些微妙的东西对于一个欠缺经验的开发人员来说可能不会立即显现出来。最令人不安的是,这些方法已经可以广泛的看到博客给其冠以"最佳实践"的评价。“abscence”的证据来阐述使用这些方法的好处——选择高流量网站只是一小部分——这反应了我的观点,他们代表了一种误导和盲目的崇拜

返回顶部