I have some good insight on this issue because I have been wroking very closely with it for the past 6 months. When building a page that changed the DOM very frequently (so that it works like a desktop app) I found that the ONLY solution is innerHTML.

I built the app first by using proper DOM construction with document.createElement. The results were too slow in all browsers. So, I quickly changed to innerHTML to run some benchmarks. It was like a new app.

Basically, in real world examples proper element constructions is only an option for very simple construction. I would like someone preaching that innerHTML is bad to provide some examples of how they can make a modern app work efficiently without it.

Personally, I'm sick and tired of all the valid markup preachers. It's just a bunch of whiners trying to fool themselves and others that their job is more important than it really is. see here

I'm here with you Jonathan. And it was only sometime in the last few months that Jeremy changed his mind. Just last December Jeremy posted his feelings on his love hate relationship for innerHTML. I too am on the fence for innerHTML. If you think about the practical existence of it in browsers... it's probably even better supported than DOM methods. innerHTML has been around longer. And doesn't help when mozilla goes ahead and gives innerHTML support to XML documents (shouldn't they call it innerXML?)

I find it extreamly useful when getting callback strings and dumping it into a div element. I mean who really wants to parse it out and build a DOM construct then append it to the document.

Anyway, I feel that Jeremy is only taking this postiion due to his "Task Force" role he has to play. I mean really, you have to admit the practicality of innerHTML.

I try to avoid using innerHTML because I know it's considered bad practice and non-standardized (albeit widely compatible) code. In cases where I am updating exclusively text (but not HTML), I use the data property of an element, but if I need to output HTML via JavaScript, innerHTML is the fastest and easiest way to go. Creating nodes and text nodes with the DOM and then appending them to an element is a major hassle, and not worth the trouble, in my opinion. The only browsers that support the method fully also support innerHTML anyway.

Another factor is the way innerHTML outputs data. If you create a text node with HTML in it (say you're getting data from a PHP script that converts UBBC to HTML), JavaScript gets confused and throws an error; if you take that same output and use innerHTML, though, it will be output as expected. This is extremely important, as it would require an enormous amount of work to search for the HTML and create separate nodes via the DOM that contain the text nodes located therein. In short, it's a mess and beyond inefficient. InnerHTML is by a large margin the most efficient tool at our disposal, so we should use it, and it should be standardized.

Face it: just because it's not standardized doesn't mean it shouldn't be.

I think it's mainly to point out that the DOM is not only used for HTML and that if you were to use any other language to manipulate documents you can't use innerHTML. Besides, the book is about the DOM, innerHTML isn't apart of the DOM API :D

Scratch that comment about the book, I should pay more attention (currently reading the book) : )

I'm all in favor of using InnerHTML as well. It works in all browsers, it's faster and it's often much less complicated in terms of code.

Me using InnerHTML could be seen as a part of the almost valid xhtml philosophy I adopted quite a while ago.

The whole standards nazi thing is crap. Cross-browser CSS design, unobtrusive Javascript, degradability etc. etc.: great! But when a site has all this, works in all modern browsers and the client is happy then who gives a flying *beep* about using InnerHTML or some ultra-minor validation problems? I for one don't. Not anymore.

I consider myself as a standard nazi. (and i'm german and i live in berlin haha ....)

why ? because i left the webdesignbusiness for a couple of years because of the lack of standards, because every browser did what they thought should do. nothing worked nowhere except on your favourite browser. It was no fun at all so I quit it and went for print and photography. A year ago or so a friend of mine told me to check out the web again since so many things have changed. I was glad to see that CSS finally worked as it was supposed to, I also liked XHTML 1.0 strict because it forced you to seperate the content from the design - i liked the whole thing - why ? because standards where there !

For how long have you all been crying for them huh ? Same thing with JScript, Javascript and Ecmascript. How often have you blamed Microsoft for not going along with the standards ? How angry do you get when something that is in the standards doesn't work for you ? I know, as long as it makes your live easier you're losing the standards way pretty fast. In my opinion it shouldn't even be Web 2.0 - it all feels more like Web 1.5 ... on a good way but still a couple of miles to go.

Don't get me wrong here - I don't really blame you for considering innerHTML the better choice. It may is, it may will find its way in the dom spec and then it is all good - also for me ;)

