- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 22 Jun 2010 01:48:48 -0700
- To: HTML WG <public-html@w3.org>
- Cc: Henri Sivonen <hsivonen@iki.fi>, Eric Seidel <eric@webkit.org>
In step 8 of <http://www.whatwg.org/specs/web-apps/current-work/#running-a-script>, the spec adds external scripts to the <http://www.whatwg.org/specs/web-apps/current-work/#set-of-scripts-that-will-execute-as-soon-as-possible>. When the fetching algorithm is complete, the spec invokes <http://www.whatwg.org/specs/web-apps/current-work/#executing-a-script-block>. However, that sequence of steps does not save the current insertion point (among other things), which seems very unlikely to be compatible with the web. In implementing the above requirement in WebKit, we assumed the spec meant to invoke <http://www.whatwg.org/specs/web-apps/current-work/#scriptTagParserResumes>, which saves the current insertion point (and does other things that would make sense at that point). Should we change the spec to say this explicitly? In double-checking our work with the HTML5 parser implementation in Minefield, we noticed that Minefield handles this case slightly different (likely due to the spec ambiguity above). In particular, when the page calls document.write from the load event of a script tag, Minefield seems to believe there is no current insertion point and blows away the entire document: http://trac.webkit.org/export/LATEST/trunk/LayoutTests/fast/tokenizer/write-on-load.html Under the above interpretation of the spec, the load event shares the same insertion point record as the external script itself, resulting in the numerals in that test being printed in order from 1 to 7. That behavior appears to match the legacy WebKit and Firefox behavior and is, therefore, likely compatible with the web. Adam
Received on Tuesday, 22 June 2010 08:49:40 UTC