readystatechange事件有一个名为"interactive"的状态，这听起来像是浏览器正在预先阻止交互式事件。这在某个地方标准化了吗？细节是什么？
我的意思是，如果浏览器不推迟/推迟或阻止这些事件，那么Javascript附加事件处理程序将始终存在竞争条件，除非Javascript与HTML混合(要么具有onclick等属性，要么Javascript自己生成整个元素(。
示例：浏览器加载一个巨大的页面可能已经使DOM的一部分对用户可见(当然可能会发生更改(，甚至还没有完成HTML的下载。如果用户点击了什么东西怎么办？该事件会被忽略、立即交付还是稍后执行？我希望它稍后会在取消阻止时生成并路由事件对象，而不是在单击时--忽略也是可以的
这听起来像是浏览器正在预先阻止交互式事件
不，听起来不是这样的，interactive这里只意味着我们可以安全地与文档交互：它的标记已经完全解析，DOM已经完全准备好了，现在它是交互式的。
没有任何与UI事件的链接，用户代理可以在不处理任何UI事件的情况下实现规范的这一部分(想想无头浏览器(。
在创建文档之前，其浏览器上下文将已经设置了代理，并且其事件循环正在运行
因此，即使在创建文档之前，事件循环也可以接收UI事件，尽管我认为在文档之外没有任何东西可以从发送。
至于何时调度这些事件，我认为这里存在一些互操作问题，但理论上，HTML解析应该是同步的，这些事件应该异步调度
不太确定UI事件，但至少有一些网络事件，如load，在Webkit浏览器中进行多年的完全解析之前是同步发送的
事件一开始就被阻止了吗？不可以。即使在主页加载期间，页面也是"交互式"的，所以我确实认为interactivereadyState用词不当。事件将"像往常一样"被激发，如果处理程序花费太多时间，事件可能会堆积起来。
网络处理可能是在Javascript执行1的同时进行的，但HTML解析不是。HTML解析的进步几乎就像Javascript运行队列上的一项任务：要么解析HTML，要么执行Javascript，如果Javascript不屈服，就不会解析更多的HTML。
Chrome和Firefox的优先级处理方式不同：例如，Chrome会在进一步解析HTML之前一致地安排事件处理，而Firefox似乎经常(但并不总是(在安排下一个事件处理程序之前解析缓冲的HTML。
而这一切都发生在document.readyState处于loading时--我在浏览器控制台和手工制作的服务器上观察到了这一点，在进入一个循环之前，它慢慢地发出带有内联脚本部分的简单HTML，在这个循环中，它在睡眠后发送<p>...元素，也就是说，它从未完成服务。
摘要：readyState === 'interactive'只不过是"主页完成解析"。
1其他限制照常适用：例如立即<脚本>在进一步解析之前执行…