我从事网络开发已经有一段时间了，帮助我学习的是直观地了解正在发生的事情。
这就是 Aardvark、Web 开发人员、Firebug 和许多其他工具出现的原因。
但是当我看到 Gecko Reflow Videos他们让我大吃一惊。
那么我的问题是，是否可以真正调试 html(单步执行每个元素)？还是接近它？
我一直在做的很多事情是使用 Aardvark 并删除元素，但 Aardvark 在“背景”和相同大小的元素方面存在问题，并且无法定位这些元素。
更新:我一直在努力为这个问题写一个很好的更新，因为它让我对它有了更多的思考。但由于英语不是我的主要语言，所以很难。
在过去的几年里，浏览器承担了与标准兼容的任务。随着他们越来越接近该目标，我们应该考虑在浏览器兼容性最低的情况下我们真正可以创建什么，以及是否有我们可以利用的技术来加快页面呈现速度。
我们可以将过去几十年视为 HTML/CSS 的早年，当时的主要目标只是让它发挥作用。现在我们应该寻找加速当前过程的技术。这方面的一个例子是上面的视频，其中 Gecko 引擎两次运行代码。这是为什么？是否还有其他情况下它会做不必要的事情(即使它们可以工作并且兼容)
这显然需要进行测试才能确认，因此我最初的问题是真正的调试器。
最佳答案
我的 0.02 美元:
“真正的”HTML 调试，在您所说的意义上，在技术上是不可能的，因为 HTML 用户代理(网络浏览器)不需要以特定顺序呈现 HTML 元素，也没有类似的东西像“语句”一样的原子执行单元。
例如，在渲染表格时，用户代理是否应该为每个 <tr> 保留空间？在渲染他们的 child 之前 <td>s (广度优先)？或者它应该渲染每个 child <td>每个 <td>s child 等等(深度优先)？实际上，用户代理会进行各种猜测以尝试尽快呈现页面。换句话说，不能保证调试顺序将匹配实际渲染顺序，也不应该有。
HTML 在这个意义上可以被认为是一种声明性语言，因为它指定应该做什么(根据规范呈现的页面)，但没有具体说明如何做(确切地说是将元素呈现到屏幕的顺序)。通常，最好假设所有事情同时发生，尽管 W3C does give some tips关于加速<table>基于用户代理应该呈现方式的呈现 <table>元素。
IMO，webdev 工具栏和 Firebug 是我们拥有的最好的，我们可以在其中编辑/禁用特定的 HTML 元素和 CSS 规则。
关于html - 真正的 HTML 调试可能吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/387183/