Javascript/DOM gurus: td.innerHTML contents not showing formatting..

[aceO07]

I'm using js to copy the innerHTML of another element that has formatting in it (pagraph, strong, underline) but when it displays, it shows the literal tags. If I use firebug and examine the element that it got copied into, it looks fine there isn't any escaped characters. If I use firebug and alter the innerHTML contents a bit, add a space and then remove it, it will display the formatting fine and not display the literal tags for formatting.

Any idea on how I can get around this problem?

example:
If I use javascript to copy
(td)This is bold(/td) innerHTML into another (td) element, it would display as
(td)This is (b)bold(/b)(/td).

 

[PhatoseAlpha]

That's odd. Copying seems to work just fine for me. Those (s are really < right? I'm sure that are, but always check.

Got a sample page we can see the behavior on?

 

[aceO07]

Unfortunately I can't provide actual code, since it's not on a public server. If you're really curious, I'm using TinyMCE (WYSIWYG js editor) with ajax. I pull up the TinyMCE editor when I need to edit and upon saving/cancel I hide it and replace with updated text. For saving it's easy since I just call the server to send back new text to place into the (td) element, but for canceling I want to avoid having to call the server again, so I just pull the text out of the hidden field that TinyMCE uses. The fields I'm describing are below, though the text is shortened. Yes, the () are really <>.

Source:
(td id='ph_9')(textarea id="phrasearea9" class="tiny_mce" style="display: none;")(p)Our Firm,(strong) Our Mission(/strong) Build(em) and preser(/em)ve > Our People(/p)(/textarea)(other elements and misc..)(/other elements and misc..)(/td)

Target:
(td id='ph_9')(/td)

JS Code:
this.parentNode.parentNode.innerHTML = document.getElementById('phrasearea'+ph_id).innerHTML
^This is essential (td id='ph_9') element. I go back a few parentNodes due to the location of the Cancel button that the code is attached to. It's strange since it's not that the code doesn't work, but it doesn't display properly after the field is updated.

 

[aceO07]

I'm using Ruby on Rails and viewing on Firefox v2. That shouldn't matter though since the only running code is the js when I invoke it from the Cancel button.

 

[PhatoseAlpha]

Ah, I see. The problem is that the source is a textarea. Tags in a textareas inner HTML are not treated like they are in other areas.

I'm looking into solutions.




EDIT: Try this. No guarantees.




this.parentNode.parentNode.innerHTML = document.getElementById('phrasearea'+ph_id).innerHTML .replace( /&amp;gt;/g, "<").replace(/&amp;lt;/g, ">");



Final: If you cut and paste, be sure it comes through the way it looks, with the ampersand symbol, not the escape sequence for the ampersand.

 

[aceO07]

Thanks PhatoseAlpha. I never knew that. I'll try it out tomorrow.

 

[aceO07]

hm.. The code didn't work as expected. The strange thing is that the escaped sequences are just within the text, and not the tags themselves. When I inspect the newly populated (td) it will so the proper < > characters for the formatting tags. The only escaped chars are the ones within the text, which is purely text.

For example, in the textarea:
Our Firm, Our Mission Building and preserving through: > A sole focus Our People

Becomes this when the textarea innerhtml is copied:
(p)Our Firm, (b)Our Mission(/b) Build(i)ing and preserving(/i) through: > A sole focus Our People(p)

The formatting tags seem to be correct and not escaped. The non tag < is escaped.. If I alter the newly copied text a bit (as little as removing any char and putting it back) in firebug and it refreshes, it will display it properly as in the original.

 

[PhatoseAlpha]

Can I recommend you do a simple little thing just to see what you're actually getting, without any possible interference from firebug or the browser? Copy the innerHTML to a string variable, then alert the variable, just to be sure there's no whacky interference going on.

 

[aceO07]

Thanks for the tip. Somehow it does get messed up. They(the element tag <> chars) are escaped. Somehow the > that are just text is also getting doubly escaped. I guess I just need to mess with the replace example you gave before and get it to work. It was replacing too much stuff before.

 

[aceO07]

double posted.. oops. end of the day. brain shutting dowwnn..

 

[kamper]

Why not use the DOM instead of innerHTML?

 

[aceO07]

Originally posted by: kamper
Why not use the DOM instead of innerHTML?

DOM instead of innerHTML? What do you mean? How's the different from what I've been doing? I'm a bit of a js/dom newbie.

