Unable to reformat HTML document data with JavaScript

This site is best viewed in a modern browser with JavaScript enabled.

Unable to reformat HTML document data with JavaScript

John-L

I've made several attempts at getting this to work; all with no success.

<DIV ID="output">
[temporary]
</DIV>
<SCRIPT language="JavaScript">
/* var TAG = "SPAN>" */
   var TAG = "PRE>" 
   var NEW_LINE = "\n"  

/* var NEW_LINE = "&#10;" */    

   var temp = "one|two|three"
   var x = temp.split("|")
   document.getElementById("output").innerHTML = "<"+TAG
   for (var i = 0; i < x.length; i++) {
      document.getElementById("output").innerHTML += x[i] + NEW_LINE
   }
   document.getElementById("output").innerHTML += "</"+TAG    

</SCRIPT>

I'm trying to produce the following result page:

one
two
three

but haven't had success.

Perhaps you will see something that I am missing.

Thanks in advance for any help you may be able to provide.

toicontien

Beware of repeatedly assigning a new value to the innerHTML property that creates invalid HTML:

var element = document.getElementById(...);

element.innerHTML = "<div>";
element.innerHTML += "...";
element.innerHTML += "</div>";

As soon as element.innerHTML = "<div>"; is executed, an opening DIV element gets created, but no closing element exists. Some browser will auto close the element. Some will complain that you've created an unbalanced document tree.

Instead, concatenate a string of HTML and assign it to the innerHTML property at the end:

var element = document.getElementById(...);

var html =  "<div>";
html += "...";
html += "</div>";

element.innerHTML = html;

deathshadow

toicontien has it right -- it's also not a good idea to call innerHTML so much since it's slow, and no longer the recommended method (not that it ever was) for generating new DOM elements.

Might also help if you weren't using HTML 3.2 style uppercase and the long LONG LONG ago deprecated language attribute... also if you are declaring multiple VAR in a row, you only need to say VAR once and then comma delimit them.

This is how you're supposed to be doing that now:

<div id="output">
[temporary]
</div>

<script type="text/javascript"><!--

function flush(e) { while (e.firstChild) e.removeChild(e.firstChild); }

var
	d = document,

tag = 'pre',
newLine = "\r\n",
temp = 'one|two|three',

x = temp.split('|'),
out = d.getElementById('output'),
e = d.createElement(tag);

/*
	Adding the elements/content to the new tag BEFORE putting it on the DOM
	actually processes a hair faster.
*/
for (var i = 0; i < x.length; i++) {
	e.appendChild(d.createTextNode(x[i] + newLine));
}

/* empty div#output */
while (out.firstChild) out.removeChild(out.firstChild);

/* then add our new tag all nice and filled with content */
out.appendChild(e);

--></script>

innerHTML is a relic that in all but the RAREST of cases belongs in the past.

root

deathshadow... http://www.webdeveloper.com/forum/showthread.php?216897-to-innerHTML-or-not-to-innerHTML

Still in use.

deathshadow

@\.\ -- Just because something is still in use doesn't make it good practice -- People still sleaze out HTML 3.2 (or worse post 3.2 proprietary markup) and slap 4 tranny or 5 lip-service around it, doesn't make that good coding practice either.

innerHTML is slower, uses more CPU (and therein more battery) and forces a full page reflow/reparse. There are a whole slew of legitimate reasons not to use it, particularly when the DOM often makes it easier to deal with generating content from JS.

Particularly if you're just making a tag and stuffing text into it.

Though... wait, that thread you linked to seems to mostly be filled with posts agreeing with me on NOT using it. Yut da?

kumar011293

I did the same thing what you are asking about. I did it in the page - SBTET Result

xelawho

deathshadow;1337065 wrote:
Though... wait, that thread you linked to seems to mostly be filled with posts agreeing with me on NOT using it. Yut da?

wow... that's an interesting interpretation. The closest I can find to anybody on that thread actually agreeing with you is a few people saying (correctly) that innerHTML is not appropriate in SOME circumstances.

javascript is full of parallel approaches and the wise approach is to understand them all to be able to choose the best one for the situation at hand. The web is full of innerHTML vs. the DOM debates and for every speed test that you can cite that says one is faster you can find another that says the other is. Everybody's free to be as dogmatic as they like when writing their own code, but I prefer to go with the best tool in the toolbox.

deathshadow

xelawho;1337113 wrote:
wow... that's an interesting interpretation.

I'm well known for coming away from things with a different understanding than the masses. See why I think HTML 5, OOCSS, LESS, SASS, Bootstrap, jQuery, Yui, Dreamweaver, and a whole host of other things that are popular and trendy are a bunch of halfwit BS that I pity anyone who is forced to use because their boss only knows it as a sick buzzword, and have little if any pity for the people who are DUMB ENOUGH to use any of them by choice.

There will always be apologists defending outdated, outmoded and just crappy ways of doing things; innerHTML is just another item on the stack of bull in all but the rarest of cases; just like nyetscape 4 style accessing of form elements by name, using getElementxxx EVERY time you access something inside a loop or even in the same program (hence the idiocy of how jQuery does selectors), and the whole host of other 1990's practices that continue to plod on mindlessly to this day.

But sure, let's dial the clock back to the worst of the browser wars practices, after all that seems to be what HTML 5 is for, so why not have our JavaScript match?

Of course, JHVH forbid you actually say that --what with the thin skinned wussies who run to the nearest authority figure "WAH, WAH, SOMEBODY SAID SOMETHING NEGATIVE!!!" like 7 year olds on the playground.

-- edit -- which is not to say I won't use innerHTML either, as I said there are RARE cases where it can/should be used, a great example being when plugging content into an element that is NOT on the DOM yet, since it will be parsed, then you can attach it as a constructed node AFTER; since it is parsed separate from the reflow, it works just as fast if not faster than a pure DOM only solution -- so you're right, just another tool in the toolbox; the key is knowing when the negatives outweigh the positives... most of the time when there are negatives it's because of a whole bunch of endless pointless annoying string additions.

Be a lot more useful if JS strings were whitespace neutral like PHP ones are.