SitePoint Sponsor

User Tag List

Results 1 to 22 of 22
  1. #1
    SitePoint Addict
    Join Date
    Sep 2001
    Posts
    320
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    using innerHTML still ok?

    i am new to the DOM. i am learning via a book called "DOM Scripting" by Jeremy Keith. In the book he recommends not using innerHTML because it is not a web standard and probably never will be. Instead he recommends using createElement() and createTextNode(), and others.

    What do you guys recommend? Should I just use innerHTML since it's easier or stick with the standards compliant way of doing things?
    Steve Davis

  2. #2
    SitePoint Zealot
    Join Date
    Dec 2007
    Posts
    120
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    IMO, innerHTML is easier from a writing/reading standpoint and it's pretty much a de facto standard in browsers.

    I say innerHTML.

  3. #3
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,696
    Mentioned
    101 Post(s)
    Tagged
    4 Thread(s)
    My opinion is that the innerHTML may be easier, but the DOM is better.

    However for a balanced discussion and comparison, you may wish to have a read of InnerHTML vs DOM
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  4. #4
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,799
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Two things to consider.

    1. innerHTML only works for HTML and not XHTML. If you want to use XHTML then you need to use createElementNS()

    2. Using innerHTML doesn't add to the DOM in all browsers so if you want to read back from what you added in order to update it in subsequent processing then you can't use it.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  5. #5
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by CraniumDesigns View Post
    ... because it is not a web standard and probably never will be.
    It is part of the WHATWG specification that has been suggested to the W3C to adopt.

    Only using innerHTML can result in a unmaintainable mess. But it does have its benefits. It is for example much faster than the DOM, especially in Internet Explorer. Check out the link above provided by pmw57.

  6. #6
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,696
    Mentioned
    101 Post(s)
    Tagged
    4 Thread(s)
    For me innerHTML crosses the line. With javascript we're supposed to keep the behaviour layer separate from the content layer. As such, most of the content that should be seen by people should exist in the HTML format already.

    I just so happen to have finished reading DOM Scripting a few days ago, and am now going through Bulletproof AJAX, where he goes through the three data formats that can be used: XML, JSON and HTML with innerHTML.

    For the purpose of AJAX, XML is the clear winner, but for HTML using innerHTML, there is the speed improvement to consider, weighed up against troubles if you want to update several sections at the same time.

    Another issue is future compatibility, in that if you properly serve XHTML as application/xhtml+xml (as it should be) then innerHTML is no longer supported.
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  7. #7
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pmw57 View Post
    Another issue is future compatibility, in that if you properly serve XHTML as application/xhtml+xml (as it should be) then innerHTML is no longer supported.
    innerHTML does work with XHTML. At least in Firefox, Opera and Safari 3.

    More WHATWG reading on XML and innerHTML.

  8. #8
    SitePoint Guru
    Join Date
    Apr 2006
    Posts
    802
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It may just be a matter of personal taste.

    I echo html out of strings on the server all the time, but I prefer creating and manipulating objects on the client with the DOM. It seems to make the code more understandable and reusable.

  9. #9
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,696
    Mentioned
    101 Post(s)
    Tagged
    4 Thread(s)
    When XHTML is inappropriately served as text/html (as it has to be for Internet Explorer to undersand it, then you can use innerHTML).

    When XHTML is properly served as application/xhtml+xml, then innerHTML becomes useless.

    We have a very good XHTML vs HTML FAQ that nicely covers these issues and more.
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  10. #10
    I meant that to happen silver trophybronze trophy Raffles's Avatar
    Join Date
    Sep 2005
    Location
    Tanzania
    Posts
    4,662
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    When XHTML is properly served as application/xhtml+xml, then innerHTML becomes useless.
    How so? innerHTML works with XML documents now, in modern browsers. That's not useless.

  11. #11
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,696
    Mentioned
    101 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by Raffles View Post
    How so? innerHTML works with XML documents now, in modern browsers. That's not useless.
    That's only because XHTML is improperly served as text/html to the modern browsers to cater for IE's inability to handle XHTML. When XHTML is properly served as application/xhtml+xml it becomes impossible to use innerHTML
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  12. #12
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    pmw57, how about actually reading the above links and testing it for yourself? You can test this by either setting up a server to serve xhtml as application/xhtml+xml or simply save the page with the xhtml extension. You can verify that the type is correct in the Page Info in Firefox.

  13. #13
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,696
    Mentioned
    101 Post(s)
    Tagged
    4 Thread(s)
    Read and tested. You show me a page with properly served XHTML that works in IE and I will lay down my guns.

    The IE7 developers say they they do not intend to support XHTML.

    The <?xml> prolog, strict mode, and XHTML in IE

    asking for support for the “application/xml+xhtml” MIME type in IE. I should say that IE7 will not add support for this MIME type
    Another good piece about it that's much more recent is Internet Explorer Did Not Kill XHTML

    To sum up what the IE7 have had to say, is such a steaming pile that they didn't want to hack in a poorly done job of it. Instead they are waiting until the next release to properly implement the XML parser.
    Last edited by paul_wilkins; Jan 17, 2008 at 06:47.
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  14. #14
    I meant that to happen silver trophybronze trophy Raffles's Avatar
    Join Date
    Sep 2005
    Location
    Tanzania
    Posts
    4,662
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Clearly we are misunderstanding each other. This statement:
    When XHTML is properly served as application/xhtml+xml, then innerHTML becomes useless.
    is wrong when talking about it in general, but sort of right when talking about IE. The thing is that what you said didn't make it seem like you were talking about IE only. In any case, it's not really that innerHTML becomes useless when serving IE proper XHTML - everything becomes useless because everything fails.

  15. #15
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,696
    Mentioned
    101 Post(s)
    Tagged
    4 Thread(s)
    Serving proper XHTML to IE fails, that's a given. The real issue with other browsers that do accept it is that with innerHTML, getting works, and setting doesn't in most browsers. To date it is only recent versions of Firefox that support this.

    See the Quirksmode bug report about innerHTML in XHTML pages.
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  16. #16
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This seems to have ended up being a question about innerHTML and XHMTL. Original question was about if it was OK to use innerHTML at all.

    Nobody would serve a page as application/xhtml+xml today, since that page wouldn't be viewable in IE at all.

    Also, note that the bug report you linked to is from November 2004. Firefox 1.0 was then released. So yes, I guess you might have a point there. Any developer wanting to support the 2-3 Firefox 1.0 users out there should test innerHTML carefully when using it.

  17. #17
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,696
    Mentioned
    101 Post(s)
    Tagged
    4 Thread(s)
    Yes, getting back to the question at hand, there are a number issues with innerHTML, that we can agree on.

    So, if you intend to stay with HTML you should be right. Once you go to XHTML, as long as you still serve it as HTML (as most of it is anyway) you will still be fairly okay.

    This is why going the standards way is a good thing. It has the greatest chance of surviving with few issues, and if there are any issues they get worked out over time.

    I for one am going to be interested in what Microsoft do with IE8 and application/xhtml+xml
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  18. #18
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, and also that that you will be fine using innerHTML with XHTML (if the browser supports it) as well.

    innerHTML can cause problems but can also be a real life safer when it comes to performance. Just try out the following code to compare performance in Internet Explorer:
    Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    	"http://www.w3.org/TR/html4/loose.dtd">
    <html>
    <head>
    <title>Perfomance Test</title>
    <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
    <script type="text/javascript">
    var perfTest;
    
    function PerfTest() {
    	this.data = [];
    
    	for(var i=0; i<4000; i++) {
    		this.data[i] = ["28.02.2004", "Jag och Lars har samma mål - vi ska till EM", "1190 kb", "dummy data"]
    	}
    
    	this.outputNode = document.getElementById("output");
    	this.timeNode = document.getElementById("time");
    
    	this.arraySolution = function() {
    		this.outputNode.innerHTML = "";
    
    		this.startTime = new Date();
    
    		var aTable = [];
    
    		aTable.push("<table border='1'><tbody>");
    
    		for(var i=0, iLength = this.data.length; i < iLength; i++) {
    			aTable.push("<tr>");
    			aTable.push("<td>" + this.data[i][0] + "</td>");
    			aTable.push("<td>" + this.data[i][1] + "</td>");
    			aTable.push("<td>" + this.data[i][2] + "</td>");
    			aTable.push("<td>" + this.data[i][3] + "</td>");
    			aTable.push("</tr>");
    		}
    
    		aTable.push("</tbody></table>");
    
    		this.outputNode.innerHTML = aTable.join("");
    
    		this.endTime = new Date();
    		this.outputTime();
    	}
    
    	this.DOMSolution = function() {
    		this.outputNode.innerHTML = "";
    
    		this.startTime = new Date();
    
    		var oTable	= document.createElement("table");
    		var oTbody	= document.createElement("tbody");
    		var oRow	= document.createElement("tr");
    		var oCell	= document.createElement("td");
    		oTable.border="1"
    
    		oTable.appendChild(oTbody);
    
    		for(var i=0, iLength = this.data.length; i < iLength; i++) {
    			var oNewRow = oRow.cloneNode(true);
    
    			for(var j=0, iLength2 = this.data[i].length; j < iLength2; j++) {
    				var oNewCell = oCell.cloneNode(true);
    				oNewCell.appendChild(document.createTextNode(this.data[i][j]));
    				oNewRow.appendChild(oNewCell);
    			}
    
    			oTbody.appendChild(oNewRow);
    		}
    
    		this.outputNode.appendChild(oTable);
    
    		this.endTime = new Date();
    		this.outputTime();
    	}
    
    	this.outputTime = function() {
    		this.timeNode.innerHTML = "Creation of the table below with " + this.data.length 
    								+ " rows took: " + (this.endTime.getTime() - this.startTime.getTime() ) /1000 + " seconds";
    	}
    }
    
    window.onload = function() {
    	perfTest = new PerfTest();
    }
    </script>
    <style type="text/css">
    #time {
    	font-weight:bold;
    	margin:20px 0 10px;
    }
    
    input {
    	width:250px;
    }
    </style>
    </head>
    
    <body>
    <p>Create a table (4 columns, 4000 rows) using one of the following methods:</p>
    <input type="button" value="array/push method with innerHTML" onclick="perfTest.arraySolution();">
    <input type="button" value="DOM solution" onclick="perfTest.DOMSolution();">
    
    <div id="time"></div>
    <div id="output"></div>
    
    </body>
    </html>

  19. #19
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,696
    Mentioned
    101 Post(s)
    Tagged
    4 Thread(s)
    Thanks, I'll remember that the next time I'm using javascript to create huge tables. I suspect though that the server would to a much better job of that than the browser.

    Yes innerHTML is faster, nobody is contesting that. For me innerHTML is more like a hammer where you take the text and slam it in there, whereas I prefer the scalpel-like precision of the DOM. There are times when one is more appropriate than the other, and situations where the server is more appropriate than the browser.
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  20. #20
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Eh, apparently it was not obvious that this was just an example to show the performance differences...

  21. #21
    Unobtrusively zen silver trophybronze trophy
    paul_wilkins's Avatar
    Join Date
    Jan 2007
    Location
    Christchurch, New Zealand
    Posts
    14,696
    Mentioned
    101 Post(s)
    Tagged
    4 Thread(s)
    Plain text operations are always going to be faster than object manipulation.

    If you want to demonstrate performance differences, Quirksmode has an excellent set of test results between W3C DOM and innerHTML
    Programming Group Advisor
    Reference: JavaScript, Quirksmode Validate: HTML Validation, JSLint
    Car is to Carpet as Java is to JavaScript

  22. #22
    SitePoint Wizard Pepejeria's Avatar
    Join Date
    Jan 2005
    Location
    Too far up north
    Posts
    1,566
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pmw57 View Post
    Plain text operations are always going to be faster than object manipulation.
    Yes and no. String concatenation is dog slow in IE. Using String concatenation to output the table in the testcase would have been the slowest.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •