Christophe Porteneuve wrote: > Thanks for bringing that up; however, innerHTML being faster is > not such a myth; it depends on a lot of things. > First, if you need to support IE6, innerHTML with proper HTML building
I swear I saw it coming... If only you read the OP's question: > I am building hybrid iPhone/iPad apps and have had trouble with using > Element.innerHTML = "some html tag soup" to convert text into html dom > fragments. This indicates the use of Webkit, and that `innerHTML` won't be faster for him, (it can be even slower). Don't be lazy to read the OP's question. :) - Balázs 2010/12/17 And Clover <[email protected]>: > On Fri, 2010-12-17 at 16:29 +0100, Christophe Porteneuve wrote: >> First, if you need to support IE6, innerHTML with proper HTML building >> (as in, use a friggin' array, don't keep appending to string, man!) will >> beat the crap out of DOM building every time. > > It completely depends on what you're doing, even in IE6. > > If you are moving a lot of nodes (eg adding a thousand child elements to > a parent div one-by-one in a loop), *that's* when DOM is slow. It > involves lots of node list manipulations which in some browsers get > slower as the list increases in size, so you can end up with O(n²)-style > horrible performance. > > On the other hand if you're moving a single node, even if it contains a > large amount of descendant content, that's fast. Trying to do that with > innerHTML would involve much more parsing of the content, which would be > slower. > > There are ways that you can shift multiple nodes at once with DOM, which > is best of all, but it means using DocumentFragments and Ranges, which > have some compatibility problems (in particular no usable Range in IE<9) > and are not widely known yet. > > I would recommend using DOM (or DOM-style methods in a framework) by > default, until such time as you have a high-load case where it you > really need `innerHTML`. Typically this is when you need to generate a > very long table. > > The advantage of DOM methods for the inexperienced author, and why I > promote them as the default best approach, is that you don't have to > worry about HTML-escaping. When you do have to use `innerHTML`, you need > to be very careful to escape any dynamic content being inserted into the > string, otherwise you will be giving yourself a cross-site scripting > vulnerability. > > Because neither JS nor the BOM gives you a standard HTML encoder, you > have to write one of your own. It's not hard, just a couple of string > replaces, but 99% of the code out there doesn't do so: it just uses > something like (in jQuery) `html('<p>'+somedata+'</p>')`. Consequently > most client-side innerHTML-hacking code is vulnerable, which is a shame > when we're just starting to make any progress of reducing XSS in > server-side code. > > (This goes double for inserting JavaScript. Inserting > `onclick="doSomething()"` into an HTML string is super-ugly and requires > two levels of escaping for dynamic value insertion, JS literal escaping > *and* HTML escaping. No-one gets this right. With the DOM way of working > it's easy to add a listener/handler function to an element without any > string serialisation.) > > -- > And Clover > mailto:[email protected] http://www.doxdesk.com > skype:uknrbobince gtalk:[email protected] > > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
