End of .html parsing ?

J

Jorge

Consider this:

<html>
<head>
<script>
setTimeout(function f1 () {
alert(".html parsing done.");
}, 0);
</script>
</head>
<body>
</body>
</html>

Is it safe to assume that f1 will be run, and that it won't run until
the parsing has ended ?

TIA,
 
R

rf

Jorge said:
Consider this:

<html>
<head>
<script>
setTimeout(function f1 () {
alert(".html parsing done.");
}, 0);
</script>
</head>
<body>
</body>
</html>

Is it safe to assume that f1 will be run, and that it won't run until
the parsing has ended ?
Click to expand...

No.
 
S

SAM

Le 9/27/09 2:49 PM, rf a écrit :
No.
Click to expand...

No?

Then try :

<html>
<head>
<script>
var t1, t2;
setTimeout(function f1 () {
t1 = new Date();
alert(".html parsing done.");
document.getElementById('t').innerHTML = t1*1;
}, 0);
alert('Am I the first?');
</script>
</head>
<body>
<h1>title</h1>
<script>
t2 = new Date();
</script>
<p>does the JS fired before to see this "title" above ?</p>
<h2>Annswer :</h2>
<pre>
<script>
document.write("time spent between parsing :\nthe setTimeout (date:"+
(t1*1)+")\nthe tilte (date:"+(t2*1)+")\ntotal = "+(t2-t1));
</script>
Time t1 = <span id="t">? ? ?</span>
</pre>
</body>
</html>


Where I think that we can now say that Jorge is right.
 
S

SAM

Le 9/27/09 3:48 PM, Hans-Georg Michna a écrit :
Jorge,

it is safe to assume that f1 will be run, but if by "parsing"
you mean "rendering to screen", then no, it will usually run
before the parsing has ended, provided the web page is a bit
bigger than the empty example above.
Click to expand...

I think Jorge speak of 'parsing'.
About 'run' I think he does a difference with 'fire'

The setTimeout fires as soon as it's parsed (normal, no?)
but the f1 will rum at that moment +0
that's to say after complete parsing of the file

.... if I had well tested (?) (only in Fx.3)
 
J

Jorge

Jorge,

it is safe to assume that f1 will be run, but if by "parsing"
you mean "rendering to screen", then no, it will usually run
before the parsing has ended, provided the web page is a bit
bigger than the empty example above.
Click to expand...

I meant parsing (of the DOM tree) not rendering (*)
In all browsers I know the rendering to screen is totally
invisible to the JavaScript subsystem, and there is no direct
way to find out what the browser's rendering engine is doing or
has done. Also they usually don't render to screen before the
JavaScript code has finished running, perhaps with the exception
of Opera. In other words, JavaScript execution has a higher
priority than rendering to screen.

Have a look athttp://winhlp.com/node/633for a possible way to
wait until the rendering to screen is complete. You can copy the
code and use it without understanding it fully, but test it
thoroughly in your application.
Click to expand...