(I actually haven't really had a chance to look back on this problem for a few days.)

 

[troytime]

DOM (document object model) would be more like:
document.YOURFORMNAME.YOURINPUTNAME.value (or something like that, i haven't used it in quite a while)

that would be used instead of document.getElementById('phrasearea'+ph_id).innerHTML

 

[nakedfrog]

Perhaps usage of the javascript command eval might help? I'm not sure.

 

[PhatoseAlpha]

Hm. Wait, I think there may be a more obvious solution. There is an element and a backup copy, yes? And one is getting edited. The backup copy is stored in a hidden text field on a form, which is what creates the problems.

Can you simply copy the element itself into a variable before any editing takes place, and use that as your backup? IE...


var Backup;

function BeginEdit()
{
Backup = $('MyElement').innerHTML;
}

function AbortAbortAbort()
{
$('MyElement').innerHTML = Backup;
}

 

[aceO07]

Originally posted by: PhatoseAlpha
Hm. Wait, I think there may be a more obvious solution. There is an element and a backup copy, yes? And one is getting edited. The backup copy is stored in a hidden text field on a form, which is what creates the problems.

Can you simply copy the element itself into a variable before any editing takes place, and use that as your backup? IE...


var Backup;

function BeginEdit()
{
Backup = $('MyElement').innerHTML;
}

function AbortAbortAbort()
{
$('MyElement').innerHTML = Backup;
}

Sorry for the late reply. Yup, I eventually did something like that. I stuck a copy into a hidden input field instead. This is generated when the html is produced. Thanks though. I didn't realize or remember that JS has variables.

 

[kamper]

Originally posted by: troytime
DOM (document object model) would be more like:
document.YOURFORMNAME.YOURINPUTNAME.value (or something like that, i haven't used it in quite a while)

that would be used instead of document.getElementById('phrasearea'+ph_id).innerHTML

No, DOM would be more like:

while (sourcenode.hasChildNodes()) targetnode.appendChild(sourcenode.firstChild);

Taking the innerHTML serializes a chunk document to a string and assigning it unserializes it again but there are properties of those nodes that get lost/confused in the process, as the op is experiencing. Moving them over unchanged should preserve things properly (or so I hope, I haven't tested this particular case).

 

[troytime]

Originally posted by: kamper

Originally posted by: troytime
DOM (document object model) would be more like:
document.YOURFORMNAME.YOURINPUTNAME.value (or something like that, i haven't used it in quite a while)

that would be used instead of document.getElementById('phrasearea'+ph_id).innerHTML

No, DOM would be more like:

while (sourcenode.hasChildNodes()) targetnode.appendChild(sourcenode.firstChild);

Taking the innerHTML serializes a chunk document to a string and assigning it unserializes it again but there are properties of those nodes that get lost/confused in the process, as the op is experiencing. Moving them over unchanged should preserve things properly (or so I hope, I haven't tested this particular case).

apparently we're talking about two different DOMs

 

[kamper]

There's only one DOM. It's a formal api specified by the w3c for manipulating xml documents (or html in this case, which is similar enough). We're talking about the same objects but you are using html-specific additional properties. As far as I can tell, the forms being direct properties of the document by name isn't part of the w3c standard although document.forms['formname'] would be. Ditto for the inputs as members of the form element.

 

[PhatoseAlpha]

Meh. Unless the DOM is seriously messed up anyway, none of that would've helped him - data entered into a text field in a form isn't going to become part of that DOM, except in it's raw string form, which is escaped as noted.

 

[troytime]

Originally posted by: kamper
There's only one DOM. It's a formal api specified by the w3c for manipulating xml documents (or html in this case, which is similar enough). We're talking about the same objects but you are using html-specific additional properties. As far as I can tell, the forms being direct properties of the document by name isn't part of the w3c standard although document.forms['formname'] would be. Ditto for the inputs as members of the form element.

i was being sarcastic

document.formname is a shortcut for document.forms['formname']

i haven't touched this type of stuff in at least 2 years though

 

[kamper]

Originally posted by: PhatoseAlpha
Meh. Unless the DOM is seriously messed up anyway, none of that would've helped him - data entered into a text field in a form isn't going to become part of that DOM, except in it's raw string form, which is escaped as noted.

Data entered into the text field should appear in the dom as the "value" attribute of the element that represents the textarea: http://www.w3schools.com/htmld...rop_textarea_value.asp (edit: hmm, well logic dictates that it should show up as a text element as a child of the textarea too, but I'm too lazy to test it out)

It does work better with the dom: http://kamper.ca/stuff/dom.html (at least in firefox)

Originally posted by: troytime
i was being sarcastic

Sorry, sarcasm-meter must have been broken