我正在查看所生成内容的未来变化，但尚不建议采用规范。
[Chapter 5 of Cascading Style Sheets Level 2 Revision 2指出生成的内容（伪元素）没有出现在文档源或文档树中。
伪元素或伪类都不会出现在文档源或文档树中。
但是，以上描述在CSS伪元素模块4级，CSS生成的内容模块3级和选择器3级中不存在。
此外，根据CSS Generated Content Module Level 3，生成的内容应该是可搜索的，可选的，并且辅助技术应该能够使用内容信息。
生成的内容应该是可搜索的，可选择的并且可用于辅助技术。 content属性适用于语音，生成的内容必须呈现为语音输出。
从以上所述，我认为将来规范无法保证在文档树上不存在伪元素。生成的内容将来会出现在文档树中吗？
我不会指望生成的内容在不久的将来可以被选择，搜索或可用于辅助技术，但是无论如何都要做好准备。应该是，但不是。在某些时候，浏览器可能会实现规范的这一方面，但是我什么时候也不会屏息。当/如果浏览器确实实现了规范的这一方面，我认为这不会涉及将生成的内容作为一部分的。如果他们这样做了，那将是向后不兼容的，因此应该要求使用其他文档类型。
为了使生成的内容可以选择，可搜索并可供辅助技术使用，它不必是dom的一部分。我认为，通过更改ui访问呈现的文档的方式，而不是更改文档的呈现方式，浏览器实际上更容易实现此类ui工具所生成内容的可用性。意思是，我的猜测是，如果/当生成的内容可用于各种ui工具（搜索/选择/屏幕阅读器）时，它仍然不会成为dom的一部分。
原因是，在应用样式之前先对dom进行结构化和填充。我不是浏览器如何呈现内容的专家，但是我了解足够多，要知道让CSS实际上将内容注入dom将需要对呈现过程进行重大更改。另外，css应该从根本上改变dom的结构并没有任何意义，因为这样做会违背css的本意。
另一方面，更改ui工具访问呈现内容的方式不必涉及从根本上改变呈现过程。包含生成的内容的渲染页面存在于浏览器中。当前ui工具（例如搜索/选择/屏幕阅读器）可以在dom上运行，但并没有根本原因。这些ui工具可以同样轻松地操作最终呈现的结果。
我的猜测是，在dom上运行的这些ui工具是一种旧版实现，尚待重新设计，但实际上应该重新设计。 ui工具应在最终输出上运行。现在随着诸如影子dom之类的问题的出现，需要ui工具对最终渲染的内容进行操作，而不是dom变得更加明显。
因此，我认为生成的内容将来不会成为dom的一部分，尽管它应该并且可能会变为可选，可搜索并且可用于辅助技术。