setTimeout(, 20ms) in order to allow the rendering to finish ?
Sorry but no, I don't think that's the way it works.
Although that might be true for IEs (I don't know) it's not so in
Safari, Chrome FiereFox nor Opera.
But note that you normally need to worry about this question
only when you have both a considerable amount of calculation to
do and a considerable amount of DOM to render. If any of the two
is small, no worries.
Click to expand...

I was thinking about a dom-ready callback, after parsing but before
onload. I've written a test page and this setTimeout(f, 0); technique
is looking quite good to me: see: http://jorgechamorro.com/cljs/083/index6.html

(*)related and interesting :

Cheers,
 
J

Jorge

No. That's easy to disprove by adding a delay somewhere on the page, for
example with PHP:

<body>
  <p>line1</p>
  <? flush(); sleep(2); ?>
  <p>line2</p>
</body>

The alert will show up long before "line2" becomes visible. I've only
tested this with FF3, but one browser is all it takes to answer "is it
safe to assume" :)
Click to expand...

Could you please put this online somewhere for me to test it too ?

Thanks !
 
S

SAM

Le 9/27/09 5:05 PM, Stefan Weiss a écrit :
No. That's easy to disprove by adding a delay somewhere on the page, for
example with PHP:

<body>
<p>line1</p>
<? flush(); sleep(2); ?>
<p>line2</p>
</body>

The alert will show up long before "line2" becomes visible. I've only
tested this with FF3, but one browser is all it takes to answer "is it
safe to assume" :)
Click to expand...

I tried that and did a mistake as all appears in one time and before the
alert (or very very close after).
(Fx.3 too)

Anyway I don't see what that can reveal except the wait on server.
 
L

Luuk

Jorge schreef:
Consider this:

<html>
<head>
<script>
setTimeout(function f1 () {
alert(".html parsing done.");
}, 0);
</script>
</head>
<body>
</body>
</html>

Is it safe to assume that f1 will be run, and that it won't run until
the parsing has ended ?

TIA,
Click to expand...

i think readyState should be used for this

w3.org:
http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/

msdn.microsoft.com:
http://msdn.microsoft.com/en-us/library/ms534359(VS.85).aspx

i think it will work on other browsers than IE too...
 
T

Thomas 'PointedEars' Lahn

Hans-Georg Michna said:
For that there is the window.onload event or, better, if you use
jQuery,
Click to expand...

.... which you shouldn't ...
the jQuery(document).ready(fn), where fn is a callback
function that is called when the DOM is completely built and
ready to be traversed.
Hardly.

The short form of that is what you often see: $(fn);
Click to expand...

.... which is equally, if not more stupid, as it unnecessarily wraps a
Function object in another object, inefficiently, just to call it.
jQuery works a bit of magic here, but if you want to rely on
pure JavaScript, use window.onload, perhaps with a little
additional checking whether everything is completely there.

https://developer.mozilla.org/en/DOM/window.onload
Click to expand...

Neither is jQuery any kind of magic (rather the opposite if you look into it
and have any clue about what you are doing), nor is `window.onload' "pure
JavaScript"; it is a proprietary property of an object provided by some host
environments that should not be used, for there is the fully
standards-compliant and backwards-compatible `onload' attribute of the
`body' element that provides the very same functionality in a much more
reliable way.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Hans-Georg Michna said:
Jorge said:
<html>
<head>
<script>
setTimeout(function f1 () {
alert(".html parsing done.");
}, 0);
</script>
</head>
<body>
</body>
</html>

Is it safe to assume that f1 will be run, and that it won't
run until the parsing has ended ?
Click to expand...
[...]
it is safe to assume that f1 will be run, but if by "parsing"
you mean "rendering to screen", then no, it will usually run
before the parsing has ended, provided the web page is a bit
bigger than the empty example above.

In all browsers I know the rendering to screen is totally
invisible to the JavaScript subsystem, and there is no direct
way to find out what the browser's rendering engine is doing or
has done. [...]
Click to expand...

However, you have evaded the question. Parsing (tokenizing the source code)
must happen before rendering (painting a graphical representation of tokens
that have or generate a graphical representation).

Insofar it stands to reason and can be shown that a `script' element's
content is going to be executed when the `script' element and its previous
siblings have been parsed (but not necessarily rendered, or the
corresponding DOM objects created). So it is possible to determine when
parsing has (nearly) finished; for example, code in a `script' element that
is the last child of the `body' element (ignoring white-space text nodes)
will execute then and not before. (However, with the W3C DOM the `load'
event appears to be best suited to determine that moment more exactly.)

