命名CSS的东西真的很难

作者：伊桑•穆勒
时间：09-02-14
原文地址([Naming CSS Stuff Is Really Hard]-[Ethan Muller](https://sparkbox.com/foundry/naming_css_stuff_is_really_hard))

这不是一篇关于CSS架构的文章。这篇文章也不是关于命名约定的。相反，让我们讨论一下所谓的元素。自己的名字。我们用来将样式块链接到它们所关联的元素的东西。

十分之九的开发人员同意:命名是迄今为止编写CSS最困难的部分。这是因为我们无法预测未来。一个类名可能在某一天非常有意义，然后设计发生了变化，第二天它就变成了一个误称。然后，我们的任务是重构标记和样式，使它们有意义。讨厌的东西。

我们该如何补救呢?选择不太可能改变的名字。

我们通常可以将给定的类名归入以下三类:

1. 基于功能类名
2. 基于内容的类名
3. 基于展现的命名

给定类别中的类名往往具有共同的可维护性特征。如果我们在命名时牢记这些类别，那么我们就可以对我们所称的事物做出更明智的决定——这些决定将使我们的CSS更适应变化。

功能类名

<button class="positive-button">Send Message</button>

函数类名看起来像是“正”按钮、“重要”文本或“选定”标签。这些元素的样式取决于它们的功能或意义。类名、它应用的样式和应用样式的原因之间有很强的联系。由于这个原因，类名与这些样式相关联。

因为样式和它们的元素之间有这种牢固的联系，所以这些样式不太可能改变。如果你改变了一个积极按钮的样子，你可能会想要改变整个网站上每个积极按钮的实例。如果你的设计师正在考虑改变“一个积极的按钮”，而不是“设置菜单中的‘添加用户’按钮”，那么你就处在一个愉快的、可维护的位置。你在用系统思考，而不是页面。

函数类名很棒。如果可能的话，这可能就是您想要编写样式的方式。但这里有一个问题:函数类名并不总是可行的。

设计并不总是合乎逻辑的。当我们讨论按钮时，很容易给出一个函数类名的例子。大多数时候，它们的功能与它们的样式密切相关。但要为我们所写的其余99%的风格给出例子就不那么容易了。有时这个方块需要一个嵌入的阴影，因为它看起来很漂亮。有时图标需要在悬停时增长，因为它很可爱。有时文本需要是橙色的，因为它是橙色的。并不是网站的每一个视觉方面都有其功能上的合理性，这是可以的。

那么开发者该怎么做呢?我们正处在一个十字路口。如果想不出一个好的函数类名，可以根据元素的内容或表示形式来命名元素。两者对可维护性有不同的含义。

基于内容的类名

<button class="submit-button">Send Message</button> 

基于内容的类名是描述它们所包含内容的类名。如果您曾经见过像submit-button、intro-text或profile-photo这样的类名，那么您看到的就是基于内容的类名。这些类名感觉很干净。它们有助于明确区分内容(HTML)和样式(CSS)。

理论上，这可以让你完全重新设计你的网站的外观和感觉，而不触及你的HTML，像CSS禅意花园。看起来是很大的福利，对吧?

现在是我让你们坐下来提出这个问题的时候了 : 这对我有什么好处?

我从来没有被要求在不修改HTML的情况下重新设计网站。很有可能你也没有。当然，有些HTML可能会因为与后端系统集成而受到限制。但是一旦您失去了对HTML的控制，您就可能需要编写一些不太理想的hack CSS来进行设计更改。请记住，CSS Zen Garden更多的是一个CSS技术演示，而不是一个维护CSS的例子。如果不需要，不要只优化css重新设计。

如果您正在处理小型网站，那么基于内容的类名工作得很好。然而，随着站点的增长，它们变得越来越不合适。它们不利于样式重用。如果登录按钮和提交按钮看起来一样怎么办? 这在CSS架构中是如何表示的?为了避免重复样式块，您要么必须用逗号分隔选择器，要么使用预处理器进行一些扩展。这两种选择都很难组织并适合大型项目。如果有一种更好的方法来重用块的样式就好了…

基于展现的命名

<button class="green-button">Send Message</button>

表示类名描述了元素看起来的方式，比如绿色按钮、大字或曲线边框。名称本身描述了应用的样式。

这些类有利于代码重用。它们不关心是否被用来样式化产品标题、用户名或页面标题。他们只知道要把文字放大加粗。这也带来了适当伸缩的好处。在开发新组件时，可以获取现有的样式并将它们添加到新的标记中。您不需要担心将新样式适合于已存在的架构，因为您没有编写任何新样式。

演示课也是非常自我描述的。如果一个元素的类名是round-image而不是profile-photo，那么通过检查代码，开发人员可以推断出更多元素的样子。可以说表示类引起了一些可维护性问题。由于它模糊了标记和表示之间的界限，许多设计更改将需要HTML编辑。如果您预见到这将成为项目的一个问题，请谨慎使用。

但这不是语义!

演示课的口碑很差。很多人会避开它们，因为它们不是语义性的。然而，这是个神话，尼古拉斯·加拉格尔打破了它。区分语义HTML和语义类是非常重要的。

Nicolas说得很好:编写语义HTML的原则是现代专业前端开发的基础之一。

大多数语义都与现有或预期内容的性质有关，但是，并不是所有的语义都需要是内容派生的。类名不能是非语义的。不管用什么名字，它们都有意义，有目的。类名语义可以与HTML元素的语义不同。

在我写这篇文章的时候，“非语义”这个词下面有一个红色的歪歪斜斜的字。非语义类名是不存在的。每个类名背后都有一些含义。在编写类名时，不要忙于创建语义上最合适的类名。请记住，类名是给开发人员的，而不是给用户的。请考虑创建类名，以便为您的开发伙伴和未来的您提供尽可能多的信息。

总结

函数类名通常是最好的选择。当你能用到它们的时候，就去做。如果您想不出一个可靠的函数名称，考虑您的项目的性质和它将如何发展。经验法则:基于内容的类名更适合小型站点;表示类名称更适合大型站点。开发人员可能会对这种东西很敏感。没有人希望项目变得不可维护，但是每个人都有不同的想法来防止这种情况的发生，特别是对于类名。考虑您正在使用的类名类型的性质，并询问它与项目的目标是否一致是很有帮助的。