W3C home > Mailing lists > Public > public-html@w3.org > October 2009

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 14 Oct 2009 09:48:41 -0700
Message-ID: <63df84f0910140948g7bb1597cuc8fec2120fc66d0@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC