DOM construction and script execution

P

Peter Michaux

Hi,

In the following snip of and HTML page, is there a specification
guarantee that the foo element will be parsed and available as part of
the DOM by the time the script executes? That is, could this error in a
standards-compliant browser?

<p id="foo">foo</p>

<script type="text/javascript>
var foo = document.getElementById('foo');
</script>

This seems to be very common practice. If this is not a standard then
perhaps this is a de facto standard that all browsers honour?

Thank you,
Peter
 
E

Evertjan.

Peter Michaux wrote on 27 jan 2007 in comp.lang.javascript:
In the following snip of and HTML page, is there a specification
guarantee that the foo element will be parsed and available as part of
the DOM by the time the script executes? That is, could this error in a
standards-compliant browser?

Methinks there are NO standards-compliant browsers yet.
There never will be,
as [long as] standards are something to aim at.
<p id="foo">foo</p>

<script type="text/javascript>
var foo = document.getElementById('foo');
</script>

This seems to be very common practice. If this is not a standard then
perhaps this is a de facto standard ...

It is not an standars per se.

foo will not be part of the DOM,
but is a javascript variable pointing to a DOM element,
[perceivesd by javascript as being an object, I think].

.... that all browsers honour?

No, not "all".
There always will be browsers, like very old versions, that will not,
but be assured that most modern ones and most ones audience volume wize do.
 
P

Peter Michaux

<p id="foo">foo</p>
<script type="text/javascript>
var foo = document.getElementById('foo');
</script>
This seems to be very common practice. If this is not a standard then
perhaps this is a de facto standard ...It is not an standars per se.

foo will not be part of the DOM,
but is a javascript variable pointing to a DOM element,
[perceivesd by javascript as being an object, I think].

Let me make that more clear with different strings.

<p id="myPara">asdf</p>

<script type="text/javascript>
var foo = document.getElementById('myPara');
</script>

So excluding browsers before IE5 and NN6 or without
document.getElementById, does anyone know of a browser that will error
when this JavaScript runs or that will not return the "myPara" element
when document.getElementById() is called?

Thanks,
Peter
 
E

Evertjan.

Peter Michaux wrote on 27 jan 2007 in comp.lang.javascript:
<p id="foo">foo</p>
<script type="text/javascript>
var foo = document.getElementById('foo');
</script>
This seems to be very common practice. If this is not a standard
then perhaps this is a de facto standard ...It is not an standars
per se.

foo will not be part of the DOM,
but is a javascript variable pointing to a DOM element,
[perceivesd by javascript as being an object, I think].

Let me make that more clear with different strings.

<p id="myPara">asdf</p>

<script type="text/javascript>
var foo = document.getElementById('myPara');
</script>

So excluding browsers before IE5 and NN6 or without
document.getElementById, does anyone know of a browser that will error
when this JavaScript runs or that will not return the "myPara" element
when document.getElementById() is called?

If you expect those old browser to be used occasionally,
you could test for the functionality:

<p id="myPara">asdf</p>

<script type="text/javascript>
if (document.getElementById('myPara')){
var foo = document.getElementById('myPara');

// rest of code

}
</script>
 
P

Peter Michaux

Peter Michaux wrote on 27 jan 2007 in comp.lang.javascript:


If you expect those old browser to be used occasionally,
you could test for the functionality:

<p id="myPara">asdf</p>

<script type="text/javascript>
if (document.getElementById('myPara')){
var foo = document.getElementById('myPara');

// rest of code

}
</script>

Thanks for the response but I think you've missed my question a
little. What I am trying to determine is if there is a de facto
standard behavior or if anyone has actually witnessed a browser where
my code snip would fail to perform (minus the obvious case where
document.getElementById() is not supported).

Peter
 
V

VK

What I am trying to determine is if there is a de facto
standard behavior

No, it is a non-standard behavior added by many browser producers
against DOM specs and own producers statements. This question was
posed a number of times, a couple of years ago I answered with quotes
from w3.org and MSDN - but I cannot find this post anymore, have to
search these dumpsters once over - some later. You cannot depend on
this behavior neither expect some consistent documented behavior
across UAs.