Really I was a little too harsh to make my point in the first part but I really feel strong about standards - i was happy to see that they finally got widely implemented and I can't see why people would go out and say "who needs the standard way anyway" since we ALL were waiting so long for it. It was just the tone of some of the comments that kind of made me angry!

It sounds much better to say "i have a valid xhtml 1.0 website with valid css 2.1 and i'm using the dom api to manipulate it" this gives you a perfect definite idea about a site wherelse "yeah i have a page that is not valid xhtml, with some css hacks and some IE javascript functions" gives you a whole other feeling right ? ;)

When I met Bert Bos, the guy who made CSS, he said "people always want cool new features - what they don't want is to write the specs"

So I'm not sure if I made any points here - except for that I feel kinda strong about standards - but I just got up ;)

And I think people who are using innerHTML are still cool - in my eyes just a little less than the ones who don't ;)

Jonathan, don't oversimplify things by claiming to know my feelings on innerHTML from a single posting on the DOM Scripting Task Force blog.

For balance, here's something else I wrote on the subject:

http://domscripting.com/blog/display/35

Please don't paint such a black and white picture of me being "against" innerHTML unless I actually say "I am against innerHTML". Thanks.

Please read what I actually wrote and don't misrepresent me so blatantly. I said innerHTML was proprietary. I didn't use words like "wrong" or "bad".

Dustin... the same.

Jonathan, at the very same SXSW presentation you mention, I stated that innerHTML is much quicker than using DOM methods.

Yes, I use words like "heavy-handed" and "sledgehammer" to describe innerHTML because I think they accurately describe it. That doesn't mean it's bad. They are accurate words. If you have something against sledgehammers, they might sound negative but what I'm striving for is accuracy.

innerHTML is fast, easy, proprietary and heavy-handed.

DOM methods are slower, long-winded, standardised and precise.

Now, which technology have I described with a negative spin and which technology have I described with a positive spin?

The answer to that question is entirely subjective and depends on where your particular priorities lie.

Both innerHTML and XMLHttpRequest are proprietary so I don't see what the big discussion is all about. Are we validating our JavaScript with the W3C now? They are both widely supported and there is no reason to believe that innerHTML may not receive the all important STANDARDS BLESSING some day. Use the one that makes the most sense for your application. Doing *that* will earn you *my* Standards Blessing and you'll probably feel better about your app at the end of the day. Fair enough?

Because it's totally inflexible. DOM allows for changing of things without having to completely reload content; this greatly both simplifies and empowers coding.

Seems obvious but:

From this article I got: http://slayeroffice.com/articles/innerHTML_alternatives/#intro

> It was when my favelets stopped working for people when they were invoked on application/xhtml+xml sites that I decided to wash my hands of it (and do a lot of re-coding).
> Since it's not a standard, it isn't terribly future proof. It's not supposed to work under the application/xhtml+xml MIME type that XHTML documents are supposed to be served under. (Firefox 1.5 changed this by allowing it for some reason)
># innerHTML is a string. The DOM is not a string, it's a hierarchal object structure. Shoving a string into an object is impure and similar to wrapping a spaghetti noodle around an orange and calling it lunch.
# It makes for some nearly illegible code in a lot of instances, with escaped quotes and plus signs all over the place appending data to the string, which in my opinion makes it difficult to maintain.

on the + side

># It's less verbose than DOM methods.
># It allows you to take arbitrary chunks of markup and drop them into a document without having to parse them.

you see!

There are situations when an HTML document is best represented as a complex tree structure. There are also situations where an HTML document is best represented as a linear stream of markup.

