在我们最近关于 CSS 属性排序 的调查结果总结中，它引出了 CSS 样式指南这一更广泛的问题。属性排序只是您在制定完整样式策略时需要做出的众多选择之一。命名是其中一部分。分段也是其中一部分。注释、缩进、整体文件结构…… 所有这些都构成了完整的 CSS 样式指南。
让我们总结一些现有的样式指南。
但首先…… 不是模式库。
我喜欢模式库。例如 Twitter Bootstrap 或 GEL。我认为它们是一种非常棒的工作方式，尤其是在大型网站和 Web 应用程序中。这篇文章不是关于这些的。我们以后会对这些进行总结，因为我认为这也很有价值。这篇文章是关于CSS 本身的样式指南。
列表
我将在下面列出每个样式指南中我喜欢的部分。
GitHub
根据经验法则，嵌套深度不要超过 3 层。如果您发现自己需要更深的嵌套，请考虑重新组织规则（无论是所需的特殊性，还是嵌套的布局）。
首选无单位的行高，因为它不会继承其父元素的百分比值，而是基于字体大小的倍数。
使用尽可能短但又足够长的 ID 和类名。
例如 #nav 而不是 #navigation，.author 而不是 .atr
不要在选择器中使用除连字符以外的任何字符（包括无字符）连接单词和缩写，以提高理解力和可扫描性。
例如 .demo-image 而不是 .demoimage 或 .demo_image
惯用 CSS
配置您的编辑器以“显示不可见字符”。这将允许您消除行尾空白、消除意外的空行空白，并避免污染提交。
长而用逗号分隔的属性值（例如渐变或阴影的集合）可以跨多行排列，以提高可读性并生成更有用的差异。
使用单独的文件（通过构建步骤连接），以帮助分解不同组件的代码。
CSS 技巧
我全面禁止在 CSS 中使用 ID。它们实际上毫无意义，只会造成危害。
此部分标题前也添加了 $。这样，当我查找某个部分时，实际上是在查找
$MAIN而不是MAIN。
在开发人员需要确切了解 CSS 代码块如何应用于某些 HTML 的情况下，我经常在 CSS 注释中包含 HTML 代码片段。
Smashing Magazine
Vitaly Friedman 的“使用 CSS 样式指南提高代码可读性” →
对于大型项目或大型开发团队，拥有简短的更新日志也很有用。
为了更好地概述您的代码，您可以考虑对简短的代码片段使用单行代码。
ThinkUp
如果宽度或高度的值为 0，则不要指定单位。
引用选择器块的注释应位于与其引用的块紧邻的上一行。
WordPress
在部分之间添加两行空行，在部分中的块之间添加一行空行。
宽泛的选择器使我们能够提高效率，但如果未经测试，可能会产生不利后果。特定位置的选择器可以节省我们的时间，但很快会导致样式表混乱。请谨慎使用。
魔法数字是不吉利的。这些数字是一次性使用的快速修复。例如：
.box { margin-top: 37px }。
SMACSS
Jonathan Snook 的 CSS 可扩展和模块化架构 →
这是一个庞然大物，很难只提取几个引用。但是……
将您创建的每种新样式都添加到单个文件的末尾会使查找变得更加困难，并且对于任何其他参与项目的人员来说都会非常混乱。
如果操作正确，模块可以轻松地移动到布局的不同部分而不会中断。
仅包含包含语义的选择器。span 或 div 没有语义。标题有一些。元素上定义的类有很多。
更多？
您的组织是否维护和使用公共样式指南？请发布它！
以前，我使用多行 CSS 格式。在阅读了您关于 CSS 格式的旧文章之一后，我现在成为了单行 CSS 的拥护者。它更短更快。此外，我认为大多数人都会想出自己的格式系统。
我的情况也完全一样。在我看来，为每个属性单独一行会使可读性降低。但我几乎只在没有团队的情况下处理 CSS。
要修改您的 CSS 属性之一，无论它是在您的情况下应用于类还是 ID，您都必须左右滚动并视觉上找到它，并将其与同一行中的其他属性并排放置。
在垂直设置中，例如按字母顺序排列，您可以更容易、更快地查找和修改内容。
.class {color: #000000; background: #FFFFFF; font: 1em Arial, Helvetica, san-serif; font-style: italic; height: 150px; width: 500px;}
对比
.class {
color: #000000;
background: #FFFFFF;
font: 1em Arial, Helvetica, san-serif;
font-style: italic;
height: 150px;
width: 500px;
}
“我在 CSS 中完全禁止使用 ID。它们根本没有意义，只会造成危害。”
再没有比这更正确的话了
有人可以详细解释一下吗？我假设人们只会使用类而不是 ID。ID 真的没有任何优势吗？
据我了解，它对元素具有类似 !important 的效果。如果你使用 #id，那么你无法覆盖该元素的样式，除非你再次使用 #id 引用它。举个用例的例子……
我认为这是正确的 :|
我认为使用 ID 的一个理由是，它们应该可以更快地渲染 CSS。Chris 写了一篇关于这个主题的文章。https://css-tricks.cn/efficiently-rendering-css/ 我意识到这篇文章已经 2 年了，但我认为它仍然适用。
Standardista 使用此图形很好地解释了它.
仅供参考，我完全不同意这种说法。ID 有其用途，并且很多时候特异性不是问题，而是解决方案。
对表格的全面禁止已经迫使人们想出一些疯狂的想法……比如使用列表代替数据表，所以让我们确保我们不会对 ID 做同样的事情。
我已经看到人们使用这样的规则
.someclass .someotherclass .yesanotherclass .canyoubelievethisisanotherclass .andyetonemore {…}
现在，作者使用类来提高特异性，这会降低性能，创建臃肿的样式表等。
ID 有很多优点，我认为恐吓人们不要使用它们是错误的。
好的，我明白了——我想我一直都在某种程度上潜意识地理解这个概念，而没有坐下来真正识别它做了什么。我一直都遵循容器是 ID，而容器内的任何内容都是类的原则，而且我一直都只是使用 ID 如何覆盖来帮助我不必创建额外的类
所以，例如，与其为标题创建特定的 h2 类，我可以在标题内定义任何 h2 的颜色。也许这是一种不好的做法，我之前完全不知道 lol。
我必须同意 @Thierry 的观点。我认为 ID 非常有用。我也注意到“.class .class .class .class .class .class”这样的情况，并且想知道这到底是怎么回事。实际上没有意识到人们反对 ID。我无法说出我是否理解这种论点。
我完全赞成“永远不要使用 ID”的说法。如果你遇到特异性问题，使用比类强大无限倍的选择器就像用大锤解决需要小刀的问题（或者其他什么，你知道我的意思）。
Chris，
你是在说
这是否意味着你假设使用 ID 是特异性问题的结果？因为我认为这与事实相去甚远。许多作者使用 ID 来表示其语义——它应该被使用的正确方式 ;-)
如果元素的样式**旨在**是唯一的，那么使用**.logo**比**#logo**更好在哪里？我并不是说要使用 ID 来填充一个包含所有元素样式的规则，我只是说要使用它来引入唯一的声明。带有 ID 的元素可以通过规则的组合（通过类型、类、ID 或任何其他方式）来设置样式。
此外，请注意我的示例使用了“logo”这个词，但是当名称更通用（因为类名应该更通用）并且项目很大时会发生什么情况？然后作者**无法**安全地假设给定规则仅针对单个元素。从那里，整个事情就会崩溃，因为他们害怕更改该规则中的某些内容，他们最终会引入另一个类——只是为了确保他们不会弄乱站点其他页面上的另一个元素。
此外，你是否认为以下规则表示一个严重的特异性问题？
.class1 .class2 .class3 .class4 .class5 {…}
我经常看到这些，在我看来，它与“将 ID 用于几乎所有内容”没有什么区别。但问题在于工具的使用方式，而不是工具本身。
你使用了“大锤”的比喻，所以我要用这个来结束
如果你只有锤子，所有东西看起来都像钉子！
干杯
我明白你的意思。但是，我仍然可以想到一些通过 ID 引用内容会是一种快速简便的方式来定位该内容并“组织”（如果可以这样说）页面部分的实例。它们之所以很棒，是因为它们是唯一的。至少根据我的经验，它们让我感觉不那么不知所措，哈哈！
当你的自动化测试脚本（例如 watir-webdriver）使用 ID 时，它们对于识别页面上的元素非常有用。
我的观点是 ID 和类都有其位置，并且都应该在项目中使用。有些人已经提到，从语义上讲，#logo 比 .logo 更好
毕竟，ID 有特定的用途，即在页面上唯一地标识一个元素。类用于将多次出现的元素，例如，你可能有一个 #comment-thread，并且在其中，具有 .comment-body 类的元素或类似的东西。
我找不到使用 .comment-thread 比 #comment-thread 更好的理由，如果人们在为此元素设置样式时遇到问题，因为这是一个 ID，我不得不质疑你在做什么，因为我从未遇到过这样的问题。
仅供参考 ;-)
@Thierry，
你建议的大多数示例都是开发问题，而不是对何时使用 ID 比类更合适或更不合适感到困惑。
例如，开发人员认为对使用表格有全面禁止，即使用于表格数据，也说明他们对 CSS 规范的理解存在更深层次的问题，而不是任何编码方法都可以解决的。
此外，我知道你只是将其用作示例，但像 .class1 .class2 .class3 .class4 .class5 {…} 这样的东西只是将类的使用提升到了极致，并且执行此类操作的开发人员也可能同样滥用 id 名称来提高特异性，最终得到类似 #header div #branding #logo img {…} 的结果。
@Sean，
看来你同意我的观点。ID 本身没有任何问题，只是人们使用它们的方式。
@Thierry，
我同意类会带来自身的问题，但我从未在我的代码中使用 ID，并且 IMO 它们会强制执行一定程度的特异性，这违背了 CSS 中 C 的目的。我唯一使用 ID 的时间是当我与具有其自身 ID 的第三方插件发生特异性冲突时，该插件在其内部隐藏了最大量的 CSS 代码，我需要重新设置其样式
@Sean，
“ID 会强制执行一定程度的特异性，这违背了 CSS 中 C 的目的”
我完全不同意这种说法。众所周知，C 代表级联，它涉及很多方面。如果我们从大局来看，ID 并不是问题……它们是解决方案的一部分。
如果“ID 因为太具体而不好”，那么为什么我们不尽可能避免使用类呢？
几年前，我认为最好的方法是避免使用任何挂钩并依赖后代选择器。我几乎不使用类，更不用说 ID 了。当时，我本可以与任何人争论使用类是不好的，因为“它们太具体了”。
今天我听到关于 ID 的论点完全相同……
无论如何，我们有“工具”来应对各种挑战。在我看来，完全忽略其中一些工具是不明智的。
我们过去也讨论过“!important”。我多次读到“永远不要使用 !important！”
是的，当然 :)
@Thierry，
我的意思是第三方插件
我看不出在 CSS 中使用 ID 的问题。你有没有使用过 Dot Net 应用程序？它们使用 ID 来进行 .vb 或 c# 中的调用，所以我有时会使用这些现有的 ID 来设置样式。但在你的情况下，你将通过传入类然后将其连接到 CSS 文件来增加文档的体积，从而增加加载时间？至于对齐我的 CSS，我通常会添加位置元素，然后是盒模型内容，然后是任何文本位，然后是前缀-
.classHere{ float:left; position:relative; padding:8px; margin:16px 0 4px; background:#f8f8f8; color:#505050; -moz-box-shadow:1px 1px 1px rgba(0,0,0,0.8); -webkit-box-shadow:1px 1px 1px rgba(0,0,0,0.8); box-shadow:1px 1px 1px rgba(0,0,0,0.8); }就是这样。我认为它使所有内容保持顺序并易于阅读。
@jamie，
我的 CSS 也是这样排序的，通常会先声明任何定位类型的声明，然后是 margin/padding，最后是其他属性。我需要花很长时间在大脑中解析字母表才能按字母顺序排列东西。我从未在 .net 中工作过，我理解在那里使用 ID 的用途，以及在 Javascript 中，只是在 CSS 中，除非被迫使用，否则我不会使用 ID。
@Thierry，好吧，每个人都有自己的方法。我想重要的是要保持一致，并记录我们的代码，以便下一个开发人员在加入项目时能够轻松理解发生了什么。
我已经在其他地方表达了我对 ID 选择器 的看法。
我刚刚为我们在 Typecast 这里开发的应用程序编写了一些内部 CSS 规则。这些规则建议永远不要将 ID 用于 CSS。我坚信，编写 CSS 应该始终专注于可重用性，它应该关于创建模式而不是一次性代码。ID 本质上是唯一的，因此与之相悖。无论你认为自己只使用一次模式，总有一天你会发现自己需要再次使用它。
这种方法也适合我们，因为我们的应用程序中有大量 Javascript 交互，将 ID 留给后端开发人员使用有助于减少设计和交互之间的冲突，因为我们的应用程序在不断发展和变化（这在过去给我们带来了一些问题）。
正如一些人已经提到的那样，这种决定通常取决于具体情况和正在处理的项目类型——对我们有效的方法可能对其他人无效。
当然，接下来我们有趣的部分是对我们已经完成的所有工作进行反向适配此规则！
看到这次对话真的很有趣，这是那些通常不会被谈论的基本核心内容之一，因为人们对新的技术或属性感兴趣。
但我倾向于站在 ID 支持者一边。
是的，类使重复使用相同的代码片段变得非常容易，这很好。但如果有一个元素你知道在每个页面上都是唯一的呢？一个如果在页面上出现两次，就会表明某些地方出错的元素（例如 CMS 输出奇怪的代码块）。
如果你使用容器来居中你的网页，并且知道你不会想要在你的页面上出现两个
<div id="page-container">...</div>元素，因为所有内容都应该放在这个唯一的容器内。那么使用 ID 可以将此固化在代码中，如果有两个这样的元素，可能会有一些视觉上的提示表明事情没有按预期工作。相同的示例可以应用于 Thierry 提到的 .logo/#logo 点，对于大多数网站来说，你知道你的徽标只会在页面上使用一次，否则看起来会很奇怪，所以如果最终页面上出现了两个
#logo元素，你就知道在生成该页面时出现了一些问题。对于大型网站来说可能有所不同，但正如文章开头所说，你可能会以不同的方式处理样式（库、预处理器等）。
因此，对于小型网站，我实在看不出在充满信心地做一些事情并说“我知道页面上不会有两个徽标，让我们将其提交到代码中”有什么问题。
这只是我对这场辩论的看法……
id 选择器用于为单个唯一元素指定样式。
类选择器用于为一组元素指定样式。与 id 选择器不同，类选择器最常用于多个元素。
在这种情况下，id 可以用来设置页面徽标区域或部分的样式。
另一方面，类可以多次使用；例如，在任何需要为黑色并具有白色背景的文本上，而在通常情况下该文本为粉色。
非常好。我总是有一些问题，我总是四处探索以了解更多信息并正确地做事。正是因为 Chris，我现在才能编写有效的 xhtml 代码，以及现在的 html5 代码（我不知道如何错过这段代码）。
不过我有一个问题，你说
为什么 #fff 不行？我不明白。
我总是有一个问题，我从不做这个，因为我认为更多的代码不好。
但我总是对这个问题有疑问
我改为
我们是用单引号 ‘ 还是双引号 ”，或者干脆省略？我个人使用双引号。
我也想知道为什么 #fff 比 #FFF 差。我对我的背景代码也做了同样的事情（忽略包含“-image”）。但是，我使用 ‘ ‘ 而不是 ” “。
我认为这更多是为了保持代码的一致性，而不是因为它不好。就像在编程中，他们说要么使用 camelCase 要么使用 underscore_it。
当我看到同一代码中出现 #FFF 和 #fff，甚至 #FFFFF 时，我会感到厌烦，这多出了 3 个不必要的字符。
记录在案，我一点也不在乎 FFF 和 fff。
甚至不太关心一致性。
你不会“阅读”十六进制代码，所以它无关紧要。
对于 ‘#FFF’ 与 ‘#fff’，实际上根本没有问题，除了代码的一致性。我们在这个地方同时使用 Photoshop 和 Fireworks，因此我们最终会得到很多变化（PS 不会而 FW 会将十六进制大写）。
对于 CSS 中的单引号和双引号，我总是使用单引号，原因如下：当稍后需要在 JavaScript/jQuery 中添加/编辑 CSS 时，它可以避免转义引号的麻烦。
这显然只适用于在 JavaScript 中使用双引号作为字符串的情况（我这样做）。
与
颜色通过组合红色、绿色和蓝色光 (RGB) 来显示。红、绿、蓝值的组合范围从 0 到 255，总共可以产生超过 1600 万种不同的颜色 (256 x 256 x 256)。
大多数现代显示器能够显示至少 16384 种不同的颜色，在本例中使用 RGB，它实际上指的是 RRGGBB——一个以 # 符号开头的十六进制值，写成 3 个两位数。使用的数字/字母越多，对颜色调色板的指定就越精确。
CSS 中的颜色可以通过以下方法指定：十六进制、RGB、RGBA、HSL、HSLA 或预定义/跨浏览器颜色名称（红色、粉色等）。
在大小写方面，W3C、Photoshop、Colorzilla、Kuler 等通常使用大写格式，类似于 Unicode 的写法。它不会影响颜色的解释，仅仅归结为美观和压缩。
__
你的背景问题是长属性声明与简写属性声明的问题。例如，如果你要使用重复的模式，则需要应用另一个 CSS 规则。
这是一个 font 属性的示例
也可以这样写
__
根据 W3C 的建议，URI 值（统一资源标识符，包括 URL、URN 等）的格式为 value url (‘ 后跟可选的空格，后跟可选的单引号 (‘) 或双引号 (“) 字符，后跟 URI 本身，后跟可选的单引号 (‘) 或双引号 (“) 字符，后跟可选的空格，后跟 ‘)。使用任何一种或都不使用都可以，但是，这两个引号字符必须相同。
@Karl 和 Jonathan Graft。不使用的一个原因
代替
是“background”定义了背景的所有不同选项，包括 background-image 和 background-color，即使你没有指定它们。我不记得这是否有效
但我可以肯定的是，这个无效
在第二种情况下，“background”语句将覆盖“background-color”语句。如果我同时对给定元素使用图像和颜色作为背景，我几乎总是将它们分别键入。或者即使我不这样做，我通常也会以这种方式键入，以防将来需要添加其中一个或另一个。可能看起来过于谨慎，但无论如何这是我的看法。
我有两点感受强烈……
1) CSS 规则写在一行上。为什么？我们都使用宽屏显示器，而且我们不使用纵向模式，那么我们为什么不利用我们可用的更多横向空间，以便在一页上看到更多 CSS 呢？
当我看到非常长的样式表，只使用了很少的横向空间，并且一次只能在屏幕上看到几条规则时，我会感到抓狂。
2) 我更喜欢这样 …. {width:80px; height:80px;} 而不是这样… {width : 80px; height : 80px;}
我知道在这里看起来并没有太大的区别，但在等宽字体 IDE 中确实有区别。在冒号前后留空格意味着属性和值之间没有视觉上的分组。80px “属于” width 属性，因此应该与它分组，并与 height 属性分开。这使得它更容易阅读并快速找到属性。
我也同意不使用 ID。我已经停止使用它们，并且减少了关于特异性的头痛。
如果你在一个版本控制环境中，单行 CSS 就完全行不通了，因为它会使差异比较毫无用处。加上 CSS3 的供应商前缀，我坚定地回到了“多行” CSS 的阵营。我曾经也和你有着完全一样的想法，所以我很理解你。
我发现多行 CSS 最终会更尊重与我一起开发的人。
我尝试过使用单行 CSS，在某些情况下我会将其设置为单行（如果我仅定义 1 或 2 个属性，并且永远不会超过这些）。
但我发现令人沮丧的是，每个人都有不同的工作方式，并且换行的方式也不同。使用多行 CSS 可以确保每个人都能看到相同的内容。
我喜欢单行 CSS 以容纳更多内容的想法，但这不切实际。作为 Web 开发人员/设计师，我们经常会担心文本行在最终产品中的长度，以便用户可以轻松阅读。那么，为什么你想强迫自己阅读跨越 20 英寸以上显示器全宽的文本行呢？更不用说它不像文章中的文本，你可以在其中使用上下文线索和已读内容来大致保持位置。
.class1{height:10px; width:20px; border: 1px solid #ccc; display:block; float:left} .class2{height:20px; width:20px; border: 1px solid #eee; display:block; float:left} .class3{height:20px; width:20px; border: 1px solid #ccc; display:none; float:right} .class4{height:10px; width:10px; border: 1px solid #ccc; display:block; float:left}这很难阅读（此处评论系统的格式使阅读更容易），并且只有大约 60-70 个字符宽。
我非常喜欢 GitHub 风格指南 :) 我相信当我开始认真对待 CSS 时，它是第一个我深入研究的指南。
我喜欢它，唯一真正困扰我的是使用 2 个空格而不是缩进。可能只是个人偏好。
我完全同意！我的编码风格一直是使用 Tab 键进行缩进，过去如此，将来也如此。
他们选择 2 个空格很有意思。我最近从使用硬 Tab 切换到软 Tab，因为我发现它在不同平台和编辑器中效果更好（空格就是空格，而 Tab 键可能很奇怪）。但我使用 4 个空格，这通常等于一个 Tab 键。
但我发现 2 个空格有点乱，看起来像是有人不小心多按了几下空格键 :\
两个空格对我来说也很奇怪，我刚刚阅读了这些内容以了解其他人的看法，我意识到这个帖子已经两年了。Tab 键是一个按钮，每次都能可靠地生成相同数量的空格，而使用实际空格则会留下更多出错/混乱的空间——我无法理解偏好空格的原因。此外，你还可以使用 Notepad++/Textwrangler/Dreamweaver 将大块代码缩进，这意味着当你快速敲击一些最后一刻的样式时，很容易回溯并整理你忘记添加空格的内容。
但我想也许空格要求来自 Tab 键存在问题的场景？似乎最好的方法是在你选择的编辑器中设置“Tab”以生成空格（而不是 Tab 键）。不停地按空格键让我抓狂，但我不喜欢东西排列不整齐，所以没有一个按钮来添加空格会很烦人。
可能是在正确的时间发布的最有帮助的文章。我目前正在考虑编写一个风格指南，需要一些参考点。
幸运的是，我同意每位作者提到的绝大多数观点。
在大多数情况下，是的，但对于高级布局选项，ID 并不是一件坏事，恕我直言。我认为 #header 和 #footer 在这里是可以的，因为它们是页面上唯一的组件。但我理解 Harry 的意思。
但到目前为止，在阅读过程中，我还没有看到太多关于使用简写代码的提及，例如 background 或 padding 而不是 background-color 或 padding-left padding-right，只在需要特异性时使用长写，在其他大多数情况下使用简写。（需要添加到我的风格指南中！）。
我想看到更多关于 CSS/LESS/SASS 文档工具的提及；KSS 是目前唯一真正可用的选项，还是自动化文档并不流行？就我个人而言，我认为这是一个非常棒的工具，可以为网站样式的每个版本构建一个完整的文档，以了解在哪里使用了什么样式。（我知道你可以直接查看 CSS 文件，但在大型网站中，这将非常方便）。
WordPress 也有自己的简短 CSS 风格指南
http://codex.wordpress.org/CSS_Coding_Standards
哦，天哪，我忘了那个了。不过我找到了他们的最新版本（不是 Codex 中的那个），并将其包含在文章中。
感谢包含手册中的 WordPress 版本——我现在已经删除了 Codex（维基）页面，改为指向该页面。在两个地方维护不断变化的标准似乎没有意义 :)
即使我理解为什么 ID 可能有害，但我认为它们不应被禁止。它们非常有用，只是并非在所有情况下都适用。
无论如何，Chris，这是一篇很棒的总结，很高兴看到关于 CSS 的如此好的建议。我特别喜欢 Nicolas Gallagher 的建议。
“使用尽可能短但又足够长的 ID 和类名。” 当你在团队环境中工作时，这一点非常重要。太短则毫无意义，太长则很烦人。
我完全同意 Dave 的观点。人类也阅读样式表！让我们希望并祈祷有一天命名约定也能得到重视。
这些风格指南中是否有任何包含列出属性的顺序？处理其他人样式表时最令人烦恼的一点是属性的位置不稳定且不一致。
Google 风格指南建议按字母顺序排列声明，我还没有阅读完其他所有内容。
http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml#Declaration_order
我个人更喜欢按类型 -> 按字母顺序排列。按类型是指我将属性大致分类为
布局：页面内，如（display、float 等）
表单：width、height 等
样式：border、margin、padding 等
文本：font-size、font-family 等
并在这些组内按字母顺序排列。虽然现在我正试图更多地了解 OOCSS，所以我一直在将它们分解成单独的类以实现可重用性。
这类帖子总是很有趣。了解其他人如何编码总是好的，以便检查自己是否可以做得更好。
顺便说一句，你错过了 星巴克风格指南。
那是一个模式库，而不是 CSS 风格指南=)
Hawidu CSS 的语法指南 指导了这个项目。人们可能真的不喜欢它使用的风格，但对我来说很棒。
Hawidu CSS 框架背后的理念是，一个 [工作] 项目将是一个尽可能接近压缩但仍然可读的单个文件。这种风格的项目避免级联，在合理的情况下使用除 class/id 之外的属性进行样式设置，并且仅在需要时粘贴花哨的功能。
很棒的参考。由于我是 Web 新手，目前正在自学，因此拥有几种不同的想法可以翻阅，不仅可以了解其他人如何做某事，还可以了解自己会怎么做并进行比较，这真是太棒了。谢谢。希望看到它更新和扩展。
我认为这个有点旧了，但可能仍然不错
http://na.isobar.com/standards/
而且它涵盖的不仅仅是 CSS。然后在 gimmebar 上有一个列表
https://gimmebar.com/collection/4ecd439c2f0aaad734000022/front-end-styleguides
我记不清是谁把那整合在一起的了……有人知道吗？再说一次，可能不仅仅是 CSS，但肯定与这篇文章相关。
那么图像引用中的引号是怎么回事呢？
wp
.class { /* 正确使用引号 */
background-image: url(“images/bg.png”);
font-family: “Helvetica Neue”, sans-serif;
}
google
/* 建议 */
@import url(//www.google.com/css/maia.css);
html {
font-family: ‘open sans’, arial, sans-serif;
}
只是内部样式？
图像引号是可选的。包含空格的字体系列名称*需要*引号；单引号或双引号 – 都没关系
有用的信息。感谢分享。
我不确定是否只使用连字符来分隔选择器中的单词。例如，当使用 OOCSS 方法时，我觉得需要通过命名约定来分隔模块、它的变体、它的组件等。例如……
.link-list { }
.link-list_item { }
这里，我使用下划线来表示“link-list_item”元素是构成“link-list”的组件或部分。
基本上，我认为这实际上提高了 CSS 的理解，而不是所有内容都只是连字符。根据命名约定很容易分辨元素层次结构，这比缺点更有益处。
不错。我将开始使用它。
我理解为什么你不想使用 ID，但专家提出的不应使用它们的笼统说法可能需要限定。目前存在一些针对 ID 的“猎巫行动”，我不相信它在现实世界中完全可行。
例如，恕我直言，在某些情况下，使用 ID 作为选择器是最实用方法（我想到的是在使用无法以实用方式更改标记的 CMS 时）。我也不介意使用它们来设置我已知永远不会更改的内容（例如，设计中的基本样式，如 #sidebar）。
总之，我想说使用类是首选且“最佳实践”，并且应该了解使用 ID 作为选择器的含义，但不要害怕如果某些内容以这种方式设置样式，世界就会终结。通常还有更大的问题需要解决！
Ben，你说
也许我错了，但我对此的第一反应是，如果 CMS 无法以实用方式更改标记，并且它将 ID 添加到这些不可触碰的元素而不是类，那么这听起来像是一个非常糟糕的 CMS。通常，CMS 会添加类（就像 WordPress 所做的那样），而不是 ID，或者除了 ID 之外。
你是否知道仅添加 ID 且不允许你更改标记的 CMS？我对不同的 CMS 没有足够的经验，但这听起来不太可能发生，即使有也可能很少。
嗨，Louis，原则上我完全同意，但有时基于象牙塔式的理想化很容易把事情描绘成负面的。我与拥有自己的（有限的）CMS 系统的组织合作过很多次。
整个世界并非都运行在最新的 CMS（甚至开源）系统上，并且许多客户和机构都在运行无法控制标记特定区域的遗留系统。
但是，即使你可以（使用类而不是 ID），我仍然认为选择使用 ID 并不一定构成编写 CSS 的严重错误。就像与网络相关的所有其他事情一样，我将求助于“视情况而定”的陈词滥调。
Harry Roberts 也有这个
https://github.com/csswizardry/CSS-Guidelines/blob/master/CSS%20Guidelines.md
但我不知道它与你在帖子中链接的那个有多么相似/不同……？
biemedia.com 的前端开发负责人……
使用帖子中的一些内容 +
当使用 CSS（:target – onclick、:hover、:focus（最好当然还有过渡）对 JavaScript 事件进行分阶段处理时，在新的、有良好文档记录的部分中声明这些块，并在基本部分/块中使用明显的参考注释。考虑到 ID 块大多是不必要的，如果完全必要，请将其保留用于微调。结合此方法
以允许你构建 CSS 部分来模拟 JavaScript 单例，以及你的 CSS 块作为子类的方式构建你的 HTML/CSS – 意思是：使你的 CSS 尽可能看起来像 JSON（一种普遍理解的模式）。这包括为了使你的代码更具语义/自记录而进行的看似不必要的父类迭代。
例如：.parent .child .babyClass{}. 或：.parent .child, .parent .sibling{}. 不是：.babyClass{} 或 .sibling{}。
在 CSS 中尽可能多地进行 GUI 设计（判断调用 :-/），并尝试仅为 DOUI（发音：Dough-EE：面向数据 UI）保留 JavaScript。这将逻辑处理与图形表示分开，但你始终可以使用 JavaScript 覆盖你的 CSS。
非常关键：使用带 content 属性的 CSS :before/:after 可以避免在 CSS 和 JavaScript 之间重复事件，只需添加图形更改（CSS）和文本（不是 html）更改（使用 JavaScript innerHTML）。
另外，知道自己错了很重要。
“如果 width 或 height 的值为 0，则不要指定单位。”
这句话，我同意你的观点。
你忘记了添加 Google 样式指南的链接。http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml
我个人的 CSS 样式指南：css.thenew.fr (http://css.thenew.fr)
这些都是很棒的东西。我正在查看 GitHub 的内容，它有一些非常好的指南。我特别喜欢他们解释表单样式的方式。我一直很难创建合适的、结构化的样式表。
我同意，谁在乎 FFF 或 fff。
关于类优先于 ID 的所有讨论……我一直被教导，当元素需要使用多次时使用类，对于其他所有内容（如 #wrappers 和 #headers），我使用 ID。实际上，就在前几天，我需要覆盖某个元素，但由于我在该元素顶部使用了 ID，因此无法覆盖。这些是在我们应该硬着头皮将 ID 更改为类的情况下吗？顺便说一句，这是一篇很棒的文章，它确实引发了一些讨论。
感谢收集，我知道其中一两个，但真的感谢你分享这些 :)
测试。
只是在测试如果提交带有内联样式的评论（因为它们显示在评论“预览”中）会发生什么。提交时它们会被删除 :)
我相信是 Php strip_tags() 函数删除了此类内容。有助于防止人们在你的页面上执行脚本。你可能会惊讶于人们使用 Javascript 做出的创造性事情。
我唯一缺少的是一个完美格式化的示例。
只需给我们提供 CSS 编码的最佳实践。像这样
还有……哪个更好？
或
为什么？
我绝对同意建议的更新日志。我遇到过太多公司（作为软件顾问），它们没有更新日志，也无法弄清楚它们如何处理变更管理。顺便说一句 - ID 也应该渲染更快的 css。
实际上，id 和 class 有不同的作用，我的概念在 Mozilla 的在线 css 编辑器中很清楚
我同意他们所有人至少一个陈述。我不同意的是“单行 css 语句”。它根本不可读，只会使你的文件代码变宽。在理论部分编写每个 CSS 语句将使盒模型、纯样式（字体、颜色）和特殊效果（border-radius、渐变）变得清晰。这将使你自己和以后接触样式表的所有人更容易。
我认为这一点尚未涉及，但 #id 作为你的 Javascript 函数的挂钩非常有用。它比使用 .classes 并不得不使用笨拙的选择器来导航 dom 好得多。没有必要完全禁止使用，但必须在正确的地方使用它们。
我在HTML和CSS的编码规范中也做了类似Harry所做的事情。
我喜欢拥有良好的代码风格指南并坚持执行的想法。多年来，JavaScript和其他编程语言一直如此，最终它也应用到了HTML和CSS中。太棒了。
顺便说一下，这是我博客文章的链接。
（我不知道如何编辑我的评论，抱歉。）
这是我的后续指南（受Harry和Hans的启发，我写下了自己的风格）：我的编码风格和指南。
CSS Wizardry的文章很糟糕，我甚至无法解释为什么你应该在网页中使用ID！只需不要在你的CSS中引用它们。完全忽略它们添加是一个非常糟糕的做法，因为它不允许开发人员轻松地与元素交互。
一般的经验法则是，你在唯一元素上使用ID，在可重用元素上使用类。比这更好的一步是为所有唯一元素分配ID，但使用类来设置它们的样式。（基本上，不要在ID元素上设置样式）
所以基本上，用你没有使用的ID来膨胀你的HTML？
似乎每个人都有不同的观点（我们都有权这样做），但我仍然不明白为什么人们讨厌ID。如果你在以后遇到它们覆盖某些内容的问题，你可能没有从正确的方向处理它？没有人可以在没有看到一些问题示例的情况下真正地说出来。
如前所述，ID有助于更快地渲染CSS，它们非常适合JavaScript（在选择元素时），因为它们比类选择更有效。它们应该只用于唯一元素（就像在HTML5之前一样，标题、页脚等的ID）。
你还提到了关于ID在唯一项目上，类在可重用项目上的“一般经验法则”，如果我错了，请打我，但我非常确定这就是它的用途（有效的HTML等等……）。
那还是我的观点;-)
一些提出的规则对我来说不起作用。
我将坚持WHTWG和W3C CSS WG的官方建议。
好吧，那很有趣。我花了很长时间仔细地撰写了一个有理有据的回复，试图提交它，却被粗鲁地告知需要填写姓名和电子邮件字段。如何在点击“提交”之前发出某种警告？然后，如何才能弥补我的错误，而不是让我点击“后退”按钮并重新输入所有内容？
抱歉，但我不会再浪费时间重新输入一遍，所以你错过了我的智慧之言。你的损失。
这里有一些很棒的技巧。利用这些方法可以使重新创建样式表更加高效。
这是我为我们公司创建的前端开发指南页面，因为我们的开发人员分布在多个地点，我们希望在所有项目中标准化最佳实践，以及就如何编写前端代码进行讨论。http://www.sessiondigital.com/frontend/
这场对话有点晚了，但我已经构建并维护了一个样式指南/模式库框架。
https://github.com/Anotheruiguy/toadstool
概念很简单，使用该框架构建自己的模式库，并利用预先设计的视图来快速开发样式指南。
请注意，它处于alpha阶段，并且本身也在快速发展。但如果你感兴趣，可以从中获得很多很棒的想法。
是否在CSS中使用ID选择器。
我认为我在ID选择器主题上看到的对话中缺少一个重点：代码重用。
根据定义，ID用于网页上唯一的一个元素；这与代码重用完全相反。
通过使用经过深思熟虑的类和可重用组件，您可以创建具有更小CSS代码库、更一致的外观、更易于维护和调试的站点，并且创建新页面变得更快。
在编程世界中，有一个名为DRY（不要重复自己）的概念。一个简单的例子是在电子商务网站上计算总计；你可能有很多页面或侧边栏显示它。它应该被抽象成一个所有这些地方都调用的通用函数来计算总计。因此，如果出现某些问题，例如税款计算方式的更改，您只需在一个地方进行更改，它就会应用于所有地方，并且最大程度地降低了遗漏一个或在一个地方出现错别字而未被注意到的风险。这种代码重用可以通过使用经过深思熟虑的类在CSS中实现；它使生活更轻松。
问题是，在CSS中使用ID的理由并不多。如果选择器强度是你的理由，那么你在CSS的其他地方存在更大的过于激进的选择器问题；这是一个权宜之计的使用案例。
ID在网页上确实有其用途，但它们的主要用途在于JavaScript。能够在一个类似资产列表中识别唯一资产。例如，您可能希望知道用户在显示放大版图像的灯箱之前点击了哪个缩略图图像。随着HTML5 data-something属性的出现，它们的用处正在逐渐消失，但它一直是个性化项目的宝贵工具。
所以我的两分钱是：如果你在CSS中使用#logo，你应该可以使用.logo代替。如果你不能，这是一个危险信号，表明你没有充分考虑CSS的其他部分。
你说它在这场对话中被遗漏了，然而主要话题之一一直是特异性（这意味着使对象过于具体以至于无法在其他地方使用，这与代码重用相同）。
我以前说过，我再说一遍，为什么使用.logo而不是#logo？你在CSS中没有节省任何空间，因为你仍然必须像使用ID一样精确地设置它的样式。如果徽标出现多次是可以理解的，但大多数情况下它不会。因此，代码重用在这些情况下不适用，因为你在编程中不会为只执行一次的事情编写函数（例如注销，它可能在网站上的多个位置，但它通常转到同一个地方，因此不需要函数）。
在没有必要的情况下（或认为ID因为特异性和代码重用而毫无意义，而这实际上并不适用）使用类而不是ID，已经说过CSS上的类不如ID高效，并且当使用JS选择元素时也是如此。
因此，简而言之：对于单一用例（例如大多数徽标、占位符等），使用ID不会有任何损失（不，甚至代码重用也没有），但你会获得轻微的性能提升（这可以累积起来！）。
这是自定义帖子类型吗？
此外，将BEM添加到列表中会很有用
http://bem.github.com/bem-method/pages/beginning/beginning.en.html
我不同意
我总是这样写
为什么？因为Chrome Web Inspector，如果我有px，我可以使用上下箭头键，但如果我只有0，它不会自动添加“px”，因此它不会移动元素。边距和填充也是如此。
这是一个很棒的想法和方法的集合！
很久以前，我认真思考过声明顺序（可能比“健康”考虑的更多）。我没有采用相当合理的字母顺序，而是提出了按层次结构顺序编写声明的想法。
描述位置、堆叠顺序和对象对其他对象影响的声明排在首位，然后是对象的尺寸、边框、填充和背景显示。从那里，我会编写任何处理对象内部内容的属性，例如字体系列或颜色。这使我能够从全局到特定的上下文中思考对象的行为。
它在纸上有效……有时。
根据Paul Irish在HTML5Rocks上关于浏览器工作原理的帖子，他提到CSS渲染是从右到左完成的。对于每个元素，每次CSS引擎遍历整个样式表以查找指定的元素，一旦找到该元素（通过id、类、标签或通用选择器），它就会移动到其左侧选择器并检查父元素，如果父元素正确，则继续前进，并应用样式。我写了一篇博客文章来解释整个过程。
所以这证明了如果没有嵌套级别，它将提高页面的性能，这在复杂的应用程序中可能很有帮助。例如，如果你查看Gmail的CSS，你会发现没有嵌套级别。每个类和id在整个应用程序中都是唯一的。即使它们是机器生成的（我不知道是怎么生成的）。
这使我们想到了GitHub和Google Code的关于特异性和命名约定的指南。Google建议
而GitHub鼓励**特异性**。这引发了一个问题，如何进行命名约定才能实现这两条指南？Smurf命名在这里是理想的方式吗？例如
.container-preview { ... }而不是像
.container .left-container .preview { ... }但是通过使用Smurf命名，它会生成有意义但非常长的名称，最终会变得很烦人。有没有其他方法可以克服这个问题？
PS 能否有人告诉我 Gmail 是如何生成那些 CSS 的？
我认为这个问题的解决方案很久以前就被 SASS 解决掉了。
如果你有一些人更喜欢用 x 格式工作，但最终希望通用格式为 y，你可以让 Sass 导入他们喜欢的任何格式，并让实际的生产样式表以各种方式格式化，例如压缩、单行，等等。
更好的是，如果这个人离开，它会立即将已有的内容转换为不同的格式。
这样，就可以遵守样式指南，而无需工作人员或任何人真正担心更改他们阅读或创建样式表的方式，这最终浪费了本可以用于处理真正重要事项的时间：以最大化用户目的的方式设计和执行网站。
我并不真正关心 ID 或类。在我看来，应该只有一种样式，并且所有内容都应该有自己的唯一名称。但这不是 W3C 的设置方式。现在他们创建了更多元素（header、nav、footer 等）。这些元素在页面上的权重与 html 和 body 完全相同。在我看来，这不好也不对。并非互联网上的每个页面都有 header 或 footer 甚至 nav。可以有独立的登陆页面。但是，互联网上的每个页面都有一个包含在 html 中的 body。
因此，页面上的所有其他内容都应该是一个“类”（不一定是指当前的 CSS 类定义），而只是一个声明的样式。并且页面上的所有内容都应该有自己的唯一样式名称，尽管可以在任何需要的地方重复使用它。现在，你可以有一个像 #nav .nav 这样的样式。你不应该能够这样做。
我认为 ID 或类并不会使事情变得更容易。它们只会让人更加困惑，并且像 header 和 footer 这样的东西会使它更加困惑。
W3C（以及人类总体上）使事情变得过于复杂。多年来，每个人都一直在简化页面，但随后这些奇怪的随机新元素不断被添加进来，使事情变得更加复杂。