- 在 一篇问答文章 中，我在Smashing Magazine上回答了一个关于如何查看CSS并确定其好坏的问题。
-
Harry Roberts 详细阐述了我的答案，并提供了更多关于CSS中不良内容的具体示例（例如，幻数、限定类、过于模糊的选择器）。Harry 在这篇文章中说
在 HTML 中使用 ID 用于片段标识符和 JS 钩子，但不要在 CSS 中使用。
- Jeffrey Zeldman 对此做出回应，并 为使用 ID 进行辩护。Jeffrey 将放弃 ID 与 OOCSS 和避免使用后代选择器进行了比较。
- 我们在 ShopTalk 上邀请了 Jeffrey 进行讨论。我们没有花太多时间争论，而是专注于一个更大的共识：对这些事情过于教条主义是最糟糕的态度。
- 完全巧合的是，下周我们将在 ShopTalk 上邀请 Harry Roberts。
现在轮到我再次发言了。我喜欢写博客。
我觉得如果有人被 Harry 的写作风格所排斥，无论是这篇还是其他文章，那可能是因为他有时给人一种教条主义的感觉。如果你不理解这个词的意思，就将其理解为不灵活的思维方式。事情就是这样，就是这样。拥有强烈的观点很棒，拥有不灵活的观点则不然。写下对你有效的方法很棒，写铁板一块的宣言则不然。
我见过 Harry。他是个好人。我不确定他在思维上有多教条主义（我认为不太多）。我们将在 ShopTalk 上讨论这个问题。
Jeffrey 称“永远不要使用 ID”的规定为“胡说八道”。
跟我一起说：当 ID 被适当地使用（语义化、结构化、谨慎）时，它并没有错。认为类总是优于后代选择器和语义化、结构化 ID 的观念则大错特错。
在我看来，这与 Harry 的教条主义一样接近。而我也有罪。我在我的文章 “沙中线，关于肉辣椒和使用类的故事” 中写到了这一点。
我不会使用 ID 来设置样式。不妥协。即使 ID 似乎可以在短期内帮助我，但永远不使用它们的长期益处更大。
完全避免使用 ID 让我获得了更好的 CSS 编写体验。我可能应该更侧重于这一点，但，好吧。
我觉得 Jeffrey 认为避免使用 ID 意味着过度使用类来修饰其他所有内容，放弃级联，以及不使用鼓励编写干净标记的智能选择器。我认为 ID 与这些事情无关。过度使用类很愚蠢，不要这样做，也不要认为这就是 OOCSS 的含义（我认为它更像是：找到一个模式，给该模式一个类）。级联仍然有用，但范围有限。你可以争辩说它带来的伤害和好处一样多。最后，我非常喜欢后代选择器。它们与类和 ID 的效果一样好。我认为更好，因为类是可以重复使用的。
我还觉得 Jeffrey 对此有比 Harry 或我更深刻的理解。正如我们在 ShopTalk 节目中讨论的那样，Jeffrey 经历了一些标记极其糟糕的时代，并帮助开启了一个我们今天习惯看到的干净标记时代。如果他觉得事情朝着另一个方向发展，我会理解他的担忧。
我经常遇到创建单页网站的情况，这些网站的使用寿命很短。OOCSS 对某些事情来说很棒，但对于小型项目，如果需要快速完成，有时它就显得过于复杂了。
我知道使用最佳实践很重要，但有时你只需要依靠那些能够应急的方法。
尽管我在评论中写了两遍，但我还是要说一遍。我的意思是，有时。ID 不需要一直被禁止。
但为什么要使用 ID 呢？一个只使用一次的类可以达到同样的目的，除了在项目扩展时你不会遇到麻烦。即使项目从未扩展，使用类也不会花费你更多的时间或精力，对吧？
@Scott，我很久没用过 ID 了，但我同意 Zeldman 的观点，即在某个实践仍然有效时，对其进行过度批判是错误的。在过去的两年里，我制作的所有网站都采用了响应式设计，但我并不介意其他人制作固定宽度的网站。
表格布局仍然有效……
也许你可以为自己创建一个样式指南，用来创建网站；类似于 Bootstrap，但没有那么完整，因为你不想花费所有时间重写大量的样式。
http://larrybotha.github.com/styleguide/
在开始一个项目时删除不需要的内容，测试所有内容的外观后再进行实现，然后像拼图一样将你的网站拼凑起来。一旦大多数元素已经布局好，网站的构建速度之快令人惊讶。
Wesley，
我不确定我是否同意你的观点。OOCSS 对我来说同样快，实际上可能更快。总的来说，以这种方式编写 CSS 是一种良好的习惯。继承是你的朋友！即使在小型项目中，使用 ID 对事物进行范围限定也会变得杂乱，尤其是在你倾向于重用代码时。对我来说，ID 范围限定在企业级网站上实际上更为重要，因为在你的代码下存在未知的 CSS 类，并且你不想让它们发生冲突。（这仍然可以通过 OOCSS 来避免，但有时你必须在命名约定方面更加巧妙）因此，在我看来，两者都有其适用的场景。
对我来说，这很简单，就是过度优化，为了将来“可能”再次使用该样式而不用 ID 是错误的。
虽然 ID 是唯一的，并且可以使用，但一旦你开始重复使用，你就需要考虑优化并改用 CLASS，但仅限于相关的方面。
所以，如果你编写所有内容都符合 OOCSS 的理念，以便将来可以在任何地方使用它，那么当然，CLASS 是正确的方法。
只是不要养成过早优化的习惯。
“过早优化。”在我看来，这听起来像是懒惰的开发。
“永远像维护你代码的人是一个知道你住在哪里的暴力精神病患者一样编写代码。”——John Woods
我们不仅仅是“将来可能再次使用该样式”，而是我们在设计中发现了模式，并选择使用可以应用于唯一实例并进行扩展的类，而不是对 10 个不同的选择器重复相同的 4 个声明。
自从 Harry 几天前发布了他的文章以来，我一直关注着这件事的发展。我非常尊重 Jeffrey，但他似乎认为使用 ID 而不是类更“语义化”。然而，事实并非如此，因为浏览器无法从 ID 的内容中获取任何信息。
Harry 有时可能会显得教条主义，但他的理由总是非常充分的。CSS 架构在过去几年里发生了翻天覆地的变化，所以我们需要有人站出来说“这就是应该做的事情，并且有证据支持它”。我觉得 CSS 正在逐渐减少对设计师的依赖，而更多地落入那些完全理解 OOCSS 等概念的人手中。
我非常有兴趣听 Harry 在 ShopTalk 节目中的发言。
我快速地插一句
谢谢，这对我来说意义重大 :)
我认为我对自己的想法非常自信；我将所有工作时间都花在了扩展 CSS 上，为大型团队编写 CSS，这些团队负责开发需要数月（甚至数年）才能完成的网站。我对自己的想法很有信心，我真的很后悔这让人觉得我像个教条主义者。
我亲身经历过 ID 在最不可能的情况下让我陷入困境的教训，松散和复杂的选择器导致了需要花费半天时间进行重构的工作，而这些工作本来只需要几秒钟就能完成。
亲身经历并规避这些问题是我（过度？）渴望分享的事情，因为只有当你意识到自己在给自己制造麻烦时，你才会意识到事情可以变得多么简单。
我想我在一个需要严格执行规则的环境中工作，因为我见过如果没有规则，事情会变得多么糟糕。如果我在日常工作中没有那么直率和自信，我真的很难胜任。
非常期待明天在 ShopTalk 上聊天。
干杯，
H
学习正确使用工具/技巧的绝佳方法是始终如一地使用它。一直用到它让你感到痛苦为止。这是我父亲教我驾驶赛车时使用的一种技巧。他会让我在转弯时开得越来越快，直到我甩尾。这让我了解了应该以多快的速度行驶，也教会了我其中的后果。
我认为Zeldman抓住了要点，“为侧边栏中的每个段落元素添加一个类名不仅是不必要的带宽浪费，而且也是一种不好的形式。”话虽如此——如果你从未查看过输出的HTML呢？在这种情况下，它真的有区别吗？
带宽问题无关紧要。我的意思是，每个人都在使用gzip（对吧？），所以添加10个相同的字符串几乎没有区别。（见鬼，如果带宽是一个问题，为什么Zeldman会鼓励使用“语义”ID名称？它们都应该只有2个字符长。）
实际的潜在问题仅仅是通过添加更多代码，使你的代码更丑陋，并且可能以后更难以阅读和调试。不过，在我看来，这是一个相当次要的问题。
相关的Twitter帖子
这正是存在的困惑。最终，这不是一个使用ID还是不使用ID的争论。它们共存于同一个生态系统中，并服务于不同的目的。对于小型到大型项目，我倾向于使用OOCSS，因为它非常适合养成习惯和代码重用。另一方面，当处理大型网站时，你没有参与过或存在底层代码，那么你的心爱的“.text”类很可能已经被用于其他用途。话虽如此，当你想要专门使用CSS来避免共享并使其自包含时，ID会派上用场。
我认为，只要你以某种方式编写代码是有原因的，而不是仅仅因为你盲目地遵循某个人，或者因为你从某个地方复制粘贴代码而不理解它，那么这样做就可以了。
OOCSS和SMACSS方法是极好的指南，但有时你必须打破规则才能解决项目中的特定问题。
也不理解对ID的恐惧。是的，在JS方面——对多个项目使用相同的ID是不安全的，但这并不意味着你一定不能使用它们。过度使用类名确实很蠢。
我同样也不理解对“表格”的恐惧:) 也非常愚蠢。
题外话——你们是怎么设置头像的？我需要在小屋里注册吗？
访问Gravatar.com。
使用ID构建大型网站是你所能给自己带来的最糟糕的体验。我经历过，而Harry Roberts的工作重点就在这里。
不使用ID是因为CSS中的ID会带来噩梦。
不确定你在限定你的陈述，但再次强调，试图编写无需使用模块化方法即可扩展的灵活样式，将会变成一场噩梦。
你怎么定义“过度使用类”？3个类？5个类？10个类？是否对可以应用于元素的类数有一个神奇的数字，或者你的推理更深层次，即类数可能取决于具体情况、特定类型元素出现的次数以及你可以使块的默认状态模块化的程度？
这再次是一个来自构建大型网站经验的问题。
John Lueders – 谢谢:) 有效
Larry Botha – 大型网站 – 是的。而且，有时确实需要为JS设置ID。如果可以简单地使用它的ID，为什么要声明一个新类呢。关键是你不应该限制自己。这并不意味着——你应该在任何地方都使用ID :)
你好，Chris，我非常同意你关于网页设计行业中教条主义的总体观点。我认为它并不局限于如何做CSS——我们在很多地方都能看到它，尤其是在移动和响应式网页设计方面。我想知道你是否读过这篇文章：CSS架构 作者：Philip Walton？据我了解，他建议减少级联的使用，尝试使用更具体的类，并避免复杂和通用的选择器。他文章中的这段CSS说明了他想表达的意思
致礼，Mark
我认为，这些做法并非关于减少级联的使用，而是关于更好地理解它的运作方式。
我完全同意文章的这部分内容，有些人从中得出结论，他们需要为每个元素添加类（例如，为所有
<p>标签添加一个类），但在我看来，这不是重点。它是关于将样式与标记分离，理想情况下，我们希望创建一个样式表，在进行标记更改时无需修改，例如决定使用一组div进行导航而不是列表项。这可能不会发生，但我最近遇到的一个问题是为手风琴创建灵活的样式解决方案，该解决方案可以放置在代码中的任何位置并正常工作，起初我的标记看起来像这样显然，使用像
.accordion h1、.accordion h1 + p这样的选择器很容易设置样式，但它不够灵活……如果我们决定在整个标记中使用h1-h6而不是到处使用h1，不同的手风琴可以有不同的标题标签，如果<p>并不总是适合我们想要在每个部分中显示的内容……简单地向<h1>和<p>添加一个类名就可以轻松解决这些问题。但这只是一个可能非常庞大的网站的一小部分，我在与Magento的默认样式表和过于具体的规则作斗争时遇到了同样多的问题（以前的开发人员在主题化时只是覆盖了Magento的样式表，而不是创建新的样式表），不得不尝试覆盖像
ul#main-navigation li.item a.navigation-link.current-item.over这样的规则，这与遇到一个顽固的ID一样令人讨厌，这就是为什么我更倾向于Harry的单一类名方法，至少我知道我和团队中的其他人不会遇到我曾经遇到的同样的挫折！FWIW，我觉得很多“代码异味”的讨论过于泛化。5年前谈论同样的事情（或者2年前问Harry），答案会有很大不同。即使今天阅读Harry的观点，几乎所有观点都有重要的例外，或者反映了他此时此刻采用的特定架构方法。这并不是说这些讨论没有价值。
我认为这实际上是在重申一致的架构、原则集以及努力保持整个结构自一致的重要性。你可以在一个上下文中存在“代码异味”，但这并不一定意味着它们是始终适用的普遍原则。在其他上下文中，可以做出不同的决定，并且你可以理解聪明的人为什么做出这些决定。否则，就会有一种从教条立场转向教条立场的倾向——（轶事地）在这种领域并不罕见。
一旦采取了强硬立场，就并不总是容易摆脱它，尤其是在你投入了大量时间和精力的情况下。Zeldman，值得称赞的是，他准备根据他文章评论中的一些有理有据的观点调整他众所周知的立场。
但许多开发人员发现，“分离关注点”的努力也导致了它们之间不同类型的紧耦合，这在导致维护问题的上下文中表现得最为明显。人们为放松这种耦合所做的努力并没有威胁到Zeldman过去的努力，它们建立在他过去的努力之上，并从对HTML级别语义的过于严格（在今天的环境下）的理解中继续前进，这种理解将CSS钩子（如类名）绑定到文档和内容级别的语义。同样，你可以预期我们在未来几年将采用不同的策略，并可能试图避免许多今天可能被认为是“好的”方法，尤其是在Web技术栈持续发展的情况下。
Nicolas，我完全同意大多数这些讨论主要是在上下文中进行的，并且与当今Web技术栈产生的问题相关。
我在Mark Dixon链接的文章中给出的大多数建议都源于这样一个事实，即在当今的网络中，完全封装CSS组件非常困难（如果不是不可能的话）。
但在（大概率）不久的将来，许多这些问题可能会通过Web Components得到缓解，Web Components确实允许完全封装CSS和HTML。
坦白说，这是一个奇怪的讨论。如果你无法处理ID，你也无法处理类。就这么简单。
是的，ID具有更高的特异性，并且在一页中只能使用一次。这并没有像有些人认为的那样有那么大的区别。
简而言之：“不要”使用ID是一个愚蠢的建议。我相信这种方法的支持者也多次被类所困扰，但选择忽略这一点。
我倾向于同意。整个争论和讨论都很愚蠢。当有人开始滔滔不绝地谈论是否使用ID以及什么使生活更轻松时，我就会立刻关掉。这完全是主观的猜测。
我认为只要在组织和构建CSS方面做出一些努力，这两种方法都可以。没有人喜欢花头几个小时来尝试阅读和理解别人的（或自己的）样式表。
在处理样式表时，我尝试将其组织成类似这样的节奏
让类/ID遵循一致的命名约定
确保这些名称对人类来说是可读的
在样式表中添加注释来解释它指的是什么，一个hack等等
顶部的内容目录也是一个不错的选择
我相信我们应该使用任何适合我们设计的东西，来吧，我们是设计师，我们是解决问题的人，代码应该以这种方式为我们服务，如果需要ID，完全可以这样做，如果你可以用仅仅使用类来实现，那也很好。
只要我们能保持代码干净、有效，并且它能满足我们的需求或解决我们的问题，那就太好了！如果不行，就用其他方法解决。
我认为这就像预处理器那样的讨论，我们应该使用适合我们并对我们有效的那个！
我赞赏“只解决问题”和“任何对你有用的方法”的态度，但要对此有高度的自我意识。这次对话表明，你可能持有“ID完全没问题”的态度，即使它（可能）会让你陷入困境。
Rodrigo，为了把你说的话放在上下文中……假设你房子的支撑梁正在垮塌，你有24小时的时间来实施解决方案。你决定使用10卷胶带并将它们缠绕在所有梁上。解决方案有效吗？是的。这是最好的方法吗？大多数人可能会认为不是。仅仅因为一个解决方案有效并不总是意味着它是最佳实践或正确的方法。
我觉得教条主义经常出现在巨大的变化和过渡时期，在这些时期，我们都希望感觉自己正在以“正确的方式”做事。当我们适应一个系统时，使用OOCSS就是一个例子，我们倾向于宣扬自己的立场。如果我们愿意接受比我们现在做的事情更好的方法的想法，那么这种不确定性会使我们所做的事情充满挑战。在大型团队/系统中，这种现象被极大地放大，在这些系统中，采取经过计算的方法至关重要。
让10位摇滚明星开发人员设计同一个网站，你将得到10种不同的CSS解决方案——所有这些解决方案都有效。基础知识和顶级指南之间存在差异。
我喜欢Harry的文章，也喜欢Zeldman所说的话。两者都是正确的。这更多地关乎上下文而不是策略。
这些讨论对我们所有人都有帮助，有助于我们更好地完成工作。问题在于有些人以“精英主义”的方式行事，好像他们的方法是唯一的。
继续吧。构建酷炫的东西！
你的“10位摇滚明星开发人员”理论引起了我的兴趣……最初它们可能看起来都一样，并且功能也一样。我认为OOCSS要解决的问题是代码的可持续性。如果这10位摇滚明星开发人员继续在同一个网站上工作，我们会看到一些使用不太理想的代码结构的开发人员开始难以维护和更新吗？如果你将代码交给另一位开发人员会怎样？他们能多容易地接手并继续工作？
我想，在讨论代码理论时，最大的问题是：让尽可能多的人以相同的方式工作，这对整个Web开发社区是否有价值？
Andrew，我同意你所说的所有内容，尤其是在拥有创建连续性的系统时。话虽如此，我认为尝试为所有项目、公司和环境确定一个单一的系统就像在射击一个移动的目标。此外，我认为CSS ID争论只是“教条”发挥作用的一个例子。我们可以讨论响应式网页设计与固定宽度与单独的移动网站，或其他类似的争论。我非常支持响应式设计，但意识到这并不一定是对所有项目的正确解决方案，我不会因为有人选择其他路径而谴责他们。
换句话说，Harry的文章完全有道理，我们都应该注意并朝着这个方向发展我们的工作，但我们也必须意识到存在例外情况，以及CSS本身也是在不断发展的事实。
仅仅因为开发人员没有完全遵循Harry的指南并不意味着他/她不是一位摇滚明星开发人员，就像遵循指南的人也不一定就是摇滚明星一样。
教条主义成为问题的地方在于，社区中的一些人会因为某人的工作没有以特定方式完成而对其进行不公平的批评，这种批评是基于教条主义本身的原则，而不是基于实际的工作或结果。
我喜欢这些帖子。我们工作在一个令人难以置信的行业。
关于ID作为类选择器的具体问题，我坚定地（现在，并非总是）站在“绝不”的阵营。我参与过太多大型项目，也与太多大型团队合作过，其中使用ID作为选择器造成了特异性方面的噩梦，需要对CSS进行几乎完全重构才能修复一个实际上非常小的问题。在我现在的实践中，CSS只挂接到类（和语义结构化的HTML元素），而ID仅作为jQuery挂钩存在。事实上，有时我会为CSS和jQuery分别给一个元素相同的类和ID。这是最有效的方法吗？也许不是。在团队环境中的大型项目中，它是最易于管理的吗？我的经验告诉我，是的。（你的里程可能会有所不同。）
关于教条主义和CSS的更大问题，我认为在团队环境和大型项目中，你需要一定程度的教条主义（我相信这曾经被称为编码风格指南？）以便每个人都保持一致。如果你不想遇到其他人的工作，处理特异性和其他问题，以及总体上处理更多麻烦而不是将项目交付出去，那么就需要制定某些规则并由每个人遵守。
仅供参考，我同意Harry帖子中99.999%的内容。他的建议代表了良好的CSS实践，我已经在一段时间的工作中尝试遵循这些建议了。我不想说我对它教条主义，但是……:-)
Harry（优秀）的文章中没有任何内容让我觉得是教条主义的。我认为你将教条主义与确定性混淆了。
Harry的建议是确定的，因为它缺乏限定或“缓和”的条件。这使得它自信而清晰，而不是胆怯而含糊。
教条主义与确定性或强烈的信念无关。教条主义拒绝改变或劝说。即使面对令人信服的证据或论点，教条主义者也不会改变自己的信念。
（教条主要指根深蒂固的宗教信仰，这些信仰被认为是不可能——或异端的——修改的。）
你可以用“视情况而定”来回答几乎任何问题；但这是一个无用的答案。当你能够的时候，最好是明确。
这种极端的非黑即白的观点实际上是我对一些最近的最佳实践（特别是ID的使用）感到反感的原因之一。
现在，在此之前，我完全理解他们的出发点，我甚至同意——你应该努力确保你的CSS是可重用的，但我用不同的方法做到这一点：我使用预处理器和mixin/类似的东西（我不认为我需要详细说明我如何使用它！）
我的问题是：我的网站上有一个元素，让我们以一个目标关联区域为例（不使用header/footer作为示例，因为我越来越多地开始为它们使用[role=blah]）。由于与CSS无关的原因，我在该元素上有一个ID，而对我来说，使用该ID更有意义，因为它已经存在，而不是向该元素添加一个或多个类。我想这感觉像是浪费了一个完美的标识符=)
也就是说，如果我需要在没有Sass/Less/Stylus的情况下用纯CSS编写它……我可能会抱怨，但会在上面添加“rounded-corners”类，因为一遍又一遍地重复一组样式很烦人！
当试图创建更易于维护、可扩展的CSS时，这种思维方式是问题的一部分。
通过重用此ID来提高“效率”会导致你的CSS与你的JavaScript或代码的其他方面耦合（取决于你使用ID的目的）。它还会使这些CSS样式比其他CSS样式更具体，这在尝试扩展/覆盖样式时可能是一个问题。当然，这意味着样式不可重用。
编写可维护的代码并不一定意味着使用尽可能少的代码。通常，有条理地进行更好。
CSS预处理器可以帮助编写更易于维护的代码，但它们只是良好解决方案的一部分。预处理器不能替代良好的CSS结构。
但这就是我在谈到预处理器时的重点——它是可重用的。
你其他的观点我发现很有趣，需要仔细思考一下，因为这些都是很好的理由。可能说服我，也可能不会，但至少比那些过于具体/可复用的论点要接近得多。谢谢 =)
哦，是的，你关于预处理器允许重用样式（即使挂钩到ID上）的观点是完全正确的。
这里有一个细微的差别：输出的CSS代码会重复你的样式。这对维护来说不是问题，但它会通过增大样式表的大小来影响性能。话虽如此，Gzip应该可以压缩大部分内容，所以这可能不是什么大问题。
实际上，它不会重复自身，如果使用扩展的话。诚然，人们仍然可能遇到特异性问题，并最终导致某些内容在文件顶部被写入，而你希望它覆盖文件下方的内容。
（我现在争论的重点已经不是为什么应该使用ID，而是更多地关于预处理，但我非常享受这次讨论）
不过，你对使用，比如 [role=main] 这种方式有什么想法——你是否仍然认为使用它会是一个问题，因此应该使用类而不是ID呢？
“过早优化”听起来很糟糕……治疗方法是什么？常见……常见……哦，是的，常识！我当然是在开玩笑，但在我看来，我们正处于一个变革时期，我们正在发明一些几乎没有益处的新技术（OOCSS尽管声称可以提高速度，但毕竟是CSS，LESS（编译后的形式）也是）。
要了解一篇关于OOCSS的好文章（基本上说明你可以使用ID，而且OOCSS不适用于小型项目），请查看Smashing Magazine的文章。
“面向对象CSS (OOCSS) 入门”
http://goo.gl/Phq53
@EdPoole 语义不仅仅局限于浏览器，它们对搜索引擎和开发者也有意义。我想说，正确使用ID带来的语义增益微乎其微，但语义并不局限于浏览器。
“这就是应该做的事情，并且有证据支持它”。无论某人认为自己多么正确，这正是问题所在。这就是教条主义。社区中没有人有权说事情应该如何完成。没有人有权将观点作为事实呈现。
我们在这里讨论的是最佳实践。根据其定义，它们是观点。OOCSS绝对不是在任何情况下构建CSS的唯一有效方法。这使得它成为一种观点，一种辩论，具有多种观点。而不是事实。
我觉得整个“不要使用ID”的运动在一定程度上损害了可访问性，因为我看到人们不再使用跳过菜单了。我们确实在使用ARIA，但它在旧版屏幕阅读器中的降级效果并不好。人们经常忽略的一点是，JAWS（最流行的屏幕阅读器）与IE配合使用效果最佳，并且升级非常昂贵，这导致许多人使用旧版本，而旧版本无法与新的HTML功能配合使用。
就我个人而言，我将ID用于主要的布局组件（标题、导航、内容、页脚等）、JavaScript（DOM访问）、跳过菜单和表单元素（显然）。但我也不是在其他情况下回避它们。
另外，新的页脚看起来你好像在偷偷地盯着商品女孩……我表示赞同。
这是一个很好的例子，说明教条主义有多可怕。如果你因为样式决策而没有包含跳过菜单，那么你做错了。即使我支持“不要使用ID进行样式设置”一方的观点，用于样式设置这一点也不能被遗忘。请继续将ID用于ID的其他用途。
是否有任何好的资源可以推荐，用于CSS样式和结构，同时也能实现不使用ID的功能？我喜欢这个想法，并且一直在寻找改进我的实践和习惯的方法，只是在寻找一些方向和关于这个主题的好的文章。
我认为这场讨论源于一些人认为有些人提倡“永远不要使用ID！”，而不是“不要使用ID进行样式设置”。第一个说法听起来非常教条，但如果更细致入微一些（在第二个说法中），它听起来就不那么教条了。
但是，虽然Chris的文章更像是“嗯，这只是我选择编写代码的方式”的感觉，但Harry的文章可能显得更“咄咄逼人”？有点像“如果你使用ID，你就做错了”，我几乎感觉受到了攻击。因此，Zeldman的文章为他辩护了ID的使用，反过来几乎感觉像是在为我辩护。
这可能听起来有点夸张，但我的意思是，这三篇文章的语气与公众如何接收实际信息有很大关系。
顺便说一句，我过去在你的CSS样式指南文章中评论过这一点。
我对这个问题的看法是，当你在非常大型的项目上工作时，工具箱中的每一个工具都很有价值。因为迟早，工具箱中的任何工具都可能成为适合该工作的正确工具。
也许只是我，但我真的不明白为什么使用ID进行样式设置从长远来看会导致如此多的麻烦。当然，类更易于重用，并且可能比ID更好，但如果在现有项目中难以更改，那么可能是代码本身写得不好。话虽如此，在阅读了这里的一些评论后，我可能会比现在更少地使用ID，但我希望听到一些真实的例子，说明使用ID如何在大型项目中破坏了任何人（或任何团队）的生产时间。
我认为认为必须是一个非常大的项目才会影响结果的想法是错误的。对我来说，这就像说
“我不会在Photoshop中使用热键，因为这只是一个快速项目。”
时间就是金钱。提高效率。永远。
我们遇到过一个问题（中等规模的网站），QA向一个元素添加了一个ID以便他们可以编写Selenium测试。碰巧他使用的单词被用作网站其他部分的ID——当时我们正在为ID设置样式。我们转向仅使用类进行样式设置的一个主要原因是，类仅用于CSS，而我们的ID用于多种用途，因此仅为类设置样式会更安全。
我认为最重要的是，你决定如何使用ID和类，并确保每个参与代码开发的人员都了解规则。
这是一个很好的例子，谢谢，所以我想我已经完全信服了，除了“它已经存在！”的情况，而对于这种情况我还没有做出决定。
请注意
那。如此之多。想象一下，如果ID不仅仅用于样式设置，还作为JavaScript挂钩用于其他用途？真是太糟糕了。
欢迎在这个男性主导的行业中发表评论的女性们。
我已经从事专业网页设计大约18个月了；我有点害怕发表评论（尤其是我不了解“面向对象”代码的所有含义）。
也就是说，我很惊讶没有人提出这一点
除了大型网站与小型网站的考虑之外，我在评论中看到的是动态设计人员与静态设计人员之间的分歧……
我还没有完全掌握脚本编写。自定义Modernizr是我所能达到的最动态的程度。因此，ID对我来说没有问题。
我理解代码风格、可扩展性和注释，但由于从未在团队中工作过，所以我经常通过“查看源代码”来学习，而源代码实际上应该被最小化（例如，删除注释）。
在我的个人网站上，每个页面都包含一个徽标/品牌（在菜单[左上角]中具有“brand”的ID），因为这是一个需要保持一致并且每个页面只使用一次的元素，因此赋予它一个ID似乎很合适（并且简洁/语义化）。
此外——也许最近发生了变化——在MDN关于编写高效CSS的文章和其他文章（尤其是在移动环境中）中，他们详细介绍了后代选择器和一些CSS3样式的“昂贵”程度。
这大部分是基于我从Paul Irish和Steve Souders那里读到的内容，我只是相信他们的说法……
当然，我可以使用伪类：last-of-type，但由于知道它有多昂贵，我倾向于手动向最后一个元素添加“last”类（等等）。但是，如前所述，我倾向于处理更小、更静态的网站。
我当前的网站是基于Twitter Bootstrap构建的，但我觉得它为许多元素“添加了过多的类”，为了使其更适合移动设备，我用近似的CSS 2.1属性替换了一些CSS3属性，简化了类，添加了ID，删除了未使用的CSS规则，并对其进行了修改以包含新的语义HTML5元素（即“nav”）。
关于Tim的评论，我还为跳过链接等添加了ID（然后向它们添加了样式属性，因为它们已经存在）。我不是什么天才，但我确实认为这是我们的责任——如果我们能够做到——让我们的内容尽可能多地提供给更多的人……
[g@!-%&?n IE用户除外——这就是他们使用忽略标准的浏览器应得的报应！]
说实话，我真的很想了解更多关于脚本编写、可访问性、最佳实践等内容……请向我解释，或提供一些资源链接，或者点击链接访问我的域名，给我发送电子邮件或提供工作机会：-D 并教我更好的方法。
作为一个编码了15年（尽管仅专业从事一年）的人，也许我应该欢迎你！=)
请问您是如何看待动态/静态页面之间的差异的？我认为，除了使用在代码中大量散布钩子的CMS之外（是的，WordPress，我喜欢用你，但我在看着你！），前面所说的任何内容在动态页面和静态页面上都不会有什么不同。
我的想法是，你不应该轻易相信任何人的话。这并不意味着你应该质疑他们说的每个字，而是要看看他们是如何支持自己的观点的，以便你能对他们为什么要这么说有一个验证。
你也应该不要害怕问为什么，只要是在主题范围内。我认为，网络的一个优势在于，大多数事情都可以——也应该——被质疑，尽管显然不应该争论客观上不正确的事情（不，#000不是白色！）。
嗨，玛丽，大家好，
从我在MDN文章中读到的内容，以及Google PageSpeed的内容（包括Irish和Souders）等关于CSS如何解析的信息来看，它是从右到左读取的，因此，由于后代选择器必须尝试匹配每个节点（？……我认为这是术语），所以它很耗时……我记得的词语是“极其昂贵”。
然后是可怕的“重绘”。
如果我仅使用类来防止以后出现特异性问题，那么我的CSS是否会散布（很棒的词……也是一个典型的例子）仅包含类的后代选择器，然后在我动态更改这些类时出现潜在的重绘问题（DOM中的位置和更改的属性将是影响因素）？
我的直觉（我在Stack Exchange上问过，但没有得到答案）是，一个没有添加类、创建和插入元素等的静态页面（分析在此方面不受影响），本质上会比一个不仅必须解析DOM和CSS，而且还必须解析脚本的页面更快。我错了吗？……在合理的范围内*，差异是否大到足以产生显著影响？
*对我来说包括移动设备。
当你只需要某个东西一次时，你使用id。如果由于你的疏忽，将来需要在其他地方再次调用它，则将其替换为class。例如，当你有一个class来表示按钮，但需要在一个特定按钮上增加更多特异性，比如需要在它的左角使用不同的border-radius时，你给它相同的class，并另外添加一个id，并覆盖该border-radius。
这样做有什么问题吗？
绝对的教条主义？真相
不要使用class来为同一属性上的相同事物设置样式，这些属性已经使用ID规则设置了样式……因为：它不会起作用……或者使用256或257个……
……
ID是强大而有个性的；class是优雅的，并且与其他人更好地协同工作。
恕我直言，这场讨论：不太重要……
我的油画老师曾经告诉我们：“作为艺术老师，我们的工作是教你规则，作为艺术学生，你的工作是告诉我们我们错了。但为了打破规则，你需要先了解它们。”
我不认为像克里斯的“底线”或哈里的“教条”之类的规则有什么特别之处，它们仅仅是规则而已。除非你首先了解它们，否则你不应该打破规则。一旦你了解了它们，并且了解了它们为什么是它们，你就可以打破它们。因为只有这样，你才会带着真正的意图去做。
学习网络相关知识，我既爱又恨的一点是，总有新的东西要学。在我之前的评论中，我感觉自己对CSS已经有了相当好的掌握，并且在没有阅读顶部链接的文章，甚至没有注意到关于在HTML中使用ID而不是CSS的小片段的情况下发表了评论。
我读了Zeldman的文章，更重要的是后面的评论，它们真正阐明了一些事情，所以我现在加入了无ID CSS的行列（前提是对于我真正期望始终唯一的并且需要HTML中ID的东西，我可能会为它设置样式而不是添加额外的class）。非常棒，有见地的讨论，我从你们所有人那里学到了很多东西，谢谢。
我在某个地方读到并完全相信CSS不是编程语言。ID是编程的产物。列表、Div、Span都需要由语言进行操作。我发现我的ID更多地用于组织菜单、手风琴等。对我来说，class是保持格式和视觉提示的好方法。将它们组合和混合起来非常容易。说不应该使用ID或者太多的class不是最佳的，实际上是在关注代码是谁写的。我将坚持认为CSS是视觉格式化，而不是页面编程。使用JQuery或JavaScript添加功能，并将CSS留给美观。
我曾遇到过ID与class让我陷入困境的情况，直到我学会了如何组织和模板化我的CSS，利用JQuery的class并保持脚本在脚本中。
ID是为了在网页上进行功能性编程而创建和使用的，而不是用于CSS格式化。让CSS保持其基于class的基本格式。