I love the DOM, but it's one of many different APIs for navigating a page, and it's not always the best. The fact that it's the only standard we have is unfortunate, but I'm not going to use the wrong tool for the job just because the better tool isn't as fondly-regarded.

Well, innerHTML has better browser support (in HTML pages). It also does not create invalid markup because the browser will make sure the output forms a valid DOM. In fact, it could be argued that the DOM methods let you create invalid markup.

As far as I know, the reason innerHTML will now work in XML pages is because it is being specified in the WHAT WG specs.

Eden, XMLHttpRequest is being specified by the W3C, see http://www.w3.org/TR/XMLHttpRequest/.

Finally, innerHTML is quite a handy trick to force Safari into repainting (a part of) the document.

I'm with Jonathon (not that taking sides is necessary!). While I enjoyed Jeremy Keith's SXSW presentation, the message was a little confusing. After recently beginning to use and appreciate innerHTML, the presentation led me to believe that it was the wrong way to go. Then one of the comments during Q&A was that the "right" way to do it was slow and not practical except in small doses.

Jeremy, also in the same presentation at SxSW, you can just hear it in your voice ;) It came off sounding bad like "never use innerHTML" and yea, sure you didn't say it... but c'mon now... I definitely got the impression. Don't forget the power of human interpretation. I am almost positive the rest of the crowd got the same feeling when you were comparing innerHTML versus DOM methods.

Anyway, aside from the matter, we'll discuss this matter a bit more at a bar in London ;)

Mark: the browser won't necessarily make sure that the output from innerHTML forms a valid DOM. It'll do whatever it does when confronted with that HTML in an ordinary page. IE certainly used to form an invalid DOM when presented with invalid HTML, and that's not changed as far as I'm aware?

Without getting into what everyone thinks Jeremy feels about innerHTML, here's my twopenneth. If you know that your code is only going to be accessed as HTML then I think innerHTML is a valid tool in certain circumstances. In fact I've just used it myself to write a block of HTML to an ActiveX object. In that example I had no reason to insert each node seperately, doubly so as I had no advance notice of what the HTML would be. innerHTML performs admirably in this instance. Elsewhere I have used the full power of DOM and been grateful for it.
Yes, inner HTML might not be valid and may never be part of the spec, but it is supported by the majority of browsers. We aren't talking blink tags here. Appropriate tool for each job I say, if it warrants a sledgehammer then I'll use it.

Whether to use innerHTML or the DOM really comes down to application and speed is definitely going to be a consideration.

I am also pretty sure that a lot of developers use innerHTML more out of laziness because they can't be bothered to write the code to build up the nodes required to insert a chunk of HTML via the DOM.

Stuart, apologies, I had forgotten to calculate IE into the equation. MOSe browsers should work as described though.

I've a feeling innerHTML, with a little tweaking, could be made a lot more reliable in regards to producing valid markup. It would be nice to see this going in a spec somewhere - I'm not sure about some of their other bits, but it sounds like the WHAT WG seem to be getting things right here. There's no denying straight DOM methods can be tedious to work with.

The whole idea of having good specs as standards is to enable working code. Validation against the specs takes a lot of the weight of the individual app developer. Some testing against various target clients (which might not be traditional browsers) is always going to be necessary, but the chances of success are greatly increased when everyone's reading from the same book.

The problem with innerHTML as it appears is that it allows authors to input potentially invalid or ill-formed code into a document which is, ideally, well-formed and valid.

Then I'm wondering if it's at all possible (and practical for all UAs and in a reasonable timeframe) to have a standardized version of innerHTML that would check the well-formedness of the input code and, possibly, its validity in regard to the DOCTYPE of the document.
If the code is rejected, false is returned and nothing happens. It could even be optional wether you want it valid+well-formed, just well-formed, or if you accept any kind of crap.

Call me a Candide, but I'm really wondering. Any gurus have an answer?

