DU wrote:
It's a bad idea to do:
var newWindowRefere nce = window.open(... );
newWindowRefere nce.document.wr ite(...); // or
Don't you have to open the document and close it? Like
newWindowRefere nce.document.op en();
newWindowRefere nce.document.wr ite(...);
newWindowRefere nce.document.cl ose();
" Closes a document stream opened by open() and forces rendering."
http://www.w3c.org/TR/2003/REC-DOM-L...ml#ID-98948567
There is a problem when not closing the document in Mozilla-based
browsers and possibly other browsers as well.
It's still a bad idea for the reason I gave. Attempting to do:
newWindowRefere nce = window.open(... );
// newWindowRefere nce.document may not exist yet!
newWindowRefere nce.document.op en();
newWindowRefere nce.document.wr ite(...);
newWindowRefere nce.document.cl ose();
will fail at least some of the time, in some browsers.
newWindowRefere nce = window.open('ja vascript:opener .someString', ...);
is a better and more reliable way to do this. Of course, the reliability of any of this
depends on JavaScript being enabled, the implementation supporting window.open(), any
popup blocking mechanism the end-user may have and where and how the new window appears
(as a tab in a tabbed browser window?). But, even given all that, do you want to make
it even _more_ unreliable by attempting to access a not-yet-created document of the new
window?
window.newWindo wReference = window.open(... );
newWindowRefere nce is already a type window (return value of the
window.open() call); so it is not needed to prefix it with window.
I included it to indicate that newWindowRefere nce is explicitly a member of the current
window. I prefer to do this rather than having variable assignments that may or may not
be "global" depending on whether it was declared with "var" somewhere earlier in the
same code block.
function callBack() {
if (document.getEl ementById) {
var theDiv =
window.newWindo wReference.docu ment.getElement ById('preview') ;
if (typeof theDiv.innerHTM L == 'string') {
The problem I see here (I might be wrong) is that *as written*, the
innerHTML value of that div id="preview" will be null: there is no
string when writing
<div id="preview"></div>.
Generally speaking, the structure
<div id="preview">&n bsp;</div>
is more manageable from a script perspective.
typeof theDiv.innerHTM L will always be "string" if innerHTML is supported. In your
example (an empty <div>):
<body onload="test(); ">
<div id="preview"></div>.
<script type="text/javascript">
function test() {
var p = document.getEle mentById('previ ew');
alert('[' + p.innerHTML + '];' + typeof p.innerHTML);
}
</script>
IE 6, Mozilla 1.0.2, Mozilla 1.7.3, Firefox 1.0PR, Opera 7.54 show an empty string and
typeof "string". Although I will acknowledge that there may exist some user agents that
support the setting and retrieving of innerHTML, where an empty element returns null
and typeof "object".
theDiv.innerHTM L = 'some text';
Also possible is branching DOM 3 textContent and innerText and/or
childNodes[0].nodeValue assuming
<div id="preview">&n bsp;</div>
The problem I have with the W3C standard is that constructing a node tree for even
mildly complex HTML is extremely tedious and fraught with peril. If you have a string
containing unknown HTML that is moderately to highly complex, innerHTML seems the way
to go. Hand the string to the browser, let it render it. Parsing it (probably badly)
and attempting to construct a node tree out of it is simply duplicating the effort
already put into writing the browser and is better left to the user agent (via
innerHTML). After all, it _knows_ how to do that, it had to do it for the entire page
in the first place.
On the other hand, if I am adding <form> elements or inserting additional fixed, known
content, I typically use the W3C methods.
I really wish innerHTML had been made part of the standard, considering it is probably
extremely easy to implement from the user agent developers' perspective.
--
Grant Wagner <gw*****@agrico reunited.com>
comp.lang.javas cript FAQ -
http://jibbering.com/faq 
