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

On Wed, Oct 14, 2009 at 9:48 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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 :)

That should say "In fact...". Sorry about spam.

/ Jonas

Received on Wednesday, 14 October 2009 16:50:05 UTC