I think this discussion is academic. It is possible to write a parser in JS, which accepts XML like "<div><br /></div>" as argument and alters given node in an appropiate way. As prototyped function called 'innerHTML' you could use it like:

document.innerHTML("<div><br / ></div>")

Is it bad or good? Anyway it is slower than Browsers implementation of innerHTML. For Browsers without innerHTML I would code this parser, because HTML is more eyefriendly structured than:

var d = document;
d.appendChild(d.createElement("div").appendChild(d.createElement("br")));

whoa. Everyone seems rather polar about this.

My take -

a) proprietry techniques are part of the reality of web development, we cater to 'proprietry' flaws all the time, why not take some of the good?

b) Regardless, I still prefer the DOM approach. You're all supposed to be transfoming your XMLHttpRequest responses with some nice XSL right? Or are you using JSON? (Wait, that's not standardised either).

c) tool:task.

d) http://www-128.ibm.com/developerworks/xml/library/x-matters41.html#N10115 etc. A good developer doesn't spend time complaining about his tools - he makes it work, and does it as best he can.

This post a comment box is cool

I like to think that they are two different tools, which you use for different tasks.
The choice between innerHTML and DOM depends on the input. If you have a snippet of markup, which you want interpreted and insert into the document, I see absolutely no other sane choice than innerHTML.
On the other hand, getting a chunk of html-markup over the wire (From XmlHttpRequest most likely) is wrong in the first place. Why ? because HTML is view-data, and you should have transmitted model-data and left it for the client to transform that into view.
If you do the transformation programmatical, DOM would be most appropriate.
Then again, if for example, you use XSLT to generate the view, you'll end up with a chunk of markup, which ofcourse you'll insert through innerHTML.

I use innerHTML cause it's the one I remember the fastest. Being new to DOM scripting and all. But I've been told several times to use childNodes[x].nodeValue instead (or first/lastNode.nodeValue).

I think it works the same, doesn't it?

My main aversion to using InnerHTML is the alteration of the markup code that IE makes. It really frustrates me that IE actively changes the code when using InnerHTML to assign content to a node.

To demonstrate this, try this bit of code:

var div = document.createElement("div")
div.innerHTML = '<' + 'a href="test.html">test<' + '/a>'
// i had to break up the a tag so the comment rendering system wouldn't treat it as a real link ;-) not really required!
alert('InnerHTML: ' + div.innerHTML);

div = document.createElement("div")
var a = document.createElement("a")
a.setAttribute("href", "test.html")
a.appendChild(document.createTextNode("test"))
div.appendChild(a);
alert('DOM: ' + div.innerHTML);

If you run that in Firefox, you'll see that the code is entered exactly as desired, however in IE with InnerHTML it prepends the URL of the site to the href of the A tag. This can get very frustrating when, for example, using InnerHTML in a Content Management System that resides in a subdirectory of a site, yet is controlling content on the front page of the site. So a simple href to "test.html" would become "admin/test.html" (if the CMS is in admin/).

Frustrating.

Tom, IE might be changing the innerHTML when you request it, that is, it might be correct in the DOM but not in the returned string.

If it was correct in the DOM but not the returned string the second alert (where I set the content through the DOM) would be the same as the first.

In my earlier post this line:

div.innerHTML = 'test'

Should read

div.innerHTML = '[a href="test.html"]test[/a]'

(although I've used real tags in my code, not square brackets).

Pasting tags into comments was.. erratic. :-)

Oops, looks like the caffeine hadn't kicked in yet.

The approach that I have used when discussing the difference in usage for innerHTML and DOM with my students has been to treat innerHTML as an excellent way to append text to elements on their web pages.

Using the createElement, createAttribute, and appendChild methods reminds them to keep well-formed, valid xHTML in mind at all times.

I have seen issues with innerHTML not rendering attributes properly. This is avoided with the DOM methods.

