提问者:小点点

为什么CSS可以使用假元素?


在我的课堂上,我四处游荡,发现CSS可以使用虚构的元素。

示例:

null

imsocool {
    color:blue;
}
<imsocool>HELLO</imsocool>

null

当我的教授第一次看到我使用这个的时候,他有点惊讶于合成元素的工作,并建议我简单地将所有合成元素改为带有ID的段落。

为什么我的教授不希望我使用虚构的元素?它们有效地工作。

还有,为什么他不知道虚构元素的存在,并与CSS一起工作。他们不常见吗?


共3个答案

匿名用户

为什么CSS可以使用假元素?

(大多数)浏览器被设计成(在某种程度上)向前兼容HTML的未来添加。无法识别的元素被解析到DOM中,但没有语义或与它们相关的特殊默认呈现。

当一个新元素被添加到规范中时,有时可以使用CSS、JavaScript和ARIA来在旧浏览器中提供相同的功能(这些元素必须出现在DOM中,以便这些语言能够操作它们来添加该功能)。

(虽然应该注意到定义使用自定义元素扩展HTML的方法的工作正在进行中,但目前这项工作还处于开发的早期阶段,因此在成熟之前应该避免。)

为什么我的教授不希望我使用虚构的元素?

  • HTML规范不允许它们
  • 它们可能与将来同名的标准元素冲突
  • 可能存在更适合任务的现有HTML元素

也;为什么他不知道虚构元素的存在并与CSS一起工作。他们不常见吗?

是的。人们不使用它们是因为它们有上述问题。

匿名用户

DR

  • 自定义标记在HTML中无效。这可能会导致呈现问题。
  • 由于代码不可移植性,因此增加了未来开发的难度。
  • 有效的HTML提供了很多好处,如SEO、速度和专业性。

冗长的回答

有一些参数表明,带有自定义标记的代码更可用。

但是,这会导致无效的HTML。这对您的站点不利。

有效CSS/HTML StackOverflow的点

  • 谷歌更喜欢它,所以它对搜索引擎优化很有好处。
  • 它使您的网页更有可能在未经测试的浏览器中工作。
  • 它使您看起来更专业(至少对某些开发人员而言)
  • 兼容的浏览器可以更快地呈现[有效的HTML]
  • 它指出了您可能错过的一堆模糊的bug,这些bug影响了您可能没有测试过的东西,例如页面的代码页或语言集。

为什么要验证W3C

  • 作为调试工具的验证
  • 验证作为未来保障质量检查
  • 验证简化了维护
  • 验证有助于传授良好实践
  • 验证是专业性的标志

匿名用户

雅达(又一个(不同的)答案)

编辑:请看下面BoltClock关于类型vs标签vs元素的评论。我通常不担心语义,但他的评论是非常恰当和信息。

虽然已经有一堆很好的回复,但你表示你的教授促使你贴出这个问题,所以看起来你(正式)在学校。我想我会更深入地阐述,不仅是CSS,而且是web浏览器的机制。根据维基百科的说法,“CSS是一种样式表语言,用于描述……一个用标记语言编写的文档。”(我加了“a”的强调)注意,它并没有说“用HTML编写”,更没有说是HTML的特定版本。CSS可以用于HTML、XHTML、XML、SGML、XAML等。当然,您需要一些东西来呈现这些文档类型,这些文档类型也会应用样式。根据定义,CSS不知道/理解/关心特定的标记语言标记。因此,就HTML而言,标记可能是“无效的”,但在CSS中没有“有效的”标记/元素/类型的概念。

现代的可视化浏览器不是铁板一块的程序。它们是不同“引擎”的混合体,它们有特定的工作要做。我至少可以想到3个引擎:呈现引擎、CSS引擎和javascript引擎/VM。不确定解析器是呈现引擎的一部分(反之亦然)还是一个单独的引擎,但您已经明白了。

无论可视化浏览器( <罢工> 另一些人已经讨论了这样一个事实: 读者在处理无效标记时可能会遇到其他问题 )应用格式取决于解析器是否在文档中留下“无效”标记,然后呈现引擎是否将样式应用到该标记。由于这会使开发/维护变得更加困难,CSS引擎并不是为了理解“这是一个HTML文档,因此这里是有效标记/元素/类型的列表”而编写的。CSS引擎只是找到标记/元素/类型,然后告诉呈现引擎,“这里是您应该应用的样式”。呈现引擎是否决定实际应用样式取决于它。

这里有一个简单的方法来思考从引擎到引擎的基本流程:解析器->CSS->呈现。实际上,它要复杂得多,但对于初学者来说,这已经足够好了。

这个答案已经太长了,所以我就到此为止。