Re: Undefining insertion point when the parser touches the DOM (except </script> and fragment parser)

On Oct 14, 2009, at 10:19, Jonas Sicking wrote:

> On Tue, Oct 13, 2009 at 11:44 PM, Henri Sivonen <>  
> 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 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?

Henri Sivonen

Received on Wednesday, 14 October 2009 08:18:54 UTC