I am a vocal supporter of standards. I've been stuck having to clean up the messes of other developers who did the bare minimum to make a page work in their personal favourite browser too many times.

So, I refuse to let my students get away with using markup or methods in their scripts that lead to a lack of appreciation for how standards have helped to clean up the mess that used to be the web.

Now, having said that, I realize that both approaches are attempts to solve a problem and neither one is the defacto standard. So, both are still acceptable on some level. innerHTML works effeciently and if left to the role of appending text to existing or newly created elements then that's great.

If, however, you want to alter the structure of a page, then use the methods that allow you to explicitly do so. We've moved on to xHTML so that paragraphs have to have a closing tag and it is not left up to the interpretation of the browser. Why not follow the same logic in our scripts? Tell the browsers exactly what elements to create and tell them exactly where to stick 'em...

Simplicity rules. I use innerHTML, as it seems faster and far quicker to code. Just like sometimes, I use XMLHttpRequest to fetch text rather than XML. Why parse or manipulate DOM if you don't absolutely have to?

After all, its a means to an end - that is, updating content.

There is a simple solution for those who use innerHTML because it's easier:

function ezAppend (element, string) {
	$(element).appendChild(document.createTextNode(string));
}

Sam, that won't work if you want to have tags inside your string (createTextNode will escape the string)

I don’t like innerHTML because if you do it in IE, there is a lag between the time IE will update its representation of the DOM tree. Thus, if you set HTML via innerHTML and then immediately attempt to access the nodes, they will not be there. Slightly frustrating if you are interfacing with another script that uses innerHTML. If you are in FireFox, innerHTML, the injected HTML will be fully parsed before FireFox continues.

Hi, I use innerHTML to create more space on the main page of blogspot. But when I move the Archives to another inner-page Blogger seems not able to track it down, i.e. no archives appear. Do you have any thoughts about this? Thanks a lot :) ^_____^

Welll...The DOM is used to parse HTML/XML to an objet structure so you can locate, extract and modify those objects. Very useful for that. If you just want to print some chunk of code to the page it is perfectly reasonable to use innerHTML. The browser will have to parse it internally anyway, so there's little point in parsing it yourself via DOM and then making the browser work twice since it will have to render your modified DOM.

it is a matter of purposes.

Here's why I don't use innerHTML:

[div id="foo"]
[a id="foo-head" href="..."]A link[/a]
[/div]

document.getElementById('foo-head').onclick = function()
{ alert("Hello."); return false; }
document.getElementById('foo').innerHTML += ' to [b]nowhere[/b].';

Once the foo DIV's innerHTML is modified, foo-head will be recreated, and the onclick property we set will be wiped out. Nothing will happen when the link is clicked.

Also, there's no easy way to reference the elements I put in with innerHTML. (e.g., if I wanted to put an onMouseOver event to the [b] in the example.)

Hi , Love your discussion! here are my 2 cents, I've been using innerHTML for 8 months and DOM methods for more than 18 months, but now mostly innerHTML, the time when I need to use DOM createElement is for example, inserting an LI in a certain index in an UL/OL that that container has a lot of LI's , or you can imagine other similar cases when a container tag is filled with structured nodes and you don't want to rewrite the whole sub tree, but just at specific location, and then! the newly created and newly inserted tag i would AGAIN use innerHTML to fill the new born tag.
other cases when i use DOM ( and innerHTML is USELESS) is when i need firstChild/nextSibling, i.e. to traverse the tree for the sake of doing eye candy ,e.g.:
var x=findParent(evt.target?evt.target:evt.srcElement
,'UL','myProperty','a_special_value'
);
/*function findParent would use parentNode+firstChild+nextSibling to get the job done: find the containg UL with certain conditions
*/
x.className='alternateStyle';

having said that, each (i.e. DOM vs. innerHTML) has its own purpose, and i dont think that i would feel easy to choose one of the two, in other words, both are good, if you know that, each tool is for its purpose!

