一般情况下，我们是否可以考虑最初无效的HTML文档，但最终在技术上有效（通过脚本编写）才能正常使用？
“OK”将是良好做法，或者可能是关于标准，如果它回答了这个问题。
例如，解析此序列化HTML标记所得的文档最初使用W3 validator验证：
<!DOCTYPE html>
<title>foo</title>
bar
虽然这个没有：
<!DOCTYPE html>
<script>document.title = 'foo'</script>
bar
即使任何支持Javascript的浏览器的结果完全相同，也就是这样。假设这是一个Web应用程序并且需要JS，这种事情是否“OK”？
当我们不有任何正确的（从应用程序角度来看）最初满足标准的方式时，我特别想知道这种情况。例如，如果我们最初不知道文档的标题，并且必须使用脚本计算/检索它，该怎么办？
在这种特殊情况下，使用占位符会出错：
<!DOCTYPE html>
<title>placeholder</title>
<script>document.title = 'foo'</script>
bar
（请注意，将title元素保留为空仍被视为无效。）
所以，在没有特别讨论title元素的情况下，是否通常接受分发仅最终有效的HTML资源？
子问题：我意识到验证文档（由DOM表示）并验证其序列化标记是两回事;有没有工具可以做前者？ （来自DOM的快照或“连续”。）示例：
<!DOCTYPE html>
<title>foo</title>
<script>document.title = ''</script>
bar
这最初验证但技术上导致文档无效，没有任何明显的方法来检测它。
更新：显然，这样的工具在静态分析环境中的价值有限（停止问题等）。但是，运行时工具应该很有用。
更新： W3C spec for DOM validation (Level 3)。
更新： W3C spec for Service Workers，似乎可以用来确保DOM在呈现之前有效，即使模板不是这样（避免使用占位符元素等） ）。在撰写本文时（2014年6月26日，所以请不要引用我）。
答案 0 :(得分：2)
无效的HTML文档不确定，即使您出于各种原因使脚本无效也是如此。
在运行脚本之前，HTML文档在加载时进行验证和解析。因此，即使您使用脚本“修复”您的文档，您的文档也很有可能是时髦的。即使您在脚本中生成所有内容，许多浏览器也不会接受。
此外，如果你关心搜索引擎，请记住：
最后但同样重要的是，不要忘记少量禁用脚本的客户端。
答案 1 :(得分：0)
我看不出你想如何决定文件'最终是否在技术上有效'。脚本代码可以指任意上下文状态（现有dom，用户客户端信息，localstorage，用户输入，web请求响应url）。大多数此类信息预先无法访问验证器。
您的方案可能适用于非常有限的脚本指令子集，但我无法看到它在现实生活应用程序中的用途。
所以，不，我不认为最终验证的概念是合理的。不能正常验证的文件不应该被认为是正确的。