- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 14 Oct 2009 09:48:41 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: "public-html@w3.org WG" <public-html@w3.org>
On Wed, Oct 14, 2009 at 1:18 AM, Henri Sivonen <hsivonen@iki.fi> wrote: > On Oct 14, 2009, at 10:19, Jonas Sicking wrote: > >> On Tue, Oct 13, 2009 at 11:44 PM, Henri Sivonen <hsivonen@iki.fi> wrote: >>> >>> I'm trying to limit code complexity and bad re-entrancy due to >>> document.write(). I've been thinking I'd undefine the insertion point >>> whenever the parser operates on the DOM (except when the parser runs a >>> script from </script>). This insertion point undefining would override >>> the >>> current cases where the spec defines the insertion point. That is, the >>> insertion point would be undefined when the SVG load event is on the call >>> stack even if the document was created with document.open() and thus had >>> the >>> insertion point always defined per current spec. >>> >>> Are there cases other than </script> and the SVG load event that cause >>> scripts to execute while the HTML parser (innerHTML parser excluded) is >>> on >>> the call stack? (As far as I can tell, timeouts and XBL bindings only run >>> from the event loop, and if there's a nested event loop for sync XHR, the >>> nested event loop must have been created by </script> or the SVG load >>> event.) >> >> XBL constructors I'm pretty sure can run. Though maybe that's an XBL1 >> thing. Haven't gotten that far in the XBL2 implementation yet. And in >> Gecko we also dispatch DOMLinkAdded and DOMLinkRemoved events whenever >> <link> elements are added/removed. Though I suspect that no content >> relies on that (the events were intended for internal use only when >> they were added I think). >> >> There's *possibly* also change events being dispatch on form elements >> when we restore form values if you go "back" to a page. > > Would it be OK to undefine the insertion point (i.e. make document.write() > blow away the page if called) in all these cases including nested event > loops created by these? In face, I would say it's preferable :) / Jonas
Received on Wednesday, 14 October 2009 16:49:36 UTC