and as for standards, I agree with hukl, if you have been long enough in the arena , then you'll appreciete why standards are good, coz there were days when the yen and the yan were tooo diffrenet to tolerate to write a cross browser library-of-function!

it should not be innerHTML vs. DOM
and innerHTML vs. standards,
i'd love to see innerHTML and XMLHttpRequest subsetOf w3c something!

hello again , this time i've got a question: in IE 6&7 i use xmlrpc in xmlhttp and the response would work 100%,i mean the response is fed into innerHTML of the srcElement, but in firefox the response string is truncated when the string is Very long, so feeding the response string (which is incomplete html fragment) would result in an unwant trashy page !
i've been trying to debug and trace why the response string is not complete, and for more than 10 days i still dont know why the string is truncated, please
please, if some one knows why this is happening in firefox1.5 and how to fix it, please inform me.
thank you!

I believe that your problem is related to Firefox's 4K limit on a node. Search for "split very long text nodes into multiple smaller text nodes" in the body of this link.

http://www.howtocreate.co.uk/tutorials/javascript/dombasics

Hope this helps.

From the sound of things, innerHTML will BECOME a standard in short order. It's faster, easier to code for in many instances, and developers would definitely prefer it if it was already a standard.

It has all the properties of a standard by popular demand.

Therefore, I say, use it! It works well now, and is likely to be included in the next spec anyway.

And, Stuart Colville: I just wrote code to build an entire calendar using 100% DOM API valid code, and it's so dog-slow now that I have to rewrite it to use innerHTML. It's not laziness, I see that I have no other option!

I think Jon is right! innerHTML or document.write, they are tools, who cares if like them or use them? Look: server will crash any time you use document.write!!!

Browsers need to get their act together and make DOM manipulation faster; rendering is complex. Tree manipulation is not.

I have to apologies for reposting on the same subject again, but English is not my first language and I have a lot of difficulties to express my ideas in the right way. I was not clear enough in my last post, so I will try again here:

There is a tendency among programmers to agonize and fret over things in programming. They go so far to define their personal LOVE or HATE to specific languages or tools inside a language. Those we call: Self-Appointed-Thought-Leaders or Gurus! Final goal for them is; to prove that one language or method is “morally bad”, so they need to plan, organize and execute a kind of “language revolution” to bring it down and exterminate it from public use... Yeah, it is that funny!

The only important thing for one language or method is: can we use it to achieve a goal...

Do you have any problems with the new versions of firefox 2.0 by using?

Quick question for you all. Have any of you had issues when using innerHTML that IE produces a runtime error when encountering a FORM tag in the innerHTML to be rendered? I am having the worst time with this. Works great in FireFox but throws a wobbly in IE. If I take out the form tag the innerHTML renders fine.

Thanks in advance,

Rico I'd have to agree with you, that is my same frusteration with innerHTML

I mean it's great if you just want to 'add something' to a node, but if you want to actually add something while keeping the current values, the current values disappear.

I'm a bit of a standards fanatic myself and I've been reading a lot about innerHTML. Here is the problem I have with not using it.

Say that you have a section of a page, a rather large section with many paragraphs and divisions and maybe a list.

Say that you want to take all of this and put in inside a new division, wrap a new division around a huge portion of the html.

To do this the standards way would require completely rebuilding the page, adding the required div and then putting everything back into it. With innerHTML I simply need to extract the current contents of the element in question, add the opening and closing div tags (concatenate them to the start and end of the string) and then set the innerHTML of the element in question to the new string.

The standard way of doing things does not sound like a realistic way to accomplish the goal. Especially when I have a deadline to meet. The non standard way will take me under a minute. The standard way could take days to program.

So, in some cases, even though I am a bit Obsessive Compulsive about standards I have to say that some of them are just unrealistic. HTML is a text document, the only thing that will be looking at my web pages is a browser. Why should I not treat it is as text?

