Post by Schubaltz on Apr 5, 2008 15:29:02 GMT -5
Seems to me that innerHTML is getting a bad rep these days. So, in an attempt to understand why, I recently did a google search. As I expected, though, the closest I got to an explanation was far from reasonable. It was an article by a guy named Dan Simmard, who claimed it was "dirty", abundant, and impractical. Believe it or not, I disagree on all points.
"innerHTML is dirty"
I don't know if this is worth the go-over, but what the hell. Reason number 1? Too many \". Talk about knit-picking. I don't like typing out getElementsByTagName or createDocumentFragment, but I don't refuse to use them because of it. And it's not like you can't get around it to a degree, by alternating single and double quotes. In fact, someone mentioned that in a comment about the article. And the author himself said he simply doesn't like single quotes. Sounds like a personal problem to me. Oh, and just for the fun of it, his DOM example in this section has a syntax error.
"A lot of HTML"
Too much looks bad? Too many createElements and appendChilds look bad. And hopefully you'll never have to go to the extreme of writing an entire webpage in innerHTML, so it's not a problem.
"innerHTML and ajax"
Alright, this is just rediculous. For one, why use innerHTML on an object the property wasn't designed for? Secondly, i'd think the person writing the application would know what they want the AJAX to return. Do with the data what you want. His argument is that you'll want to do something different. Not always. And it's not as though you can't assign the return value and a property of the return value. I honestly don't know why this is even part of the argument. You could run into that same "problem" with a load of other things, innerHTML aside.
"It is not standard"
If everything were standard, there'd be no cross-compatibility issues, no companies would compete, and there'd be world peace. But there isn't. In almost everything you do, there are corners to cut with cross-compatibility. Especially with AJAX, something Dan just mentioned in his article. This mindset basically says, i'm using standards and if your browser doesn't like it, you're out of luck. Just imagine the chaos over something like that. No browser is completely standards-compliant. Nothing would ever work. Ever. Now, on the other hand, if every standards-compliant property was as efficient and multi-platform as innerHTML, there'd be something to this reasoning. But there isn't.
I could write dozens of articles on why not to use properties because they don't work well in certain cases. But that's why we have several properties anyway. They all serve their own purpose. I'm not calling out getElementById because I can't grab an element node by it's tagName with it.
"innerHTML is dirty"
I don't know if this is worth the go-over, but what the hell. Reason number 1? Too many \". Talk about knit-picking. I don't like typing out getElementsByTagName or createDocumentFragment, but I don't refuse to use them because of it. And it's not like you can't get around it to a degree, by alternating single and double quotes. In fact, someone mentioned that in a comment about the article. And the author himself said he simply doesn't like single quotes. Sounds like a personal problem to me. Oh, and just for the fun of it, his DOM example in this section has a syntax error.
"A lot of HTML"
Too much looks bad? Too many createElements and appendChilds look bad. And hopefully you'll never have to go to the extreme of writing an entire webpage in innerHTML, so it's not a problem.
"innerHTML and ajax"
Alright, this is just rediculous. For one, why use innerHTML on an object the property wasn't designed for? Secondly, i'd think the person writing the application would know what they want the AJAX to return. Do with the data what you want. His argument is that you'll want to do something different. Not always. And it's not as though you can't assign the return value and a property of the return value. I honestly don't know why this is even part of the argument. You could run into that same "problem" with a load of other things, innerHTML aside.
"It is not standard"
If everything were standard, there'd be no cross-compatibility issues, no companies would compete, and there'd be world peace. But there isn't. In almost everything you do, there are corners to cut with cross-compatibility. Especially with AJAX, something Dan just mentioned in his article. This mindset basically says, i'm using standards and if your browser doesn't like it, you're out of luck. Just imagine the chaos over something like that. No browser is completely standards-compliant. Nothing would ever work. Ever. Now, on the other hand, if every standards-compliant property was as efficient and multi-platform as innerHTML, there'd be something to this reasoning. But there isn't.
I could write dozens of articles on why not to use properties because they don't work well in certain cases. But that's why we have several properties anyway. They all serve their own purpose. I'm not calling out getElementById because I can't grab an element node by it's tagName with it.
