Re: [Edbrowse-dev] Parallel versions of js access functions

[Kevin Carhart <kevin@carhart.net>]

This is terrific.  I'm relieved to hear that it
may be less bad than originally thought.

I had a thought which may be moot now but here
is a graf about it just in case.  I was wondering
about JS-based parsing from a pluggable piece of
JS that is a utility function providing a service.
Leave it on the JS side.  At the time of innerHTML,
who knows, the script could have another 800 steps
ahead, which will obliterate the tags in the
innerHTML long before the next time the user is
working with edbrowse buffers.   The tags in the
innerHTML could be inherently intermediate.
Just a way of manifesting an assert() of some
concept, which populates a boolean, which the
code uses for something else.  edbrowse
rendering isn't going to be
enlisted for a while yet, so I thought maybe
on balance, while it would be yet another component,
maybe it would be less of redesign for JS to
call a JS-based parser and keep working.
The moment of the side effects call remains
the time and place when we consolidate what
edbrowse needs to process.

Is my impression even accurate in the
first place?  And even if so, in the
intervening time I think you've solved it!

> Kevin do you think document.write is similar to innerHTML
> in that it is suppose to take effect immediately?
> html is parsed and js objects created,
> and made available by the next line of the running javascript?

I am almost positive that is true.  I found the following
in the bowels of the yellowpages.com code without needing
to look very hard.
frameDoc.open();
frameDoc.write(div.innerHTML);
var $bingImg=$(frameDoc).find("#minimap > img");
...
frameDoc.close()

I'm making some assumptions that this cherry-picked
piece of JS is relevant, but I think it represents
what you're asking about and if it happens to be
used in my guinea pig website, it is probably
something that gets relied on and used
all over the place.

K