在CSS生成的内容模块级别3中，生成的内容是否定义为显示在文档树上？

Question

第5章级联样式表第2级修订版2声明生成的内容(伪元素)不会出现在文档源或文档树中。

文档源或文档树中没有出现伪元素或伪类.

然而，上述描述并不存在于CSS伪元素模块级别4、CSS生成的内容模块级别3和选择器级别3中。

此外，根据CSS生成的内容模块级别3，生成的内容应该是可搜索的、可选择的，并且辅助技术应该能够使用内容信息。

生成的内容应该是可搜索的、可选择的，并可供辅助技术使用。content属性适用于语音，必须为语音输出呈现生成的内容。

从以上所述，我认为CSS生成的内容模块级别3中没有保证包含伪元素的生成内容不会出现在文档树上。在CSS生成的内容模块级别3中，生成的内容是否定义为显示在文档树上？

Answer 1

我不会指望所生成的内容是可选择的、可搜索的，或者在短期内可供辅助技术使用，但无论如何，我都要做好准备。应该是，但事实并非如此。在某种程度上，浏览器可能会实现规范的这一方面，但我不会屏住呼吸，不知道何时.当/如果浏览器确实实现了规范的这一方面，我不认为这将涉及到使生成的内容成为dom的一部分。如果是这样的话，这将不是向后兼容的，因此应该需要一个不同的doc类型。

如果生成的内容是可选择的、可搜索的，并且可供辅助技术使用，则不需要成为dom的一部分。我认为浏览器实际上更容易实现这些ui工具的生成内容的可用性，方法是更改ui访问呈现的文档的方式，而不是更改文档的呈现方式。也就是说，我的猜测是，如果/当生成的内容对各种ui工具(搜索/选择/屏幕阅读器)可用时，它仍然不会是dom的一部分。

原因是，在应用样式之前，dom是结构化和填充的。我不是浏览器如何呈现内容的专家，但我了解到让css实际上将内容注入dom将需要在呈现过程中进行重大更改。此外，css应该从根本上改变dom的结构也是没有意义的，因为这样做会违背css的含义。

另一方面，改变ui工具访问呈现内容的方式不需要从根本上改变呈现过程。呈现的页面(包括生成的内容)存在于浏览器中。目前，用户界面工具，如搜索/选择/屏幕阅读器，在dom上运行，但是没有根本的理由必须这样做。这些ui工具同样可以轻松地操作最终呈现的结果。

我的猜测是，这些在dom上运行的ui工具是一种遗留实现，尚未重新设计，但实际上应该重新设计。ui工具应该对最终的输出进行操作。现在，随着影子dom之类的东西的出现，用户界面工具对最终呈现的内容而不是dom的操作变得更加明显。

因此，我不认为生成的内容将来会成为dom的一部分，尽管它应该也可能成为可选择的、可搜索的、可供辅助技术使用的内容。