Therefore, if `f1' is called at all (the markup is not Valid, setTimeout()
is not defined a built-in method of the Global Object, the Function instance
reference may not be supported, 0 may not be supported for the second
argument), it is going to be called almost immediately after the `script'
element has been parsed (as 0 would be the approximate number of
milliseconds after the setTimeout() call after which `f1' would be called),
and the correct answer to the OP's question must be "no" (it is not safe to
assume [the opposite]). After all, the `head' element is parsed before the
`body' element, and this `script' element is a child of the `head' element.

But, as you say correctly, in a standard-security environment it is not
possible *in general* to determine with scripting when *rendering* has
finished; for example, the `load' event specification does not define if all
referred image resources have been downloaded and rendered when the event
occurs. There are special cases, though, where it can be determined with
scripting whether rendering was finished.


PointedEars
 
S

SAM

Le 9/27/09 6:10 PM, Stefan Weiss a écrit :
The point is that the alert box appears before HTML "parsing has ended".
Click to expand...

Not in my tests.
If you don't see the effect, maybe it's browser dependent; I used FF3.0
on Linux for testing.
Click to expand...

FF3.014 (cache disabled)
on iMac-Intel 10.4.11
and its server [Apache/1.3.41 (Darwin) PHP/5.2.4].
@Jorge, I've put the example page online so you can try it out:

<http://foo.at/paste/2009/test_delayed.php>
Click to expand...

Same config as given above :
Line 1
then alert
then line 2
Right as you said.

Can we get your file in text ?
because mine didn't do that, display nothing, wait, then display all and
alert without possibility to see which one was really the first.
I tested it on my server Apache at home.
I uploaded it on free.fr ...
.... the php line seems there to do not be interpreted :-(

Notice that Safari with that url displays all together (lines and alert)
at end of delay.
To make it more noticeable, I increased the delay to 5 seconds.
Click to expand...

My file with delay 6 seconds, on server at home :
- FF.3 : white, wait, display all, alert (in this order, sure)
- Safari.3 : white, wait, display all together (window and alert)

My tested file in copy-paste :

<html>
<head>
<script>
setTimeout(function f1 () {
alert(".html parsing done.");
}, 0);
// alert('Am I the first?');
</script>
</head>
<body>
<h1>title</h1>
<?php flush(); sleep(6); ?>
<p>ligne test php</p>
<pre>
Time t1 = <span id="t"></span>
</pre>
</body>
</html>
 
J

Jorge

(...) Javascript might be
turned off.
Click to expand...

Sheesh ! Still advocating the good ol' form-comes form-goes web
model ?

Do you want to know a secret ?
In the very near future *nobody* will want a browser without a good
javascript engine under the hood.
 
B

Bart Lateur

Jorge said:
Consider this:

<html>
<head>
<script>
setTimeout(function f1 () {
alert(".html parsing done.");
}, 0);
</script>
</head>
<body>
</body>
</html>

Is it safe to assume that f1 will be run, and that it won't run until
the parsing has ended ?
Click to expand...

Well I often use this as an alternative to onWindowLoad. I've never
known it to fail.
 
B

Bart Lateur

Jorge said:
Sheesh ! Still advocating the good ol' form-comes form-goes web
model ?

Do you want to know a secret ?
In the very near future *nobody* will want a browser without a good
javascript engine under the hood.
Click to expand...

Wrong. Lots of people use NoScript, and only turn Javascript on for
domains they know, and trust.
 
B

Bart Lateur

Bart said:
Well I often use this as an alternative to onWindowLoad. I've never
known it to fail.
Click to expand...

Judging by the posts in the rest of this thread, I've just been lucky.
:)
 
O

Osmo Saarikumpu

Bart Lateur kirjoitti:
Wrong. Lots of people use NoScript, and only turn Javascript on for
domains they know, and trust.
Click to expand...

And then some, take me for example. I script kid around almost daily,
but still I surf with QuickJava extension that by (my) default disables
JavaScript (and Java). And that backed up with (blacklisting) YesScript,
in case I decide, to quote Jorge, to turn on my good javascript engine
under the hood.

I really hope that Jorge's vision about the future of the Web turns out
to be an illusion.
 
G

Garrett Smith

Hans-Georg Michna said:
s
Osmo,

I am convinced that JavaScript will gain even more widespread
acceptance in the very near future. I actually even like that,
but even if I didn't, I would have to adapt to it.

Just-in-time JavaScript compilers and new releases of the
language will be built into all major browsers. They will open
the floodgates to many new applications we may not even be able
to imagine right now. JavaScript may well supplant some other
technologies, like Flash.

I can only contribute a tiny example for a heavily
computing-intensive and not web- or Internet- or browser-related
program written in JavaScript, "Telly", at
http://winhlp.com/telly/ ,
Click to expand...

Warning: this is extremely intensive application that may cripple the
system it runs on.

which can serve as a simple speed
test. It merely uses the browser as its hardware-independent
platform.

Works best in Firefox right now, but does work in the other
major browsers, albeit more slowly. Haven't done any speed tests
with the allegedly compiling Google Chrome.
Click to expand...

It is not apparent what that web page is supposed to be doing.

Using Firefox 3.5, I see a few navigation links (those work), a dropdown
menu with "English" selected, a text input field, a button with "...".

It doesn't seem to do anything useful in the one browser you claim it
"works best" in.

View source reveals invalid XHTML served as text/html and jquery.js.
A fair assessment of the quality would probably be "junk".

Launching safari 4, I see:
| Change your telephone number into words you can use to dial.

Entering a phone number, Safari became unresponsive. Launching Task
manager, I see CPU at 60%, and Safari at nearly 1gb memory usage.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

What "might" I be doing wrong with this snippet? 6
How do I hide the modal after 5 seconds? 4
What's the correct behaviour ? 4
I'm about to get in trouble with the HTML <body></body> tags 10
Filename undefined for Blob ? 1
Script stops working when using variables to save time typing... 4
How to check the validation of js files or html files including js? 6
How to use PDF-lib and how to center each line of texts on the page? 1

Members online

Total: 44 (members: 1, guests: 43)
Robots: 431

Forum statistics

Threads
473,769
Messages
2,569,576
Members
45,054
Latest member
LucyCarper

Latest Threads

Top