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:49:12 -0700
Message-ID: <63df84f0910140949o716174a8y270d0e3ad30f0a4@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 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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:52 UTC