"Genetically" this behavior extension is of the same kind as
window.location.href(URL) added on IE - thus location used as a method
and not as a property. On a bigger scale it is another reflection of
JavaScript programming specifics where a great amount of developers
are not programmers as such. Respectively traditionally a great amount
of people programming on JavaScript have their own - sometimes very
strong - ideas of what and how should act and consecutively not giving
any sh** of how should it work by some stupid specs. At some point
this or that UA producer decides to save some nerves so simply adding
the most common mis-usages as extra features.

<http://groups.google.com/group/comp.lang.javascript/msg/
b6e5bfd65e6813af>
<quote>
Once again, for any robust solution the mantra is:

before page load event - document.write only
after page load event - DOM methods only
Ommm...
....
before page load event - document.write only
after page load event - DOM methods only
Ommm...
....

Repeat 10 times before go to bed and the life becomes much more easy
and your customers will stay happy, and money will stay in your house.

:)
</quote>

Anyone is welcome to live by this VK's mantra or call instead to the
spirit of good luck.
 
D

dd

I remember when this wouldn't work on some browsers,
I'm fairly sure it was limited to Netscape pre 6:

<script type="text/javascript>
document.write('<p id="myPara">asdf</p>');
var foo = document.getElementById('myPara');
</script>

That would fail because (I summized) that the document
writes were being buffered until the script tag closed. As
I recall (and it was a few years back so I might be fuzzy),
this solved the problem:

<script type="text/javascript>
document.write('<p id="myPara">asdf</p>');
</script>
<script type="text/javascript>
var foo = document.getElementById('myPara');
</script>

Closing and then re-opening the script tags caused the
pending document.writes to get put into the DOM. This
isn't what you're dealing with but I thought it might be
interesting to bring up.
 
D

dd

dd wrote on 28 jan 2007 in comp.lang.javascript:

In my post I wasn't quoting anything. By 'this' I meant
'this code below', indicated by the colon at the end of
the line :)

~dd
 
P

Peter Michaux

Hi dd,

I remember when this wouldn't work on some browsers,
I'm fairly sure it was limited to Netscape pre 6:

<script type="text/javascript>
document.write('<p id="myPara">asdf</p>');
var foo = document.getElementById('myPara');
</script>

That would fail because (I summized) that the document
writes were being buffered until the script tag closed.

I saw this very technique used just a few days ago and it made be
wonder what is going on. It seems like this script shouldn't work even
today. Very forgiving of the browser makers to enable this script.

As
I recall (and it was a few years back so I might be fuzzy),
this solved the problem:

<script type="text/javascript>
document.write('<p id="myPara">asdf</p>');
</script>
<script type="text/javascript>
var foo = document.getElementById('myPara');
</script>

Closing and then re-opening the script tags caused the
pending document.writes to get put into the DOM. This
isn't what you're dealing with but I thought it might be
interesting to bring up.

Definitely good to know. Much appreciated.

Thanks,
Peter
 
L

-Lost

dd said:
I remember when this wouldn't work on some browsers,
I'm fairly sure it was limited to Netscape pre 6:

<script type="text/javascript>
document.write('<p id="myPara">asdf</p>');
var foo = document.getElementById('myPara');
</script>

That would fail because (I summized) that the document
writes were being buffered until the script tag closed. As
I recall (and it was a few years back so I might be fuzzy),
this solved the problem:

<script type="text/javascript>
document.write('<p id="myPara">asdf</p>');
</script>
<script type="text/javascript>
var foo = document.getElementById('myPara');
</script>

Closing and then re-opening the script tags caused the
pending document.writes to get put into the DOM. This
isn't what you're dealing with but I thought it might be
interesting to bring up.

I wonder then, is this behavior that we should rely on? The first example worked in
Internet Explorer 6, Firefox 1.5.0.9, and Opera 9.10.

In my opinion that is "definitive" enough to warrant it being reliable, unless of course
some document somewhere states that it specifically needs to be removed.

-Lost
 
R

Richard Cornford

Peter Michaux wrote:
Let me make that more clear with different strings.

<p id="myPara">asdf</p>

<script type="text/javascript>
var foo = document.getElementById('myPara');
</script>

So excluding browsers before IE5 and NN6 or without
document.getElementById, does anyone know of a browser
that will error when this JavaScript runs or that will
not return the "myPara" element when document.getElementById()
is called?

