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

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.

/ Jonas

Received on Wednesday, 14 October 2009 07:20:01 UTC