Comments on: The problem with innerHTML http://ajaxian.com/archives/the-problem-with-innerhtml Cleaning up the web with Ajax Thu, 17 May 2012 07:43:39 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Morgan Roderick http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-260095 Morgan Roderick Tue, 18 Dec 2007 09:29:55 +0000 http://ajaxian.com/?p=3115#comment-260095 kschneid: that's the one. That article inspired me greatly awhile back, and has caused a small shift in how I write my javascript :-) kschneid: that’s the one. That article inspired me greatly awhile back, and has caused a small shift in how I write my javascript :-)

]]> By: MiguelVentura http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-260039 MiguelVentura Sun, 16 Dec 2007 22:51:01 +0000 http://ajaxian.com/?p=3115#comment-260039 Sorry for my previous post... I was hoping to get "readable version here. Sorry for my previous post… I was hoping to get “readable version here.

]]> By: MiguelVentura http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-260038 MiguelVentura Sun, 16 Dec 2007 22:35:15 +0000 http://ajaxian.com/?p=3115#comment-260038 I personaly never liked using regular expressions to filter HTML. Unless you use a grammar you won't really be able to parse anything. el.innerHTML = html.replace(/]*>((.|[\r\n])*?)/ig, ""); looks good, but what if instead of terminating the script with "" I terminate it with "" ? Or better yet, how about html = "void(0);pt defer=\"true\">alert('foo');" If this is about security and disabling script injection attacks, it still has a lot that isn't done. I personaly never liked using regular expressions to filter HTML. Unless you use a grammar you won’t really be able to parse anything.
el.innerHTML = html.replace(/]*>((.|[\r\n])*?)/ig, “”);
looks good, but what if instead of terminating the script with “” I terminate it with “” ? Or better yet, how about
html = “void(0);pt defer=\”true\”>alert(‘foo’);”

If this is about security and disabling script injection attacks, it still has a lot that isn’t done.

]]> By: Schill http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-260025 Schill Sat, 15 Dec 2007 21:17:39 +0000 http://ajaxian.com/?p=3115#comment-260025 Actually, interestingly enough, I've noted that you can write to innerHTML in at least a limited fashion with Firefox 2/3 and Safari 3 in this case; my personal site is served with the correct MIME type when applicable, and I am (unfortunately) writing to innerHTML in a few spots. I was thinking I'd have to rewrite those bits to use proper DOM calls, but it turns out I was able to get away with a few things. This was not the case in 2004 when <a href="http://www.schillmania.com/content/entries/2004/10/24/application-xhtml+xml/" rel="nofollow">I was "researching" application/xhtml+xml</a>, Firefox would throw errors when any innerHTML "write" call was attempted. I get the feeling they decided to allow some form of writes because the technique is used (and overly-so, in my opinion,) so often. Actually, interestingly enough, I’ve noted that you can write to innerHTML in at least a limited fashion with Firefox 2/3 and Safari 3 in this case; my personal site is served with the correct MIME type when applicable, and I am (unfortunately) writing to innerHTML in a few spots. I was thinking I’d have to rewrite those bits to use proper DOM calls, but it turns out I was able to get away with a few things. This was not the case in 2004 when I was “researching” application/xhtml+xml, Firefox would throw errors when any innerHTML “write” call was attempted. I get the feeling they decided to allow some form of writes because the technique is used (and overly-so, in my opinion,) so often.

]]> By: posaune http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-260018 posaune Sat, 15 Dec 2007 06:07:18 +0000 http://ajaxian.com/?p=3115#comment-260018 One thing concerning innerHTML that never seems to be mentioned is that it will not work when content is served as application/xhtml+xml (or any other flavor of true xml for that matter) One thing concerning innerHTML that never seems to be mentioned is that it will not work when content is served as application/xhtml+xml (or any other flavor of true xml for that matter)

]]> By: HudsonTavares http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-260012 HudsonTavares Sat, 15 Dec 2007 02:15:55 +0000 http://ajaxian.com/?p=3115#comment-260012 * <i>Setting innerHTML will destroy existing HTML elements that have event handlers attached to them, potentially creating a memory leak on some browsers.</i> That's a implementation problem, and not an argument, neither in a favorably or contrary way to innerHTML. * <i>You can’t set the innerHTML property on all HTML elements on all browsers (for instance, Internet Explorer won’t let you set the innerHTML property of a table row element)</i> Until IE isn't dead, cross-browser solutions still as a set of work around. Ok, it's a good argument, but... we all know that there are millions of further things which IE doesn't allow. We're furious, however, not amazed about. @Schill When using AJAX, sometimes i throw the results on a XSLT processor before be attached on the response. So, i use innerHTML without merging the layers of my applications, pasting directly the XSLT results on a target node. * Setting innerHTML will destroy existing HTML elements that have event handlers attached to them, potentially creating a memory leak on some browsers.

