On Sat, Jan 03, 2015 at 10:34:02AM -0500, Karl Dahlke wrote:
> My next project, which is not a major redisign,
> but more like filling in some holes,
> is to fix tag.innerHTML = "foobar", in js.
> This never really worked properly, never.
> It injects html into the page, after it is parsed,
> but my parsing software in html.c was built to be a one time thing,
> so there is some work to do here.
> I use to get around this by dumping the injected html into another buffer
> and rendering it there, but that is ugly.
> It belongs where it belongs, under the specified tag
> on the current page.
> And for calls to document.write() after browse, I use to do the same thing,
> dump the html somewhere else and parse it in a separate window.
> This is illustrated by line 3 in browsed jsrt, the timer, fire it and
> watch what it does, ugly.
> It should just append that (rendered) html to the current buffer.
> Both issues are related, and I am making a series of small foundational
> changes that will let me approach this one.

That's good. It'll be nice to get this sorted,
and hopefully it may make some things work more as expected (I'm not sure what
currently happens if js expects the inner html to be present in the current
page, but that'll no longer be an issue hopefully).

What kind of "foundational changes" are being made,
and will the multi-pass rendering logic be able to also handle other js-made
dom changes or is it going to be more like altering the html string in memory
then re-rendering that?
In addition, will the dom be altered by the presence of this html whilst the script is
running or will the script run then the new html be parsed and linked in?
I'd think the first is the expected behavior, but I'm not sure.

Cheers,
Adam.