将浏览器切换到严格模式以编写正确的 html 代码
Switch browser to a strict mode in order to write proper html code
是否可以将浏览器切换到 "strict mode" 以便至少在开发阶段编写正确的代码？
我总是看到无效、肮脏的 html 代码（除了糟糕的 javascript 和 css），我觉得一个原因也是所有浏览器的高容忍度。所以至少我会准备好在使用浏览器开发页面时采用更严格的模式，以迫使自己使用正确的代码。
任何已知的浏览器是否有类似的东西？
我知道 w3c-validator 但老实说谁经常使用它？
浏览器和验证器之间是否存在某种常规接口？是否有自动测试验证的开发环境？
Is there anything like that with any of the known browser? Is there maybe some sort of regular interface between browser and validator? Are there any development environments where the validation is tested automatically?
所有这些问题的答案都是“否”。没有浏览器像您描述的那样具有任何内置集成。有（或曾有）一些浏览器扩展会获取您加载的每个文档并将其发送到 W3C 验证器进行检查，但是使用其中一个扩展（或任何其他在后台自动将内容发送到 W3C 验证器的东西）是一个让 W3C 阻止您的 IP 地址（或整个公司网络的 IP 地址范围）滥用 W3C 服务的好方法。
I know about w3c-validator but honestly who is really using this frequently?
W3C 验证器目前每秒处理大约 17 个请求——每天大约 150 万个文档——所以我想有相当多的人经常使用它。
I see always invalid, dirty html code… I would be ready to have a stricter mode while I use the browser for the development for the pages in order to force myself to proper code.
我不确定你所说的“脏 html 代码”或“正确代码”具体指的是什么，但我可以说有很多标记案例都不错或无效，但有些人们错误地认为不好。
例如，有些人认为每个 <p> 开始标签都应该有一个匹配的 </p> 结束标签，但事实是，从 HTML 创建时起，它已经从不要求文档在所有情况下都始终具有匹配的 </p> 结束标记（事实上，当 HTML 创建时， <p> 元素基本上是一个空元素——而不是容器——所以<p> 标签只是一个标记。
另一个被一些人错误地认为是不好的例子是未加引号的属性值；例如，<link rel=stylesheet …>。但事实是，除非属性值包含空格，否则通常不需要用引号引起来。所以实际上像 <link rel=stylesheet …>.
这样的情况实际上没有任何问题
所以基本上没有必要尝试寻找一种工具或机制来检查此类情况，因为这些情况实际上并不是真正的问题。
综上所述，HTML 规范确实将一些标记案例定义为错误，而这些案例正是 W3C 验证器检查的内容。
因此，如果您想发现真正的问题并能够解决它们，答案很简单：使用 W3C 验证器。
披露：我是 W3C 验证器的维护者。
正如@sideshowbarker 所说，目前所有浏览器都没有内置任何东西。
但是我确实喜欢这个想法并希望也有这样的工具（这就是我得到这个问题的方式）
有一个 "partial" 解决方案，如果您使用 Firefox，并查看源代码（不是开发人员工具，而是 CTRL+U 或右键单击 "View Page Source") Firefox 将在原始 HTML 源中以红色突出显示无效的标签嵌套和属性问题。我发现这是非常宝贵的第一遍查看似乎无法正常工作的页面。
它非常好，因为它对未引用的 asdf id 或某个属性是否被弃用不是特别挑剔，但它会突出显示 td 上的间距等小问题attributes 搞砸了（如果没有引用属性，这会导致问题），并且发现 span 标签没有正确关闭，并且 script 标签在 [=14= 之外] 标签，如果我错过了 doctype 或前面有内容，它也会标记出来。
不幸的是 "seeing" 这些问题是一个手动过程...我很乐意在开发控制台和所有浏览器中看到这些问题。
大多数 plugins/extensions 只有在 DOM 被解析后才能访问 DOM 并且这些错误消失或被否定...但是如果有办法获得 raw HTML 这些扩展模型之一的源代码，我们可以编写一个扩展来测试这些类型的错误，我非常愿意帮助编写一个（DM @scunliffe on Twitter). Alternatively this may require writing something at a lower level, like a script to run in Fiddler.
是否可以将浏览器切换到 "strict mode" 以便至少在开发阶段编写正确的代码？
我总是看到无效、肮脏的 html 代码（除了糟糕的 javascript 和 css），我觉得一个原因也是所有浏览器的高容忍度。所以至少我会准备好在使用浏览器开发页面时采用更严格的模式，以迫使自己使用正确的代码。
任何已知的浏览器是否有类似的东西？
我知道 w3c-validator 但老实说谁经常使用它？
浏览器和验证器之间是否存在某种常规接口？是否有自动测试验证的开发环境？
Is there anything like that with any of the known browser? Is there maybe some sort of regular interface between browser and validator? Are there any development environments where the validation is tested automatically?
所有这些问题的答案都是“否”。没有浏览器像您描述的那样具有任何内置集成。有（或曾有）一些浏览器扩展会获取您加载的每个文档并将其发送到 W3C 验证器进行检查，但是使用其中一个扩展（或任何其他在后台自动将内容发送到 W3C 验证器的东西）是一个让 W3C 阻止您的 IP 地址（或整个公司网络的 IP 地址范围）滥用 W3C 服务的好方法。
I know about w3c-validator but honestly who is really using this frequently?
W3C 验证器目前每秒处理大约 17 个请求——每天大约 150 万个文档——所以我想有相当多的人经常使用它。
I see always invalid, dirty html code… I would be ready to have a stricter mode while I use the browser for the development for the pages in order to force myself to proper code.
我不确定你所说的“脏 html 代码”或“正确代码”具体指的是什么，但我可以说有很多标记案例都不错或无效，但有些人们错误地认为不好。
例如，有些人认为每个 <p> 开始标签都应该有一个匹配的 </p> 结束标签，但事实是，从 HTML 创建时起，它已经从不要求文档在所有情况下都始终具有匹配的 </p> 结束标记（事实上，当 HTML 创建时， <p> 元素基本上是一个空元素——而不是容器——所以<p> 标签只是一个标记。
另一个被一些人错误地认为是不好的例子是未加引号的属性值；例如，<link rel=stylesheet …>。但事实是，除非属性值包含空格，否则通常不需要用引号引起来。所以实际上像 <link rel=stylesheet …>.
所以基本上没有必要尝试寻找一种工具或机制来检查此类情况，因为这些情况实际上并不是真正的问题。
综上所述，HTML 规范确实将一些标记案例定义为错误，而这些案例正是 W3C 验证器检查的内容。
因此，如果您想发现真正的问题并能够解决它们，答案很简单：使用 W3C 验证器。
披露：我是 W3C 验证器的维护者。
正如@sideshowbarker 所说，目前所有浏览器都没有内置任何东西。
但是我确实喜欢这个想法并希望也有这样的工具（这就是我得到这个问题的方式）
有一个 "partial" 解决方案，如果您使用 Firefox，并查看源代码（不是开发人员工具，而是 CTRL+U 或右键单击 "View Page Source") Firefox 将在原始 HTML 源中以红色突出显示无效的标签嵌套和属性问题。我发现这是非常宝贵的第一遍查看似乎无法正常工作的页面。
它非常好，因为它对未引用的 asdf id 或某个属性是否被弃用不是特别挑剔，但它会突出显示 td 上的间距等小问题attributes 搞砸了（如果没有引用属性，这会导致问题），并且发现 span 标签没有正确关闭，并且 script 标签在 [=14= 之外] 标签，如果我错过了 doctype 或前面有内容，它也会标记出来。
不幸的是 "seeing" 这些问题是一个手动过程...我很乐意在开发控制台和所有浏览器中看到这些问题。
大多数 plugins/extensions 只有在 DOM 被解析后才能访问 DOM 并且这些错误消失或被否定...但是如果有办法获得 raw HTML 这些扩展模型之一的源代码，我们可以编写一个扩展来测试这些类型的错误，我非常愿意帮助编写一个（DM @scunliffe on Twitter). Alternatively this may require writing something at a lower level, like a script to run in Fiddler.