XMLHttpRequest to DOM translation == innerHTML substitute (not as fast, of course): http://domaxh.sourceforge.net

There are some instances where one cannot use the DOM methods to alter the HTML. When the document is in 'designMode', one can only use the DOM to view the nodes and their respective values. One cannot use the DOM methods appendChild, removeChild, or replaceChild. The only way to alter the it is innerHTML;

innerHTML is fast and small footprint. Just what web pages SHOULD be... whats the point of optimising the graphics, slicing up images to load faster, etc if you're then going to load the interface down with a whole load of longwinded garbage.

innerHTML is a simple and obvious way to replace elements in a page... note that we're not talking about arbitrary sections, but well defined sections... special container DIVs set up for the purpose of holding content. Just like loading and unloading Plugin DLLs in a binary app.

Now, yes, the result can be malformed HTML. But ONLY if you INJECT BAD HTML. This has nothing to do with the method of switching these blocks in and out of the page... but in creating them in the first instance. Create them properly, and only inject them into container tags, and this problem goes away. Get anal about it and you can argue that notepad produces malformed HTML, so does PHP and so does too much beer.

The ONLY real problems with innerHTML are...

- Nobody has bothered to standardise it, possibly because...
- Theres more industry revenue in more complex schemas
- In the absence of a standard the UA vendors are making a collective ass of themselves again.

So, yes... it wipes out javascripts dynamic handlers tied to an object if you append code to the div (sometimes)
Yes, you cannot add to an IE table (sometimes)
Yes, the newly written objects are not immediately available under IE (sometimes)

Thats why we need a standard! What we need to do is lock Bill's team and the Mozilla team in a room and refuse to let them out till they've agreed on the best way of handling, preserving and refreshing HTML when the structure is altered.

...and, just to assist them both to reach the best possible solution... Bills team should be gagged and handcuffed to their chairs.

In principle there is bugger all wrong with innerHTML for most purposes.

-Gary

... Oh, actually, while they're at it they could also standardise on a method of creating the XMLHttpRequest object. There should be a standard structure for instantiation of such objects with a formalised specification regardless of the modules implementation.

THESE are the real problems my friends. Asshat UAs trying to run the whole show and then pin inconsistencies on the competition (You listening Bill?)

(Sorry about the double-post)

-Gary

innerHTML, I always run into problems with it. and javascript in general. but it is what is out there.

I jump between the two all the time. Some times it is easier to use the proper DOM methods, these can also be much faster if you use the clone() function and avoid creating nodes, which is IMHO a very slow way of doing something.

But then there is also the cases where it is better to use innerHTML. I would bet that the preview feature that is copying out what I write below is using innerHTML. Could you imagine trying to get that to work with DOM methods? Like I can type a link like this MySite and it shows up. If you use DOM, I would have to first use regular expressions to find out the node name, then the attributes, then the text in it. That would be so painful, you would not do it.

I jump between the two all the time. Some times it is easier to use the proper DOM methods, these can also be much faster if you use the clone() function and avoid creating nodes, which is IMHO a very slow way of doing something.

But then there is also the cases where it is better to use innerHTML. I would bet that the preview feature that is copying out what I write below is using innerHTML. Could you imagine trying to get that to work with DOM methods? Like I can type a link like this MySite and it shows up. If you use DOM, I would have to first use regular expressions to find out the node name, then the attributes, then the text in it. That would be so painful, you would not do it.

Я бы сказала о монументальности, грандиозности некоторых сюжетов. А назвала бы - "нефильтрованный реал". На мой взгляд, красота - это все-таки другое: лучшее, чистое, избранное, заставляющее трепетать и поражаться. Можно найти красоту во всем, но всё скопом - не есть красота. Имхо.

Я никак не смогла вставить рисунок в коментарий. Вставляю ссылку на рисунок а он не показывает его как рисунок. Что мне делатЬ?
Фотки беру отсюда - images.yandex.ru/yandsearch?text=snook.ca