忽视速度和兼容性，为什么不使用类，并且从不使用HTML / CSS中的ID？ [英] Disregarding speed and compatibility, why not use only classes and never use IDs in HTML/CSS?

问题描述

我只使用类并从不使用ID。
很多人喜欢使用ID，出于不同的原因。

我已经看到很多关于id和stackoverflow上的类的问题，但没有人提到纯代码组织点从代码组织的角度来看，我认为使用ID很不好，就像在Visual Basic代码中使用全局变量一样。

原因之一是ID必须是唯一的，这会在代码的不同独立部分之间引入不必要和不良依赖（控制HTML DOM树的不同部分）。

另一个原因是，创建新的类名实际上比ID名称更容易，因为使用ID您必须担心全局范围和类名，您只需要担心局部范围内的唯一性，与局部变量一样。

大多数人会认为，通过ID处理的表现要好于类，我同意这一点。但是，随着浏览器变得更加先进，本地实现了来自javascript的CSS寻址并且计算机变得更快，性能变得越来越不重要。所以让我们忽视它，只关注当前问题的上下文中的代码组织。

这个讨论开始于这里，但是我的潜在错误建议会产生负面影响，并且变得太大以至于无法留言，所以我在这里尝试转换它变为积极和可管理的。

有利于ID的一个可见点是将它们用作规则优先级排序的工具，因为#name的优先级高于优先级。名称。
我的回应：使用ID来提高优先级是不好的破解，它更干净，并且如果您使用在主体和其他树级别之间插入的额外根元素（例如 body div的优先级） div span.class1 {} 高于 body div span.class1 {} 高于 body span.class1 { } 高于 span.class1 {} 。另一个用于此目的的工具是！important 。
有些人可能会争辩说，使用更多的根元素意味着更多的困难，当页面结构改变时，但我不认为这是这种情况，因为你不必在身体和指定优先级divs之间的任何东西。这些div始终可以保持低于正文，高于所有其他内容。

另一个有趣的关联是关于指针，ID并不坏，因为指针并不坏。
我的回应：如果您在代码中硬编码绝对内存地址，则指针是不好的。使用相对指针总是更好（例如：在8086 CPU中使用段（CS，DS，SS，ES）;编译器生成的相对变量和方法地址）。如果我们将DOM树视为内存并使用ID与使用类进行比较，那么 #name 表示绝对内存地址，但 div.tab1 .name 表示相对地址（相对于 div.tab1 ）。

另一个支持点可见的ID是具有ID的元素更容易在JavaScript中用作全局属性。我的回应：再次，这就像是说Visual Basic中的全局变量更方便可用。问题在于，如果不引入像level1_level2_name这样的命名层次结构，就无法保持足够大的全局（或任何其他）名称空间，这只是将一个名称空间机制替换为另一个名称空间机制的一种手段。

使用下划线命名空间模拟内部ID是不好的，因为你不能建立命名上下文并且必须重复所有的命名空间代码中的所有路径。这实际上意味着您将无法使用CSS修复CSS无法使用上下文的CSS 预处理器。

解决方案

我一般同意你的看法：类使用起来更简洁;你可以创建命名空间并清理它们的级联;他们可以结合： class ='class1 class2'。

在页面上寻找真正独特的元素，尤其是当处理稍后将要在JavaScript中更改的元素时（例如隐藏的叠加层）。

I use only classes and never use IDs. Many people like to use IDs for different reasons.

I've seen many questions regarding IDs vs classes on stackoverflow, but no one addressed pure code organization point of view disregarding compatibility and runtime performance.

From code organization point of view, I think that using IDs is bad just like using global variables in Visual Basic code.

One reason is that IDs have to be unique which introduces unnecessary and bad dependency between different independent parts of your code (controlling different parts of HTML DOM tree).

Another reason is that making new class names is actually easier than ID names because with IDs you have to worry about global scope and with class names you need to worry only about uniqueness in local scope, same benefit as with local variables.

Most people will argue that performance of addressing by ID is better than by class and I will agree with that. But as browsers become more advanced with native implementations of CSS addressing from javascript and computers become faster, performance becomes less and less important. So let's disregard it and concentrate only on organization of code in context of current question.

This discussion started here, but my potentially wrong advice generates negative points and became too big to keep in comments, so here I try to convert it into something positive and manageable.

One visible point in favor of IDs is to use them as a tool of rule prioritization because priority of #name is higher than priority of .name. My response: using IDs to raise priorities is bad hack, it's cleaner and there is more freedom if you use additional root elements inserted between body and other levels of tree, for example priority of body div div span.class1{} is higher than body div span.class1{} is higher than body span.class1{} is higher than span.class1{}. Another tool to use for that purpose is !important. Some may argue that using more root elements means more difficulties when the page structure changes, but I don't think this is the case because you never have to put anything between body and designated for prioritization divs. Those divs can always stay below body and above all other content.

Another interesting association was brought about pointers and that IDs are not bad because pointers are not bad. My response: pointers are bad if you hardcode absolute memory address in your code. Using relative pointers is always better (examples: using segments(CS,DS,SS,ES) in 8086 CPU; relative variable and method addresses generated by compilers). If we consider DOM tree as memory and compare using ID to using class then #name represents absolute memory address, but div.tab1 .name represents relative address (relative to div.tab1).

Another supporting point that I've seen for IDs is that elements with IDs are more easily available in javascript as becoming global properties. My response: again, this is like saying that global variables in Visual Basic are more conveniently available. The problem is that you can't keep large enough global (or any other) namespace in order without introducing naming hierarchy like level1_level2_name, which is just a hack to replace one namespace mechanism with another. DOM tree is convenient enough to organize namespaces, why disregard it ?

Namespace simulation inside IDs using underscore is bad because you can't establish naming context and will have to duplicate all paths everywhere in your code. That practically means that you won't be able to use CSS preprocessors that fix inability of CSS to use contexts.

解决方案

I agree with you in general: Classes are much cleaner to use; you can create "namespaces" and clean cascades with them; and they can be combined: class='class1 class2'.

IDs still have their place when you're addressing really unique elements on the page, especially when addressing an element that is going to be changed in JavaScript later (e.g. a hidden overlay.)

这篇关于忽视速度和兼容性，为什么不使用类，并且从不使用HTML / CSS中的ID？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！