That’s a implementation problem, and not an argument, neither in a favorably or contrary way to innerHTML.

* You can’t set the innerHTML property on all HTML elements on all browsers (for instance, Internet Explorer won’t let you set the innerHTML property of a table row element)

Until IE isn’t dead, cross-browser solutions still as a set of work around. Ok, it’s a good argument, but… we all know that there are millions of further things which IE doesn’t allow. We’re furious, however, not amazed about.

@Schill
When using AJAX, sometimes i throw the results on a XSLT processor before be attached on the response. So, i use innerHTML without merging the layers of my applications, pasting directly the XSLT results on a target node.

]]> By: Schill http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-260009 Schill Fri, 14 Dec 2007 23:22:29 +0000 http://ajaxian.com/?p=3115#comment-260009 In my experience, if you build a DOM structure offline (createDocumentFragment/createElement and so on,) finally inserting to the "live" document with a single appendChild() call, the browser shouldn't have to do any more reflow work than if innerHTML were used.   I'm also a fan of having "templates" in HTML wherever possible (avoiding creating HTML using JS is always good, thus separating layers etc.), cloning that template, modifying and appending to the DOM. Again if you do all of this work offline and append to the live document once, I think the performance is pretty solid. In my experience, if you build a DOM structure offline (createDocumentFragment/createElement and so on,) finally inserting to the “live” document with a single appendChild() call, the browser shouldn’t have to do any more reflow work than if innerHTML were used.
 
I’m also a fan of having “templates” in HTML wherever possible (avoiding creating HTML using JS is always good, thus separating layers etc.), cloning that template, modifying and appending to the DOM. Again if you do all of this work offline and append to the live document once, I think the performance is pretty solid.

]]> By: Ryan http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-260004 Ryan Fri, 14 Dec 2007 19:54:25 +0000 http://ajaxian.com/?p=3115#comment-260004 The Taconite Ajax framework does not use the innerHTML property**, instead relying on DOM manipulation methods. All you do is specify the markup you want, *as markup*, and Taconite does the renderning for you. Ryan Taconite Lead Developer ** The innerHTML property is used in a few spots to try to overcome some IE quirks, but it is used quite sparingly. The Taconite Ajax framework does not use the innerHTML property**, instead relying on DOM manipulation methods. All you do is specify the markup you want, *as markup*, and Taconite does the renderning for you.

Ryan
Taconite Lead Developer

** The innerHTML property is used in a few spots to try to overcome some IE quirks, but it is used quite sparingly.

]]> By: skypoet http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-260000 skypoet Fri, 14 Dec 2007 17:26:58 +0000 http://ajaxian.com/?p=3115#comment-260000 Julien, Thanks for the article. I'm also glad that you brought up the fact that innerHTML is extremely fast! Oliver Julien,

Thanks for the article. I’m also glad that you brought up the fact that innerHTML is extremely fast!

Oliver

]]> By: jlecomte http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-259996 jlecomte Fri, 14 Dec 2007 16:36:34 +0000 http://ajaxian.com/?p=3115#comment-259996 @mdmadph One of the best use case for the <code>innerHTML</code> property is when it comes to modifying the document tree efficiently. Using <code>innerHTML</code> is a lot faster than using the DOM APIs. @mdmadph

One of the best use case for the innerHTML property is when it comes to modifying the document tree efficiently. Using innerHTML is a lot faster than using the DOM APIs.

]]> By: Anonymous http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-259995 Anonymous Fri, 14 Dec 2007 16:27:12 +0000 http://ajaxian.com/?p=3115#comment-259995 sometimes innerHTML is only the right way http://www.quirksmode.org/dom/innerhtml.html sometimes innerHTML is only the right way
http://www.quirksmode.org/dom/innerhtml.html

]]> By: jlecomte http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-259991 jlecomte Fri, 14 Dec 2007 15:42:21 +0000 http://ajaxian.com/?p=3115#comment-259991 @Mathieu I could not agree more. The <code>setInnerHTML</code> function barely normalizes the script tag execution behavior across all A-grade browsers. @Morgan Reducing the number of event handlers definitely helps alleviating some of the associated memory leaks, and event delegation is a well-known pattern that helps doing just that. @Mathieu

