这就是Aardvark，Web开发人员，Firebug等许多工具的原因。
但是，当我看到Gecko Reflow Videos他们只是吹了我的头脑。
那么我的问题是，是否可以真正地调试html(逐步通过每个元素)？还是靠近呢？
我一直在做的很多事情是使用Aardvark和删除元素，但Aardvark有其“背景”和相同大小的元素的问题，并且无法对其进行定位。
更新：我一直在努力为这个问题写一个很好的更新，因为它让我更多地考虑了这个问题。但由于英语不是我的主要语言，它是艰难的。
在过去的几年中，一直以来，浏览器的任务是与标准兼容。当他们越来越接近这个目标时，我们应该考虑在浏览器兼容性最小的时候我们可以真正创建什么，如果我们可以利用这些技术可以使渲染页面更快。
我们可以将过去几十年看作是HTML / CSS的早期阶段，其主要目标就是让事情发挥作用。现在我们应该寻找加速当前流程的技术。一个例子是在上面的视频中，Gecko引擎正在运行代码两次。这是为什么？还有其他的事情，它做不必要的事情(即使他们工作和兼容)
这是明确需要测试以确认的东西，因此我原来的一个真正的调试器的问题。
解决方法
因为没有HTML用户代理(Web浏览器)以特定顺序呈现HTML元素的要求，也没有什么像原子单位那样，“True”的HTML调试在某种意义上说，在技术上是不可能的的执行就像一个“声明”。
例如，当呈现表时，如果用户代理为每个< tr>保留空间在呈现他们的孩子< td>(广度优先)之前？或者它应该渲染每个孩子< td>和每个< td>的小孩等等(深度优先)？在实践中，用户代理使各种猜测尽可能快地呈现页面。换句话说，不会保证调试顺序与实际的渲染顺序相匹配，也不应该存在。
HTML可以被认为是这种意义上的声明性语言，因为它指定了应该做什么(页面呈现为规范)，但不完全如何(完全是为了将元素呈现给屏幕)。一般来说，最好假设一切都发生在一起，尽管W3C does give some tips在加速< table>基于用户代理如何呈现< table>元素。
IMO，webdev工具栏和Firebug是我们最好的，我们可以在其中编辑/禁用特定的HTML元素和CSS规则。
