Their argument is mentioned by lonesomeday in their answer, that it tightly couples it to the HTML and doesn't allow for reuse.
I could make an argument, that there are cases where you don't want a style to be used by anything other than a single element, so specifying it on an id selector would make sense.
It's all going to come down to personal preference. This isn't some hard and fast rule that you have to adhere to, it appears to be the thinking of the CSS Lint team, not a rule that causes errors or anything.
当您管理大量 CSS 或大型网站时，就会出现一个大问题。根据定义，ID 不可重复使用。但你也会遇到具体的问题。当你开始改变特异性时，你就会陷入令人讨厌的风格竞争条件。 ID 比类具有更多的特异性，但内联样式比 ID 具有更多的特异性。内联样式比外部样式表更具特异性。通过使用类，您可以标准化样式应用于元素的方式，从而使事情变得更加可预测。这往往会简化开发，尤其是在与多人合作时。
A big issue comes in when you are managing a lot of CSS or large websites. IDs by definition are not reusable. But you also get into issues with specificity. You get into nasty race conditions with styles when you start changing specificity. IDs have more specificity then classes, but inline styles have more than IDs. Inline styles have more specificity than external style sheets. By using classes you standardize how styles are applied to your elements making things more predictable. This tends to ease development, especially when working with multiple people.
COMPONENTS: if you write reusable component e.g. table with id (e.g. <div id="data">) then if you put two tables into one document then you will get INVALID html.
基本上，如果您构建如果你的代码使用类而不是 ID，你的代码可以更加通用和可重用，这通常是一件好事。此外，特异性是一件很难让您理解的事情，并且可能会导致难以发现的错误，因此如果您省略 ID 选择器，则不太可能以意想不到的方式解决冲突的规则。
CSSLint gives a guide to why they make their recommendations:
IDs shouldn't be used in selectors because these rules are too tightly coupled with the HTML and have no possibility of reuse. It's much preferred to use classes in selectors and then apply a class to an element in the page. Additionally, IDs impact your specificity and can lead to specificity wars.
Basically, if you structure your code to use classes rather than IDs, your code can be more general and reusable, which is generally a good thing. Furthermore, specificity is a hard thing to get your head around, and can cause bugs that are hard to find, so if you omit ID selectors, you're less likely to have conflicting rules resolved in unexpected ways.
And because I know that structure is consistent, I don't mind using #page, #header, #nav, #wrapper, #content, #sidebar, and #footer in my css for sweeping region-specific styles. These styles are tightly coupled to this particular structure, which makes them less reusable; because I reuse the structure, they are reusable. The important thing to remember is that using an ID in a selector is very specific, and should be used sparingly.
Generally speaking, one should use the lowest possible specificity selector that makes the correct selection:
If you're targeting all <a> elements, then it makes sense to use a. If you're targeting all <a> elements within <div class="foo">, then it makes sense to use .foo a. If you're targeting all <a> elements within <div id="bar">, then it makes sense to use #bar a. However, you could use a lower specificity selector. [id="bar"] a has the same specificity as .foo a, which means that you can still target specific elements by ID without creating selectors with unnecessarily high specificity.
I do not generally recommend using [id="XXXX"] selectors for selecting on the [id] attribute, because it's verbose and may cause confusion. I do recommend using [data-id="XXXX"] selectors for selecting based on custom [data-*] attributes to more closely relate styles to the current state of DOM nodes.
ID 无疑是不好的想法，在我看来，只是当你在与团队打交道时的 CSS fu 一开始就不是那么好时，你才能得出这样的想法。
在我看来，良好、灵活的 CSS 遵循以下通用最佳实践：
始终从通用转向具体。例如，一般正文文本的字体系列和最常见的字体大小只能在一个地方声明。当您升级到更通常涉及类的使用的选择器时，您将开始覆盖字体大小。当需要将大多数未使用的字体系列应用于非常特定的 HTML 子集时，就需要在容器上使用 ID 来命中获取正文文本变体的元素。
属性应用得越广泛，就越容易覆盖，并且您不必担心会意外覆盖最常用的属性。例如，body#some_id div 就是一个非常糟糕的选择器。在第二层（有 3 个...左右），您通常更多地处理与分类容器相关的常用重用元素束，因此意外覆盖这些属性应该会更困难一些。在我看来，当你到处都有成堆的多类选择器时，“意外”发生的频率会更高。在最后一层，您应该处理的不是可重用元素，而是覆盖文档中高度特定的部分。在这些情况下使用 ID 是一种理想的做法，并非坏事，但最好谨慎使用 ID，并且仅用于 ID 实际需要更改的项目容器中元素的特定属性。
选择器越具体，就越难意外破坏它。我所说的“具体”并不仅仅指元素上的 ID。我的意思是一个带有 ID 的容器元素，它靠近您实际定位的元素。然而，故意覆盖应该总是花费最少的努力，这就是 ID 真正帮助而不是阻碍你的地方（参见下面的示例）。如果你发现自己处于“ID、类和标签用完”的境地，我建议你使用暴力（至少是想象中的暴力）。但说真的，有人应该受到打击。
CSS Lint, like JS lint is an opinion disguised as validation, not an authority.
I've been at this for five years. I've worked on very large retail sites, at interactive agencies, as a solo contractor, and am currently at a SaaS firm.
The idea that IDs are unequivocally bad, IMO is only an idea you could arrive at if your CSS-fu when it comes to dealing with teams wasn't that great to begin with.
Good, flexible CSS, IMO, follows the following general best practices:
Always move from general to specific. Font-family and most-common font-size for general body text for instance, should only ever be declared in one place. As you move up to selectors that more typically involve use of classes, you'll start to override font-size. When it comes time to apply a mostly unused font-family to a very specific subset of HTML, that's when it makes sense to use an ID on a container to hit the elements getting the body text variation.
The more generally applied a property is, the easier it should be to override and you shouldn't ever be worried about overwriting your most general properties by accident. This for instance, body#some_id div, is an incredibly bad selector to use for that reason. At the 2nd-ish tier (there are 3...ish) where you're typically dealing more with bundles of commonly re-used elements tied to classed containers, it should be a little harder to overwrite those properties by accident. 'By accident' happens more frequently, IMO, when you've got piles of multiple-class selectors all over the place. In the last tier, you should be dealing not with re-usable elements but overrides for highly specific sections of a document. Using an ID in these circumstances is an ideal practice, not a bad one but IDs are best used sparingly and only for the specific properties of the elements in the item container that the ID actually needs to change.
The more specific a selector is, the harder it should be to break it by accident. By specific, I don't just mean IDs on the element. I mean an ID'd container element that sits close to the element you're actually targeting. Intentionally overriding, however, should always involve minimal effort, which is where IDs actually help rather than hinder you (see example below). If you ever find yourself in a position of "running out of IDs, classes, and tags" I recommend violence (at least imaginary violence). But seriously, somebody deserves to be hit.
Avoid lengthy selector lists: you should start to feel like you're 'doing it wrong' any time you regularly use 4+ selectors values for a declaration. I would not count > as a tag/value when tallying since using that wisely is an excellent practice for both maintainability and performance.
Avoid Specificity Arms Races: You know the guy. The "don't mess with my stuff" rookie who decided the best way to cover his butt was use every tag, selector and ID he could starting with the body. Don't hire that guy or spank him until he stops. But even on more forward-looking teams, arms races can still start innocently enough if you don't (sparingly) add more weight to selectors in places where it makes sense to.
The minimalist approach in particular is huge. The more you rely on HTML placement to avoid needing CSS in the first place, the better. The better job you've done at distributing the most general styles globally, the less you have to worry about in more specific contexts. The more pinpoint-targeted and concise highly specific property overrides are, the easier they are to manage in the long haul. And this is where the blanket non-ID policy is stupid IMO.
What's more practical and straightforward to override?
This:
body .main-content .side-bar .sub-nav > ul > li > button
Or this?
#sub-nav button
If you generally work solo or only do small projects to keep up the appearance of doing web dev for a living while making your real money at speaking engagements, the upper one might seem silly and unlikely to you but when you work with a team and you're following a class-only policy, and you just got burned for not using high enough specificity recently, it would be very easy to start adding more and more classes and tags to your stuff (just to avoid trouble on a short deadline - you'll change it back later of course), resulting in a gargantuan unpredictable convoluted mess in your CSS files.
So: Try to never use more than one ID and only for properties that are local to a container that doesn't contain other containers. Try to never use more than one or two classes. Avoid classes and IDs that target elements from on-high (the containers they represent are many many ancestor nodes above). More than 3-4 tags is probably too much in most cases until it's time for some maintenance or training/spanking of rookies. And follow the boyscout rule. Zap those importants and obviously overly specific selectors as you go when it's safe to.
But stick with rules of thumb rather than CSS "laws" and make sure you evaluate these ideas in the light of experience. Don't trust anybody or any tool that spouts blanket statements like "never use IDs" for something with as many variables as a CSS layout scenario can have. That's just noob kool-aid as far as I'm concerned and the authors responsible should know better by now if they want to claim to be experts at it.
发布评论
评论（6）
他们的论点被 lonesomeday 在他们的回答中提到，它将它与 HTML 紧密耦合并且不允许重用。
我可以提出一个论点，在某些情况下，您不希望除单个元素之外的任何其他元素使用样式，因此在 id 选择器上指定它是有意义的。
这一切都取决于个人喜好。这并不是什么必须遵守的硬性规则，它似乎是 CSS Lint 团队的想法，而不是导致错误或其他任何情况的规则。
Their argument is mentioned by lonesomeday in their answer, that it tightly couples it to the HTML and doesn't allow for reuse.
I could make an argument, that there are cases where you don't want a style to be used by anything other than a single element, so specifying it on an id selector would make sense.
It's all going to come down to personal preference. This isn't some hard and fast rule that you have to adhere to, it appears to be the thinking of the CSS Lint team, not a rule that causes errors or anything.
当您管理大量 CSS 或大型网站时，就会出现一个大问题。根据定义，ID 不可重复使用。但你也会遇到具体的问题。当你开始改变特异性时，你就会陷入令人讨厌的风格竞争条件。 ID 比类具有更多的特异性，但内联样式比 ID 具有更多的特异性。内联样式比外部样式表更具特异性。通过使用类，您可以标准化样式应用于元素的方式，从而使事情变得更加可预测。这往往会简化开发，尤其是在与多人合作时。
A big issue comes in when you are managing a lot of CSS or large websites. IDs by definition are not reusable. But you also get into issues with specificity. You get into nasty race conditions with styles when you start changing specificity. IDs have more specificity then classes, but inline styles have more than IDs. Inline styles have more specificity than external style sheets. By using classes you standardize how styles are applied to your elements making things more predictable. This tends to ease development, especially when working with multiple people.
组件：如果您编写可重用组件，例如带有 id 的表格（例如
），那么如果您将两个表格放入一个文档中，那么您将得到 无效 html。COMPONENTS: if you write reusable component e.g. table with id (e.g.
<div id="data">) then if you put two tables into one document then you will get INVALID html.CSSLint 给出了他们提出建议的原因指南：
（来自 禁止选择器中的 ID。）
基本上，如果您构建如果你的代码使用类而不是 ID，你的代码可以更加通用和可重用，这通常是一件好事。此外，特异性是一件很难让您理解的事情，并且可能会导致难以发现的错误，因此如果您省略 ID 选择器，则不太可能以意想不到的方式解决冲突的规则。
CSSLint gives a guide to why they make their recommendations:
(From Disallow IDs in selectors.)
Basically, if you structure your code to use classes rather than IDs, your code can be more general and reusable, which is generally a good thing. Furthermore, specificity is a hard thing to get your head around, and can cause bugs that are hard to find, so if you omit ID selectors, you're less likely to have conflicting rules resolved in unexpected ways.
我不同意从不使用 ID 来选择元素的想法，但我确实理解其中的原因。
通常，当一般形式就足够时，开发人员会使用非常高的特异性选择器：
可能更好地写为
另外，像这样的写作风格：
更好地写为：
我与 CSSLint 的不同之处涉及重用的结构 ID。
我经常用这种结构标记页面：
并且因为我知道结构是一致的，所以我不介意使用
#page、#header、#nav< /code>、#wrapper、#content、#sidebar和#footer在我的 css 中用于扫描区域-特定风格。这些样式与此特定结构紧密耦合，这使得它们可重用性较差；因为我重用了该结构，所以它们是可重用的。需要记住的重要一点是，在选择器中使用 ID 是非常具体的，应该谨慎使用。关于特异性的几句话：
一般来说，应该使用尽可能低的特异性选择器，以使正确选择：
如果您的目标是所有
元素，那么使用a是有意义的。如果您的目标是
中的所有元素，那么使用.foo a< 是有意义的/代码>。如果您要定位
中的所有元素，则使用#bar a< 是有意义的/代码>。 但是，您可以使用较低特异性的选择器。[id="bar"] a与.foo a具有相同的特异性，这意味着您仍然可以通过 ID 定位特定元素，而无需创建具有不必要的高特异性的选择器。我不通常建议使用
[id="XXXX"]选择器来选择[id]属性，因为它很冗长并且可能会导致困惑。我确实建议使用[data-id="XXXX"]选择器基于自定义[data-*]属性< /a> 将样式与当前状态更紧密地联系起来DOM 节点数。I disagree with the idea of never using IDs for selecting elements, however I do understand the reasoning.
Oftentimes developers will use a very high specificity selector when the general form will suffice:
is probably better written as
Additionally, writing styles like:
are better written as:
Where I differ from CSSLint involves structural IDs that are reused.
I often mark up pages with this structure:
And because I know that structure is consistent, I don't mind using
#page,#header,#nav,#wrapper,#content,#sidebar, and#footerin my css for sweeping region-specific styles. These styles are tightly coupled to this particular structure, which makes them less reusable; because I reuse the structure, they are reusable. The important thing to remember is that using an ID in a selector is very specific, and should be used sparingly.A few words on specificity:
Generally speaking, one should use the lowest possible specificity selector that makes the correct selection:
If you're targeting all
<a>elements, then it makes sense to usea.If you're targeting all
<a>elements within<div class="foo">, then it makes sense to use.foo a.If you're targeting all
<a>elements within<div id="bar">, then it makes sense to use#bar a. However, you could use a lower specificity selector.[id="bar"] ahas the same specificity as.foo a, which means that you can still target specific elements by ID without creating selectors with unnecessarily high specificity.I do not generally recommend using
[id="XXXX"]selectors for selecting on the[id]attribute, because it's verbose and may cause confusion. I do recommend using[data-id="XXXX"]selectors for selecting based on custom[data-*]attributes to more closely relate styles to the current state of DOM nodes.首先：
CSS Lint，就像 JS lint 一样，是一种伪装成验证的观点，而不是权威。
我从事这个工作已经五年了。我曾作为独立承包商在大型零售网站、互动机构工作过，目前在一家 SaaS 公司工作。
ID 无疑是不好的想法，在我看来，只是当你在与团队打交道时的 CSS fu 一开始就不是那么好时，你才能得出这样的想法。
在我看来，良好、灵活的 CSS 遵循以下通用最佳实践：
始终从通用转向具体。例如，一般正文文本的字体系列和最常见的字体大小只能在一个地方声明。当您升级到更通常涉及类的使用的选择器时，您将开始覆盖字体大小。当需要将大多数未使用的字体系列应用于非常特定的 HTML 子集时，就需要在容器上使用 ID 来命中获取正文文本变体的元素。
属性应用得越广泛，就越容易覆盖，并且您不必担心会意外覆盖最常用的属性。例如，
body#some_id div就是一个非常糟糕的选择器。在第二层（有 3 个...左右），您通常更多地处理与分类容器相关的常用重用元素束，因此意外覆盖这些属性应该会更困难一些。在我看来，当你到处都有成堆的多类选择器时，“意外”发生的频率会更高。在最后一层，您应该处理的不是可重用元素，而是覆盖文档中高度特定的部分。在这些情况下使用 ID 是一种理想的做法，并非坏事，但最好谨慎使用 ID，并且仅用于 ID 实际需要更改的项目容器中元素的特定属性。选择器越具体，就越难意外破坏它。我所说的“具体”并不仅仅指元素上的 ID。我的意思是一个带有 ID 的容器元素，它靠近您实际定位的元素。然而，故意覆盖应该总是花费最少的努力，这就是 ID 真正帮助而不是阻碍你的地方（参见下面的示例）。如果你发现自己处于“ID、类和标签用完”的境地，我建议你使用暴力（至少是想象中的暴力）。但说真的，有人应该受到打击。
避免冗长的选择器列表：只要您经常在声明中使用 4 个以上的选择器值，您就应该开始感觉自己“做错了”。我不会数>作为计数时的标签/值，因为明智地使用它对于可维护性和性能来说都是一个很好的实践。
避免特异性军备竞赛：你认识这个人。这位“别弄乱我的东西”的新秀决定遮盖屁股的最佳方法是从身体开始使用他能使用的所有标签、选择器和 ID。在他停下来之前，不要雇用那个人或打他的屁股。但即使在更具前瞻性的团队中，如果您不（谨慎地）在有意义的地方为选择器添加更多权重，军备竞赛仍然可能会无害地开始。
极简主义的方法尤其重要。您越是依赖 HTML 布局来避免首先需要 CSS，效果就越好。您在全球范围内分发最通用的样式方面做得越好，您在更具体的上下文中不必担心的就越少。高度具体的属性覆盖越有针对性和简洁，从长远来看就越容易管理。在我看来，这就是一揽子非身份证政策愚蠢的地方。
还有什么更实用、更容易重写的呢？
这个：
body .main-content .side-bar .sub-nav > ul>力>按钮
还是这个？
#sub-nav 按钮如果您通常独自工作或只做小项目，以维持以 Web 开发为生的外表，同时通过演讲活动赚取真正的钱，那么上面的一个可能看起来很愚蠢，并且这对你来说不太可能，但是当你与一个团队合作并且遵循仅限类的策略时，并且你刚刚因为最近没有使用足够高的特异性而感到恼火，那么很容易开始向你的团队添加越来越多的类和标签东西（只是为了避免在短时间内出现麻烦 - 你会当然稍后再把它改回来），导致 CSS 文件中出现巨大的、不可预测的、错综复杂的混乱。
因此：尽量不要使用多个 ID，并且仅用于不包含其他容器的容器的本地属性。尽量不要使用超过一两个类。避免以高层元素为目标的类和 ID（它们代表的容器是上面的许多祖先节点）。在大多数情况下，超过 3-4 个标签可能就太多了，直到需要对新手进行一些维护或培训/打屁股为止。并遵守童子军规则。在安全的情况下，删除那些重要的和明显过于具体的选择器。
但要坚持经验法则而不是 CSS“法则”，并确保根据经验评估这些想法。不要相信任何人或任何工具，他们会针对 CSS 布局场景所能拥有的变量数量发出诸如“永远不要使用 ID”之类的笼统声明。就我而言，这只是菜鸟的帮助，如果负责的作者想声称自己是这方面的专家，他们现在应该更清楚了。
First of all:
CSS Lint, like JS lint is an opinion disguised as validation, not an authority.
I've been at this for five years. I've worked on very large retail sites, at interactive agencies, as a solo contractor, and am currently at a SaaS firm.
The idea that IDs are unequivocally bad, IMO is only an idea you could arrive at if your CSS-fu when it comes to dealing with teams wasn't that great to begin with.
Good, flexible CSS, IMO, follows the following general best practices:
Always move from general to specific. Font-family and most-common font-size for general body text for instance, should only ever be declared in one place. As you move up to selectors that more typically involve use of classes, you'll start to override font-size. When it comes time to apply a mostly unused font-family to a very specific subset of HTML, that's when it makes sense to use an ID on a container to hit the elements getting the body text variation.
The more generally applied a property is, the easier it should be to override and you shouldn't ever be worried about overwriting your most general properties by accident. This for instance,
body#some_id div, is an incredibly bad selector to use for that reason. At the 2nd-ish tier (there are 3...ish) where you're typically dealing more with bundles of commonly re-used elements tied to classed containers, it should be a little harder to overwrite those properties by accident. 'By accident' happens more frequently, IMO, when you've got piles of multiple-class selectors all over the place. In the last tier, you should be dealing not with re-usable elements but overrides for highly specific sections of a document. Using an ID in these circumstances is an ideal practice, not a bad one but IDs are best used sparingly and only for the specific properties of the elements in the item container that the ID actually needs to change.The more specific a selector is, the harder it should be to break it by accident. By specific, I don't just mean IDs on the element. I mean an ID'd container element that sits close to the element you're actually targeting. Intentionally overriding, however, should always involve minimal effort, which is where IDs actually help rather than hinder you (see example below). If you ever find yourself in a position of "running out of IDs, classes, and tags" I recommend violence (at least imaginary violence). But seriously, somebody deserves to be hit.
Avoid lengthy selector lists: you should start to feel like you're 'doing it wrong' any time you regularly use 4+ selectors values for a declaration. I would not count > as a tag/value when tallying since using that wisely is an excellent practice for both maintainability and performance.
Avoid Specificity Arms Races: You know the guy. The "don't mess with my stuff" rookie who decided the best way to cover his butt was use every tag, selector and ID he could starting with the body. Don't hire that guy or spank him until he stops. But even on more forward-looking teams, arms races can still start innocently enough if you don't (sparingly) add more weight to selectors in places where it makes sense to.
The minimalist approach in particular is huge. The more you rely on HTML placement to avoid needing CSS in the first place, the better. The better job you've done at distributing the most general styles globally, the less you have to worry about in more specific contexts. The more pinpoint-targeted and concise highly specific property overrides are, the easier they are to manage in the long haul. And this is where the blanket non-ID policy is stupid IMO.
What's more practical and straightforward to override?
This:
body .main-content .side-bar .sub-nav > ul > li > buttonOr this?
#sub-nav buttonIf you generally work solo or only do small projects to keep up the appearance of doing web dev for a living while making your real money at speaking engagements, the upper one might seem silly and unlikely to you but when you work with a team and you're following a class-only policy, and you just got burned for not using high enough specificity recently, it would be very easy to start adding more and more classes and tags to your stuff (just to avoid trouble on a short deadline - you'll change it back later of course), resulting in a gargantuan unpredictable convoluted mess in your CSS files.
So: Try to never use more than one ID and only for properties that are local to a container that doesn't contain other containers. Try to never use more than one or two classes. Avoid classes and IDs that target elements from on-high (the containers they represent are many many ancestor nodes above). More than 3-4 tags is probably too much in most cases until it's time for some maintenance or training/spanking of rookies. And follow the boyscout rule. Zap those importants and obviously overly specific selectors as you go when it's safe to.
But stick with rules of thumb rather than CSS "laws" and make sure you evaluate these ideas in the light of experience. Don't trust anybody or any tool that spouts blanket statements like "never use IDs" for something with as many variables as a CSS layout scenario can have. That's just noob kool-aid as far as I'm concerned and the authors responsible should know better by now if they want to claim to be experts at it.