所以我经常使用网站LiveWeave.com来测试我编写的HTML,CSS和JavaScript代码。它有一个语法检查器,每当我在CSS部分使用ID作为选择器时,它表示使用ID作为选择器是不合适的。
我已在this Weaver中证明了这一点。 CSS窗口中第三行的右侧是一个黄色图标,当它悬停在上面时,表示使用ID作为选择器是不合适的。我的印象是,这是专门用于单个DOM元素的选择器,而不是类,它被设计为应用于多个DOM元素。
我错了吗?使用ID作为选择器是不合适的吗?
我能想到的唯一其他实例是JavaScript document.getElementById()
和类似的函数。 ID的正确使用是什么?
请注意,我不是要求ID和类之间的区别,而是使用ID作为选择器是否合适。
答案 0 :(得分:2)
使用ID是在CSS和Javascript中选择DOM节点的最有效方式。我个人喜欢使用所有重复项目的类和唯一项目的ID,或重复模块的唯一配置。有很多CSS模式,我使用一种称为BEM(Block,Element,Modifier,见here)的样式,它是一种基于类的命名约定。查看您喜欢的网站,右键单击或检查。你会发现你的问题没有一个正确的答案,只有很多正确的答案。
我可以说,由于某种原因,这两者都存在于标准中,并根据您的应用需求提供服务。
以下是选择器的效率顺序。 ID是最有效的伪类,伪元素效率最低。
id (#myid)
class (.myclass)
tag (div, h1, p)
adjacent sibling (h1 + p)
child (ul > li)
descendent (li a)
universal (*)
attribute (a[rel=”external”])
pseudo-class and pseudo element (a:hover, li:first)
见here ...
答案 1 :(得分:2)
使用ID作为选择器并不是不合适的,只要使用的ID只对应于DOM(文档对象模型)中的一个元素。
如果您希望选择器具有多功能,并且能够应用于DOM中的多个元素,请使用类。虽然我确定你知道这一点。
一些CSS开发人员和完整堆栈设计师不赞成ID的主要原因仅仅是因为它们不是多功能的,它们具有比类更高的特异性,这可能有助于或阻碍开发(基于CSS知识)。
有关CSS特异性的更多信息,请阅读:https://css-tricks.com/specifics-on-css-specificity/
答案 2 :(得分:1)
它是有效的,它被一些开发人员认为是不好的做法,因为如果你没有遵守规则,它可能会很难维护你的CSS。我不是CSS的专家,但我很确定这与#具有非常高的特异性评级有关,如果你将它们点缀在你的CSS文件中,就很难管理级联,即样式规则的继承。因此,有些人认为只使用ID来引用JavaScript中的元素。
答案 3 :(得分:0)
有些人提出仅将class
es用于纯css内容并将id
保留为javascript和其他id
特定功能的想法。
网站似乎遵循这种意识形态,所以他们试图让用户采用它。我不确定是否最佳做法让id
远离css
您可以自行决定是否值得使用id
,而只需使用class
。
答案 4 :(得分:0)
除了已经提到的内容之外,即使在CSS中,ID也很有用,具体取决于结构设计。
例如;如果您网站中的每个页面都需要页眉和页脚,我不明白为什么将它作为ID是没有用的。
这样做有什么问题:
#header {}
#footer {}
如果您确定您的网页只有一个页眉和一个页脚,我看不到使用课程的重点。
提到id非常具体,在这种情况下页面结构是不可靠的。
此外,我也没有看到做某事的错误,例如:
.menu{}
#header .menu li{}
#footer .menu li{}
根据页面段添加特定样式。对我来说似乎非常合法。
最终,我甚至认为使用ID来表示页面部分可能更有益于“知道”它们是唯一的(虽然它们可能在不同的页面中反复出现)。
读取CSS文件中的id应该让CSS设计人员能够立即知道以下css规则引用的页面段。
在这种情况下,仅使用类的工作表似乎不如使用ID的imo清晰。
答案 5 :(得分:0)
如果您使用ID作为选择器并且在Javascript中也使用它,那么您可以设置一个情况,如果您决定重命名它,那么您已经创建了一个依赖项,如果您使用了类,则不会存在CSS中的名称。
此外,尽管使用ID更快,但如果您使用#text a则速度不快 - 因为CSS从右向左读取并且必须首先检查所有锚元素,然后找到ID为#的那个文本。
这也意味着样式不可重用,也不能使用多个类。
所以我认为答案确实是,基于使用ID作为选择器的所有优点和缺点,让你摆脱可能的未来问题的最佳做法是不要这样做。当然,这完全取决于您的编码方式,项目范围以及项目中其他人的工作量。它不违反规则,只是不是真正的最佳实践,因为你可能正在构建的问题可能会在以后咬你。