I'm practicing navigating the DOM with Javascript and running into an issue. I'm aware of cross site scripting is not allowed, but I have a question.
I can post the HTML code if need be, but for the moment had a simple question.
When I run
iframe_dom = document.getElementsByTagName('iframe')[0]
console.log(iframe_dom)
This is what's printed out (abbreviated version)
<iframe style="width:100%;height:100%;"> .... </iframe>
#document
<html>
<head>..</head>
<body>
<iframe>...</iframe>
That's what I expected. However, when I try to navigate the tree by putting in:
iframe_dom.iframe
undefined is returned.
If I've passed the body of iframe into a a variable, why can't I navigate the tree?
How is not entirely consistent across browsers, and if you're executing your script on load, it may not be available yet.
Check out the Plunker below. I built it based on this: http://xkr.us/articles/dom/iframe-document/
function getChildTitle() {
var oIframe = document.getElementsByTagName('iframe')[0];
var oDoc = (oIframe.contentWindow || oIframe.contentDocument);
if (oDoc.document) oDoc = oDoc.document;
console.log(oDoc.body.getElementsByTagName('h1')[0].innerHTML);
}
In short, from the iframe element, sometimes you want the contentDocument property, sometimes contentWindow property - depending on browser. Take whichever one exists (or isn't falsey, in the code). In some browsers you may need to use that object's document property.
http://plnkr.co/edit/cSRD0qh5kntYR6aS8f1H
Related
Are there any issues with code like the following?
document.documentElement.insertAdjacentHTML('beforeend', `
<div style="border: 5px solid pink">This content is outside the <body>, but both Firefox and Chrome render it fine.</div>
`)
Is this reliable? Or can there be issues in some browsers? From what I can tell, it is totally fine in Firefox and Chrome.
I can't find any information about this, but it seems to work.
EDIT:
The reason I found for using document.documentElement, is we can rely on the fact that document.documentElement seems to be always defined no matter when a <script>'s code runs.
However, document.body is sometimes null depending on when a <script>'s code runs.
For example, consider the following code using document.body. If you stick it in a .html file, then open it in your browser, you will see the message null.
<script>
alert(document.body)
</script>
Here's a live example: https://plnkr.co/edit/PkhHjSHi6esfrl32
Now consider this code:
<script>
alert(document.documentElement)
</script>
The message that you will see is [object HTMLHtmlElement] (or similar). Live example: https://plnkr.co/edit/nSxtGZzN8tU0hCbq
This means, that to write code using document.body, it takes more effort and requires more code.
To get the document.body version to work, we have to do something like the following:
<body>
<script>
alert(document.body)
</script>
</body>
Live example: https://plnkr.co/edit/7BcZDZX4jemhwfcV. Of course, it's not that much more code, but when following the principle of simplicity, it seems that document.documentElement leads to slightly simpler code.
In my tests so far, it seems to work just fine (anything outside the of the eventually-created <body> renders as a sibling to the body element.
What problems may placing DOM elements in document.documentElement cause, that I have not forseen?
by default scripts run synchronously just like normal code. In normal code this won't work
const b = a + 1; // ERROR! a is not defined
const a = 1;
Because a does not exist when b is trying to use it you'll get an error. HTML and scripts are exactly the same
<script>
document.getElementById('a').textContent = 'yo!'; // ERROR <div id="a"> is not defined
</script>
<div id="a"></div>
fails for exactly the same reason as the JavaScript example. <div id="a"> does not exist when the script runs
This explains your <body> issue. If you put the script before the <body> tag then it does not yet exist. If you put it after then it does.
So the simple answer is you can do whatever you want as long as the things you want to reference exist when you try to reference them.
As for adding to the root element, yes you can do that. You don't have to have a body tag. In fact Google even suggests leaving it out.
note: I said above scripts run synchronously by default. There are plenty of ways to make them run later. The modern way is with the defer keyword though that way requires the script to be in a separate file. An old and no longer recommended way is to use the load event using one of <body onload="someFunc()"> or window.onload = someFunc() or window.addEventListener('load', someFunc). In these cases the script actually runs immediately but then effectively sets a callback to be called when the rest of the page has finished loading. Most modern JavaScript no longer uses the load event and either puts the script after the stuff it needs to reference or uses defer. Also es6 modules always "defer"
note that <html> and <body> are special tags. The HTML element is always the root element whether you declare one or not. Also, both <html> and <body> will only have one element each regardless of how many you declare them. Further, <body>, if you declare it, will always be a child of the root element.
In tutorials I've learnt to use document.write. Now I understand that by many this is frowned upon. I've tried print(), but then it literally sends it to the printer.
So what are alternatives I should use, and why shouldn't I use document.write? Both w3schools and MDN use document.write.
The reason that your HTML is replaced is because of an evil JavaScript function: document.write().
It is most definitely "bad form." It only works with webpages if you use it on the page load; and if you use it during runtime, it will replace your entire document with the input. And if you're applying it as strict XHTML structure it's not even valid code.
the problem:
document.write writes to the document stream. Calling document.write on a closed (or loaded) document automatically calls document.open which will clear the document.
-- quote from the MDN
document.write() has two henchmen, document.open(), and document.close(). When the HTML document is loading, the document is "open". When the document has finished loading, the document has "closed". Using document.write() at this point will erase your entire (closed) HTML document and replace it with a new (open) document. This means your webpage has erased itself and started writing a new page - from scratch.
I believe document.write() causes the browser to have a performance decrease as well (correct me if I am wrong).
an example:
This example writes output to the HTML document after the page has loaded. Watch document.write()'s evil powers clear the entire document when you press the "exterminate" button:
I am an ordinary HTML page. I am innocent, and purely for informational purposes. Please do not <input type="button" onclick="document.write('This HTML page has been succesfully exterminated.')" value="exterminate"/>
me!
the alternatives:
.innerHTML This is a wonderful alternative, but this attribute has to be attached to the element where you want to put the text.
Example: document.getElementById('output1').innerHTML = 'Some text!';
.createTextNode() is the alternative recommended by the W3C.
Example: var para = document.createElement('p');
para.appendChild(document.createTextNode('Hello, '));
NOTE: This is known to have some performance decreases (slower than .innerHTML). I recommend using .innerHTML instead.
the example with the .innerHTML alternative:
I am an ordinary HTML page.
I am innocent, and purely for informational purposes.
Please do not
<input type="button" onclick="document.getElementById('output1').innerHTML = 'There was an error exterminating this page. Please replace <code>.innerHTML</code> with <code>document.write()</code> to complete extermination.';" value="exterminate"/>
me!
<p id="output1"></p>
Here is code that should replace document.write in-place:
document.write=function(s){
var scripts = document.getElementsByTagName('script');
var lastScript = scripts[scripts.length-1];
lastScript.insertAdjacentHTML("beforebegin", s);
}
You can combine insertAdjacentHTML method and document.currentScript property.
The insertAdjacentHTML() method of the Element interface parses the specified text as HTML or XML and inserts the resulting nodes into the DOM tree at a specified position:
'beforebegin': Before the element itself.
'afterbegin': Just inside the element, before its first child.
'beforeend': Just inside the element, after its last child.
'afterend': After the element itself.
The document.currentScript property returns the <script> element whose script is currently being processed. Best position will be beforebegin — new HTML will be inserted before <script> itself. To match document.write's native behavior, one would position the text afterend, but then the nodes from consecutive calls to the function aren't placed in the same order as you called them (like document.write does), but in reverse. The order in which your HTML appears is probably more important than where they're place relative to the <script> tag, hence the use of beforebegin.
document.currentScript.insertAdjacentHTML(
'beforebegin',
'This is a document.write alternative'
)
As a recommended alternative to document.write you could use DOM manipulation to directly query and add node elements to the DOM.
Just dropping a note here to say that, although using document.write is highly frowned upon due to performance concerns (synchronous DOM injection and evaluation), there is also no actual 1:1 alternative if you are using document.write to inject script tags on demand.
There are a lot of great ways to avoid having to do this (e.g. script loaders like RequireJS that manage your dependency chains) but they are more invasive and so are best used throughout the site/application.
I fail to see the problem with document.write. If you are using it before the onload event fires, as you presumably are, to build elements from structured data for instance, it is the appropriate tool to use. There is no performance advantage to using insertAdjacentHTML or explicitly adding nodes to the DOM after it has been built. I just tested it three different ways with an old script I once used to schedule incoming modem calls for a 24/7 service on a bank of 4 modems.
By the time it is finished this script creates over 3000 DOM nodes, mostly table cells. On a 7 year old PC running Firefox on Vista, this little exercise takes less than 2 seconds using document.write from a local 12kb source file and three 1px GIFs which are re-used about 2000 times. The page just pops into existence fully formed, ready to handle events.
Using insertAdjacentHTML is not a direct substitute as the browser closes tags which the script requires remain open, and takes twice as long to ultimately create a mangled page. Writing all the pieces to a string and then passing it to insertAdjacentHTML takes even longer, but at least you get the page as designed. Other options (like manually re-building the DOM one node at a time) are so ridiculous that I'm not even going there.
Sometimes document.write is the thing to use. The fact that it is one of the oldest methods in JavaScript is not a point against it, but a point in its favor - it is highly optimized code which does exactly what it was intended to do and has been doing since its inception.
It's nice to know that there are alternative post-load methods available, but it must be understood that these are intended for a different purpose entirely; namely modifying the DOM after it has been created and memory allocated to it. It is inherently more resource-intensive to use these methods if your script is intended to write the HTML from which the browser creates the DOM in the first place.
Just write it and let the browser and interpreter do the work. That's what they are there for.
PS: I just tested using an onload param in the body tag and even at this point the document is still open and document.write() functions as intended. Also, there is no perceivable performance difference between the various methods in the latest version of Firefox. Of course there is a ton of caching probably going on somewhere in the hardware/software stack, but that's the point really - let the machine do the work. It may make a difference on a cheap smartphone though. Cheers!
The question depends on what you are actually trying to do.
Usually, instead of doing document.write you can use someElement.innerHTML or better, document.createElement with an someElement.appendChild.
You can also consider using a library like jQuery and using the modification functions in there: http://api.jquery.com/category/manipulation/
This is probably the most correct, direct replacement: insertAdjacentHTML.
Try to use getElementById() or getElementsByName() to access a specific element and then to use innerHTML property:
<html>
<body>
<div id="myDiv1"></div>
<div id="myDiv2"></div>
</body>
<script type="text/javascript">
var myDiv1 = document.getElementById("myDiv1");
var myDiv2 = document.getElementById("myDiv2");
myDiv1.innerHTML = "<b>Content of 1st DIV</b>";
myDiv2.innerHTML = "<i>Content of second DIV element</i>";
</script>
</html>
Use
var documentwrite =(value, method="", display="")=>{
switch(display) {
case "block":
var x = document.createElement("p");
break;
case "inline":
var x = document.createElement("span");
break;
default:
var x = document.createElement("p");
}
var t = document.createTextNode(value);
x.appendChild(t);
if(method==""){
document.body.appendChild(x);
}
else{
document.querySelector(method).appendChild(x);
}
}
and call the function based on your requirement as below
documentwrite("My sample text"); //print value inside body
documentwrite("My sample text inside id", "#demoid", "block"); // print value inside id and display block
documentwrite("My sample text inside class", ".democlass","inline"); // print value inside class and and display inline
I'm not sure if this will work exactly, but I thought of
var docwrite = function(doc) {
document.write(doc);
};
This solved the problem with the error messages for me.
In tutorials I've learnt to use document.write. Now I understand that by many this is frowned upon. I've tried print(), but then it literally sends it to the printer.
So what are alternatives I should use, and why shouldn't I use document.write? Both w3schools and MDN use document.write.
The reason that your HTML is replaced is because of an evil JavaScript function: document.write().
It is most definitely "bad form." It only works with webpages if you use it on the page load; and if you use it during runtime, it will replace your entire document with the input. And if you're applying it as strict XHTML structure it's not even valid code.
the problem:
document.write writes to the document stream. Calling document.write on a closed (or loaded) document automatically calls document.open which will clear the document.
-- quote from the MDN
document.write() has two henchmen, document.open(), and document.close(). When the HTML document is loading, the document is "open". When the document has finished loading, the document has "closed". Using document.write() at this point will erase your entire (closed) HTML document and replace it with a new (open) document. This means your webpage has erased itself and started writing a new page - from scratch.
I believe document.write() causes the browser to have a performance decrease as well (correct me if I am wrong).
an example:
This example writes output to the HTML document after the page has loaded. Watch document.write()'s evil powers clear the entire document when you press the "exterminate" button:
I am an ordinary HTML page. I am innocent, and purely for informational purposes. Please do not <input type="button" onclick="document.write('This HTML page has been succesfully exterminated.')" value="exterminate"/>
me!
the alternatives:
.innerHTML This is a wonderful alternative, but this attribute has to be attached to the element where you want to put the text.
Example: document.getElementById('output1').innerHTML = 'Some text!';
.createTextNode() is the alternative recommended by the W3C.
Example: var para = document.createElement('p');
para.appendChild(document.createTextNode('Hello, '));
NOTE: This is known to have some performance decreases (slower than .innerHTML). I recommend using .innerHTML instead.
the example with the .innerHTML alternative:
I am an ordinary HTML page.
I am innocent, and purely for informational purposes.
Please do not
<input type="button" onclick="document.getElementById('output1').innerHTML = 'There was an error exterminating this page. Please replace <code>.innerHTML</code> with <code>document.write()</code> to complete extermination.';" value="exterminate"/>
me!
<p id="output1"></p>
Here is code that should replace document.write in-place:
document.write=function(s){
var scripts = document.getElementsByTagName('script');
var lastScript = scripts[scripts.length-1];
lastScript.insertAdjacentHTML("beforebegin", s);
}
You can combine insertAdjacentHTML method and document.currentScript property.
The insertAdjacentHTML() method of the Element interface parses the specified text as HTML or XML and inserts the resulting nodes into the DOM tree at a specified position:
'beforebegin': Before the element itself.
'afterbegin': Just inside the element, before its first child.
'beforeend': Just inside the element, after its last child.
'afterend': After the element itself.
The document.currentScript property returns the <script> element whose script is currently being processed. Best position will be beforebegin — new HTML will be inserted before <script> itself. To match document.write's native behavior, one would position the text afterend, but then the nodes from consecutive calls to the function aren't placed in the same order as you called them (like document.write does), but in reverse. The order in which your HTML appears is probably more important than where they're place relative to the <script> tag, hence the use of beforebegin.
document.currentScript.insertAdjacentHTML(
'beforebegin',
'This is a document.write alternative'
)
As a recommended alternative to document.write you could use DOM manipulation to directly query and add node elements to the DOM.
Just dropping a note here to say that, although using document.write is highly frowned upon due to performance concerns (synchronous DOM injection and evaluation), there is also no actual 1:1 alternative if you are using document.write to inject script tags on demand.
There are a lot of great ways to avoid having to do this (e.g. script loaders like RequireJS that manage your dependency chains) but they are more invasive and so are best used throughout the site/application.
I fail to see the problem with document.write. If you are using it before the onload event fires, as you presumably are, to build elements from structured data for instance, it is the appropriate tool to use. There is no performance advantage to using insertAdjacentHTML or explicitly adding nodes to the DOM after it has been built. I just tested it three different ways with an old script I once used to schedule incoming modem calls for a 24/7 service on a bank of 4 modems.
By the time it is finished this script creates over 3000 DOM nodes, mostly table cells. On a 7 year old PC running Firefox on Vista, this little exercise takes less than 2 seconds using document.write from a local 12kb source file and three 1px GIFs which are re-used about 2000 times. The page just pops into existence fully formed, ready to handle events.
Using insertAdjacentHTML is not a direct substitute as the browser closes tags which the script requires remain open, and takes twice as long to ultimately create a mangled page. Writing all the pieces to a string and then passing it to insertAdjacentHTML takes even longer, but at least you get the page as designed. Other options (like manually re-building the DOM one node at a time) are so ridiculous that I'm not even going there.
Sometimes document.write is the thing to use. The fact that it is one of the oldest methods in JavaScript is not a point against it, but a point in its favor - it is highly optimized code which does exactly what it was intended to do and has been doing since its inception.
It's nice to know that there are alternative post-load methods available, but it must be understood that these are intended for a different purpose entirely; namely modifying the DOM after it has been created and memory allocated to it. It is inherently more resource-intensive to use these methods if your script is intended to write the HTML from which the browser creates the DOM in the first place.
Just write it and let the browser and interpreter do the work. That's what they are there for.
PS: I just tested using an onload param in the body tag and even at this point the document is still open and document.write() functions as intended. Also, there is no perceivable performance difference between the various methods in the latest version of Firefox. Of course there is a ton of caching probably going on somewhere in the hardware/software stack, but that's the point really - let the machine do the work. It may make a difference on a cheap smartphone though. Cheers!
The question depends on what you are actually trying to do.
Usually, instead of doing document.write you can use someElement.innerHTML or better, document.createElement with an someElement.appendChild.
You can also consider using a library like jQuery and using the modification functions in there: http://api.jquery.com/category/manipulation/
This is probably the most correct, direct replacement: insertAdjacentHTML.
Try to use getElementById() or getElementsByName() to access a specific element and then to use innerHTML property:
<html>
<body>
<div id="myDiv1"></div>
<div id="myDiv2"></div>
</body>
<script type="text/javascript">
var myDiv1 = document.getElementById("myDiv1");
var myDiv2 = document.getElementById("myDiv2");
myDiv1.innerHTML = "<b>Content of 1st DIV</b>";
myDiv2.innerHTML = "<i>Content of second DIV element</i>";
</script>
</html>
Use
var documentwrite =(value, method="", display="")=>{
switch(display) {
case "block":
var x = document.createElement("p");
break;
case "inline":
var x = document.createElement("span");
break;
default:
var x = document.createElement("p");
}
var t = document.createTextNode(value);
x.appendChild(t);
if(method==""){
document.body.appendChild(x);
}
else{
document.querySelector(method).appendChild(x);
}
}
and call the function based on your requirement as below
documentwrite("My sample text"); //print value inside body
documentwrite("My sample text inside id", "#demoid", "block"); // print value inside id and display block
documentwrite("My sample text inside class", ".democlass","inline"); // print value inside class and and display inline
I'm not sure if this will work exactly, but I thought of
var docwrite = function(doc) {
document.write(doc);
};
This solved the problem with the error messages for me.
I'm working with classic ASP.
I have an 2 includes that have 2 different forms on them. They are both unique in name. However, when I try to read the value of the one the elements in the 2nd form I get an error saying it is null. However, when I view the source in Firebug I can see that in face there is a value in that element.
My javascript code:
console.log(document.getElementById('focusValue').value);
Output from firebug:
<input id="focusValue" type="hidden" value="1006" name="focusValue">
Is there something I need to do because there are 2 forms on this "rendered" screen? The only other thing I think I should mention is that these pages are in an iFrame. Not sure if that really matters...
An iFrame creates a separate document within the containing document, you need to get a reference to that document before you can access its content. There is a reasonable tutorial at http://www.dyn-web.com/tutorials/iframes/.
If you only have one iFrame in the page, then you can reference it by:
var frame = window.frames[0];
Or you could use an id with getElementById. To get a reference to the document:
var doc;
if (frame) {
doc = frame.contentDocument || frame.contentWindow.document;
}
Now you can get to the input element:
var input = doc && doc.getElementById('focusValue');
Of course this all depends on you complying with the same origin policy, otherwise you can't access the frame content.
Can't see your page, so it's hard to debug. Assuming the script runs AFTER the forms. The only thing i can think is that there is more than one element on the page with the id "focusValue".
What happens when you console.log(document.getElementById('focusValue'))
This is the iframe I'm trying to access:
<div class="mceBody" id="additionalTxt_b">
<iframe frameborder="0" id="additionalTxt_f" src='javascript:""' class="punymce"/>
</div>
Using this line:
frames['additionalTxt_f'].document.getElementsByTagName("body")[0].innerHTML
For some reason I'm getting "frames.additionalTxt_f is undefined" from firebug.
I have similar iframes (dynamically created by punyMCE plugin) on other pages, and they work perfectly fine. And IE7/8 has no problem accessing this iframe either.
Just at a complete loss here. Any ideas on why Firefox can't find the iframe?
The window.frames[] array is indexed by the [i]frame's name attribute (aka frame target). id can't be relied upon to also work — although it may in IE <8, which often thinks names and ids are the same thing.
If you want to access a frame's content via ID, use the DOM Level 2 HTML contentDocument property instead of the old-school (“DOM Level 0”) frames array:
document.getElementById('additionalTxt_f').contentDocument.body.innerHTML
...but then, for compatibility with IE <8, you also have to add some fallback cruft, since it doesn't support contentDocument:
var f= document.getElementById('additionalTxt_f');
var d= f.contentDocument? f.contentDocument : f.contentWindow.document;
d.body.innerHTML
So it's up to you which method you think is less ugly: the extra script work, or just using the name attribute.
if you have only 1 iframe you can also find it with window.frames[1] or
document.getElementsByTagName('iframe')[0]
(In the first option, the parent window is #0)