I am not aware of any browser where an attempt to retrieve a reference to
an element from the DOM would fail following the HTML parser's parsing of
the element's mark-up (indeed the parsing of the opening tag would appear
to be sufficient).



However, what you can do with that reference, and what you can expect
from it, is extremely questionable. For example, your chances of getting
useful (or any) positioning and size information from the element at that
point are quite low.

Richard.
 
L

-Lost

Richard Cornford said:
Peter Michaux wrote:


I am not aware of any browser where an attempt to retrieve a reference to an element
from the DOM would fail following the HTML parser's parsing of the element's mark-up
(indeed the parsing of the opening tag would appear to be sufficient).

However, what you can do with that reference, and what you can expect from it, is
extremely questionable. For example, your chances of getting useful (or any) positioning
and size information from the element at that point are quite low.

Is it possible for you to provide an example of this theory?

I created one or two scenarios dealing with IMGs. Both retrieving their dimensions and
their position in the same context as I created them. So maybe I misinterpreted something
or am simply not enacting the correct tests.

-Lost
 
R

Richard Cornford

-Lost said:
Richard Cornford wrote:

Is it possible for you to provide an example of this theory?

It is not a theory. Try reading the - offsetWidth - properties of various
Elements in various browsers before the browser has finished parsing the
whole DOM and you will find some that have not assign values to those
properties (and some that have assigned provisional values during
progressive rendering, but those values may change when the whole DOM is
laid out).
I created one or two scenarios dealing with IMGs. Both retrieving
their dimensions and their position in the same context as I
created them. So maybe I misinterpreted something or am simply
not enacting the correct tests.

How many versions of how many browsers, with how many types of elements,
have you tried it with? And using what code?

Richard.
 
L

-Lost

Richard Cornford said:
It is not a theory. Try reading the - offsetWidth - properties of various Elements in
various browsers before the browser has finished parsing the whole DOM and you will find
some that have not assign values to those properties (and some that have assigned
provisional values during progressive rendering, but those values may change when the
whole DOM is laid out).

I suppose I should have said implementation, not theory. Anyway...

Well, initially we were talking about positioning and size information. (And I assumed
"size information" meant only a width or height property, no offsets.) I used the:
<script type="text/javascript>
document.write('<p id="myPara">asdf</p>');
var foo = document.getElementById('myPara');
</script>

....approach. In this fashion I was able to retrieve all attributes I set. Which included
inline styles, id, alt, width, height et cetera.
How many versions of how many browsers, with how many types of elements, have you tried
it with? And using what code?

I only tested in Internet Explorer 6, Opera 9.10, and Firefox 1.5.0.9.

After modifying this to a DOM-only representation, I was unable to retrieve valid offsets.
So, I understand now. Thanks.

-Lost
 
L

-Lost

I suppose I should have said implementation, not theory. Anyway...

Well, initially we were talking about positioning and size information. (And I assumed
"size information" meant only a width or height property, no offsets.) I used the:


...approach. In this fashion I was able to retrieve all attributes I set. Which
included inline styles, id, alt, width, height et cetera.


I only tested in Internet Explorer 6, Opera 9.10, and Firefox 1.5.0.9.

After modifying this to a DOM-only representation, I was unable to retrieve valid
offsets. So, I understand now. Thanks.

OK, I made a mistake. I was setting the width and height to '32px', not 32. When I
initially had that offsetWidth gave me *very* strange results.

var body_obj = document.getElementsByTagName('body')[0];
var img_obj = document.createElement('img');
img_obj.id = 'img1';
img_obj.src = 'loading.gif';
img_obj.alt = 'loading...';
img_obj.width = 32;
img_obj.height = 32;
body_obj.appendChild(img_obj);
var img = document.getElementById('img1');
document.write('<br />' + img.offsetWidth);
document.write('<br />' + img.width);

Once I changed width and height, offsetWidth and width were both available and accurate
with or without me explicitly setting the width and height attributes.

I call that directly within the BODY and in one SCRIPT context. I may have done this
incorrectly or may not understand if the HTML DOM has finished loading, but I thought it
was accurate. For lack of better understanding...

Thanks.

-Lost
 

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

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,596
Members
45,139
Latest member
JamaalCald
Top