I could not agree more. The setInnerHTML function barely normalizes the script tag execution behavior across all A-grade browsers.

@Morgan

Reducing the number of event handlers definitely helps alleviating some of the associated memory leaks, and event delegation is a well-known pattern that helps doing just that.

]]> By: Pete B http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-259986 Pete B Fri, 14 Dec 2007 14:23:15 +0000 http://ajaxian.com/?p=3115#comment-259986 I've run up against a number of problems using innerHTML recently: document.body.innerHTML += 'your stuff' seems to break the DOM tree so that any node collections and event handlers are lost. Also, when using innerHTML to parse a json feed (in a form - asp.net) makes ie randomly crash I’ve run up against a number of problems using innerHTML recently: document.body.innerHTML += ‘your stuff’ seems to break the DOM tree so that any node collections and event handlers are lost. Also, when using innerHTML to parse a json feed (in a form – asp.net) makes ie randomly crash

]]> By: Morgan Roderick http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-259982 Morgan Roderick Fri, 14 Dec 2007 13:54:11 +0000 http://ajaxian.com/?p=3115#comment-259982 Some of the issues with event listeners and innerHTML can easily be overcome. Chris Heilmann (unless my memory fails me) wrote an excellent article on using event delegates instead of event handlers in javascript. Chris: can you link it? LowPro for Prototype, by Dan Webb, has the brilliant Event.addBehavior method, that also overcomes problems with dom updates and event handlers. Some of the issues with event listeners and innerHTML can easily be overcome.

Chris Heilmann (unless my memory fails me) wrote an excellent article on using event delegates instead of event handlers in javascript. Chris: can you link it?

LowPro for Prototype, by Dan Webb, has the brilliant Event.addBehavior method, that also overcomes problems with dom updates and event handlers.

]]> By: Site Smart http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-259980 Site Smart Fri, 14 Dec 2007 13:36:43 +0000 http://ajaxian.com/?p=3115#comment-259980 since DOM is the recommendation it really shouldn't be an issue since DOM is the recommendation it really shouldn’t be an issue

]]> By: Snowcore http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-259976 Snowcore Fri, 14 Dec 2007 13:08:53 +0000 http://ajaxian.com/?p=3115#comment-259976 Concerning innerHTML of the in IE it's a real problem. My solution is to receive data via AJAX, and then use DOM functions to build new rows of the table: document.createElement("TR"); // .... etc. Concerning innerHTML of the in IE it’s a real problem.
My solution is to receive data via AJAX, and then use DOM functions to build new rows of the table:

document.createElement(“TR”);
// ….

etc.

]]> By: Rodrigo http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-259975 Rodrigo Fri, 14 Dec 2007 13:05:50 +0000 http://ajaxian.com/?p=3115#comment-259975 Using innerHMTL also has the problem of getting an "Unknow runtime error" in Internet Explorer sometimes. Using innerHMTL also has the problem of getting an “Unknow runtime error” in Internet Explorer sometimes.

]]> By: Mathieu \'p01\' Henri http://ajaxian.com/archives/the-problem-with-innerhtml/comment-page-1#comment-259971 Mathieu \'p01\' Henri Fri, 14 Dec 2007 12:50:51 +0000 http://ajaxian.com/?p=3115#comment-259971 Script tags are just one out of many ways to inject malicious code. Stripping only the script tag is sub par. You must also be careful of IFRAMEs, OBJECT, EMBED, IMG ... and even some attributes ( some browsers still allow script execution in <em>style="background:url(javascript:...);"</em>. The only way to sanitize properly markup to be injected is to use a whitelist of tags and attributes ... or to simply not inject markup using innerHTML. Script tags are just one out of many ways to inject malicious code. Stripping only the script tag is sub par. You must also be careful of IFRAMEs, OBJECT, EMBED, IMG … and even some attributes ( some browsers still allow script execution in style=”background:url(javascript:…);”.

The only way to sanitize properly markup to be injected is to use a whitelist of tags and attributes … or to simply not inject markup using innerHTML.

]]>