Grant Wagner wrote:[color=blue]
> DU wrote:
>
>[color=green][color=darkred]
>>>It's a bad idea to do:
>>>
>>>var newWindowReference = window.open(...);
>>>newWindowReference.document.write(...); // or[/color]
>>
>>Don't you have to open the document and close it? Like
>>newWindowReference.document.open();
>>newWindowReference.document.write(...);
>>newWindowReference.document.close();
>>" 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.[/color]
>
>
> It's still a bad idea for the reason I gave. Attempting to do:
>
> newWindowReference = window.open(...);
> // newWindowReference.document may not exist yet![/color]
Yes, I agree with you on this. The window may have been created while
the document may not be loaded and referencible in the memory.
[color=blue]
> newWindowReference.document.open();
> newWindowReference.document.write(...);
> newWindowReference.document.close();
>
> will fail at least some of the time, in some browsers.
>[/color]
I agree.
[color=blue]
> newWindowReference = window.open('javascript
: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?
>[/color]
No. Of course not. I was merely indicating that one need to open(), and
then close() the writing of the string into the document. When people
don't do that, the browsers (at least Mozilla-based browsers) are in a
state of perpetual downloading, expecting, waiting for the download to
stop: they are in a state of waiting.
[color=blue]
>[color=green][color=darkred]
>>>window.newWindowReference = window.open(...);[/color]
>>
>>newWindowReference is already a type window (return value of the
>>window.open() call); so it is not needed to prefix it with window.[/color]
>
>
> I included it to indicate that newWindowReference is explicitly a member of the current
> window.[/color]
Ok. So, this was for instructional purposes.
I prefer to do this rather than having variable assignments that may or
may not[color=blue]
> be "global" depending on whether it was declared with "var" somewhere earlier in the
> same code block.
>[/color]
Ok.
[color=blue]
>[color=green][color=darkred]
>>>function callBack() {
>>> if (document.getElementById) {
>>> var theDiv =
>>>window.newWindowReference.document.getElementBy Id('preview');
>>> if (typeof theDiv.innerHTML == 'string') {[/color]
>>
>>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"> </div>
>>is more manageable from a script perspective.[/color]
>
>
> typeof theDiv.innerHTML 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.getElementById('preview');
> 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".
>
>[color=green][color=darkred]
>>> theDiv.innerHTML = 'some text';[/color]
>>
>>Also possible is branching DOM 3 textContent and innerText and/or
>>childNodes[0].nodeValue assuming
>><div id="preview"> </div>[/color]
>
>
> 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.[/color]
Yes, that is fair to say, especially when the node is a document
fragment. But here, it is a simple text node and there are alternatives
(IE-specific and W3C DOM) for such specific case.
If you have a string[color=blue]
> 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.
>[/color]
One negative drawback of this is that users do not learn, understand
what is the DOM, how to handle (create, insert, remove, replace, etc.)
DOM tree node. They hinder their long term understanding of DOM;
eventually (it's already the case IMO) they over-use or mis-use innerHTML.
[color=blue]
> 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 <gwagner@agricoreunited.com>
> comp.lang.javascript FAQ -
http://jibbering.com/faq
>[/color]
Mozilla implemented innerHTML for the reasons (simplicity, ease of use)
you give.
DU
--
The site said to use Internet Explorer 5 or better... so I switched to
Mozilla 1.7.3 :)
