[Edbrowse-dev] document.write atomic

[Edbrowse-dev] document.write atomic

[Karl Dahlke]

This is mostly aimed at Kevin, our resident expert in html and js in the wild,
but I thought I'd post it here for all to consider.
A pivotal question influencing design is this.
Is document.write immediate and atomic?
I asked before and Kevin thought it was.
That as soon as I see document.write(string) I am to parse that html
and create the implied js objects etc etc.
And yet, I'm pretty sure I've seen websites,
I know I've written websites, wherein the write is not atomic,
and should not be parsed in isolation.
Example:

document.write("<P><a href=url>");
document.write("click on this baby");
document.write("</a>");

I'm pretty sure I've seen things like that, what do others say?
Parsing each string as an individual html document would not work.
The first string would degenerate to <a href=url></a>,
and the second would just be text not enclosed in a hyperlink,
and the third would be a close tag without an open tag and discarded.
That won't work.
If document.writes are as above,
then my current design is correct and should not change.
Build the writes up in a buffer and then parse the write buffer
after the script returns.
This is completely separate from the innerHTML strategy,
foo.innerHTML = string;
The string is the whole html in its entirety,
is to be parsed at this time,
and the js objects immediately available by the next line of javascript.
I just don't think document.write works that way,
but I have to suspend all coding until I have a confident answer to this question.

Karl Dahlke

Re: [Edbrowse-dev] document.write atomic

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

On Mon, Sep 28, 2015 at 11:20:06PM -0400, Karl Dahlke wrote:
> This is mostly aimed at Kevin, our resident expert in html and js in the wild,
> but I thought I'd post it here for all to consider.

Yeah Kevin should have the final say on this since he's seen more of the
internals of running websites.

> A pivotal question influencing design is this.
> Is document.write immediate and atomic?
> I asked before and Kevin thought it was.
> That as soon as I see document.write(string) I am to parse that html
> and create the implied js objects etc etc.
> And yet, I'm pretty sure I've seen websites,
> I know I've written websites, wherein the write is not atomic,
> and should not be parsed in isolation.
> Example:
> 
> document.write("<P><a href=url>");
> document.write("click on this baby");
> document.write("</a>");
> 
> I'm pretty sure I've seen things like that, what do others say?

I looked this up and the closest "answer"
I could find was the examples and explanation here:
<http://www.w3schools.com/jsref/met_doc_write.asp>

From this it looks like html is shoved into the document prior to parsing then
the document is reparsed in the loading case.
In the post-loading case it looks as if we need to replace everything in the
document with the document.write output. Same goes for document.writeln I guess.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] document.write atomic

[Kevin Carhart]

Crud.  To be honest, I really don't know.

It's true - your apples example shows document.write
building segments that don't make any sense on
their own.

It seemed to me that in my other example, well,
you have to interpret the jquery syntax to understand
it, but the point is that it says 'write', which
pumps in whatever is in div.innerHTML, and then
immediately afterwards, calls jquery's own
find() method on that html.

frameDoc.write(div.innerHTML);
var $bingImg=$(frameDoc).find("#minimap > img");

But of the two examples, I think you're correct,
because the use of jquery is probably a confound
whereas your apples landing page uses vanilla javascript.

The only thing that bothers me about taking sites.help.org
as a precedent is that they appear to be the ethically
challenged portion of the internet, and this might suggest
that they are less than technically airtight too.  For
instance, they make an iframe out of:

www.youtube-nocookie.com

Which is like a phishing trick to deceive you.

But does questionable intent necessarily mean that
their javascript was bad?!  Not necessarily but 
anyway, I will scout around a little more tomorrow
just to corroborate with a little more usage.

Kevin