innerHTML

P

PaPa

I'm not sure this is a javascript issue or an HTML issue. I notice
that when I extract the contents of a div using the innerHTML property
(?), that I wind up with a literal variable (?) which exactly matches
the contents of the div with one exception.

It seems that whenever the code includes a tag which uses the forward
slash against the closing bracket (say the break tag ..... />) that
the browser, or HTML, or javascript, or something else, removes the
forward slash.

I've tried this on safari, chrome, mozilla, and IE and they all seem
to do the same thing.

Can someone tell my why this is happening and if there is a way to get
around it?

Regards,
PaPa

Here is some code which demonstrates the issue.

<body >

<div id="test1">
<p>This is a test to see if the / symbol is recreated here </p>
<p> now we will add a break tag </p><br />
</div>

<script type="text/javascript">
var lit=document.getElementById("test1").innerHTML;
alert(lit);

</script>


</body>

In the alert box, you should see all the forward slashes in the
"test1" div, except for the forward slash in the br tag.
 
P

PaPa

I don't know what a "literal variable" is, but your assumption that the
innerHTML property holds the div contents exactly as you wrote them is
incorrect, and not only in the case of empty elements like <br/>. Try
this, for example (in an HTML document, not XHTML):

<div><table><tr><td>hello</table></div>

The innerHTML of the <div> will include the implicit <tbody> element as
well the closing tags for <td> and <tr>:

<table><tbody><tr><td>hello</td></tr></tbody></table>

innerHTML returns the parsed and modified HTML contents of an element,
the way the browser sees it.


Why do you want to get around it? In current browsers, even if your
document is XHTML, you can assign what you retrieved from one element's
innerHTML property to another element's innerHTML property without
errors. The contents will be automatically converted to a valid XHTML
fragment. You can even do something like this:

node.innerHTML = "<u><i>hey</u></i>";

which will automagically be fixed to "<u><i>hey</i></u>". Older browsers
like Firefox v1 or Safari v? did not support innerHTML as a setter in
XML documents, even though reading the value would work.

I don't think there's any way to get the literal markup contents of an
element, at least not through the DOM.

  - Conrad

Thanks for the reply Conrad.

The reason I want to get "around it" is that I am using the data to
show the code that actually exists in the div. I have created a
(rather labyrinthine) function that receives the data from the
innerHTML property(?) and transforms it into the raw XHTML so the
viewer can see the code that created the div.

Indeed, I have noticed that the tbody tag gets placed into the code,
as well as some other IE oddities like capitol letters etc. IE even
changes the order of attributes in one image tag that I have seen.

There is probably a much neater way to show a div, followed by the
code that created it. My function, repeated below, is kind of
complicated but it shows comments in red and, for the most part, it
seems to work. It just will not show those closing slashes.

Regards,
PaPa

function deco(x)
{

var lit_nr=x.length;
var br="&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;";
var br_nr=0;
var br_vec=new Array(br,br+br,br+br+br,br+br+br+br,br+br+br+br+br);
var z="";

for (j=0; j<lit_nr; j++){
if ((x.charAt(j)=="<")&(x.charAt(j+1)!="/")){
br_nr=br_nr+1;
z=z+"&lt;";
}

else if ((x.charAt(j)=="<")&(x.charAt(j+1)=="/")){
br_nr=br_nr-1;
if (br_nr<0){br_nr=0;}
z=z+"<br />"+br_vec[br_nr]+"&lt;";
//ff=1;
}

else if ((x.charAt(j)==">")&(x.charAt(j-1)!="/"))//is this a xxx>
{
if(x.charAt(j-1)=="-")//is this end of comment
{z=z+"&gt;</span><br />"+br_vec[br_nr];}
else if((x.charAt(j+1)=="<")&(x.charAt(j+2)=="!"))//is a comment
next
{z=z+"&gt;<span class='emph'>&lt;!";
j=j+2;}
else
{
z=z+"&gt;<br />";
//if (ff==1){z=z+"<br />";
//ff=0;
//}
z=z+br_vec[br_nr];
}



}

else if ((x.charAt(j)==">")&(x.charAt(j-1)=="/")){
z=z+"&gt;<br />";
br_nr=br_nr-1;
}

else {z=z+x.charAt(j);}
}
return z;
}
 
T

Thomas 'PointedEars' Lahn

PaPa said:
[...] In current browsers, even if your document is XHTML, you can
assign what you retrieved from one element's innerHTML property to
another element's innerHTML property without errors.

Of course you cannot. That is only possible when the XHTML markup
is not regarded XHTML but tag soup in the first place.

It is not a matter of the browser but of the used markup parser. But even
if writing or reading the property would work there, it would accomplish
nothing useful, given that the languages in question are largely incompatible.
I don't think there's any way to get the literal markup contents of an
element, at least not through the DOM.
[...]

It is possible.
Thanks for the reply Conrad.

Thanks for trimming your quotes next time, especially for not quoting
signatures anymore.

The reason I want to get "around it" is that I am using the data to show
the code that actually exists in the div. I have created a (rather
labyrinthine) function that receives the data from the innerHTML
property(?) and transforms it into the raw XHTML so the viewer can see
the code that created the div.

Since the property is called `innerHTML', and not `innerXHTML', on purpose,
and the parsing of `<br/>' like `<br>' by tag-soup parsers is merely based
on false error-correction (correct would have been to parse it the same as
`<br>&gt;'), you cannot solve this with `innerHTML'.

Existing editors have either attempted to correct the false result of
error-corrected markup to XHTML back again (which would involve rather
extensive user-defined parsing), or employed an XML serializer if the
content really is an XHTML fragment.
[...]
[atrocious code snipped]

No, thanks.


PointedEars
 
P

PaPa

Thanks Conrad and Thomas,

You've helped me understand how much work I have to do. And thanks
for the tip on TagSoup. I had never heard of that and it looks like a
tool that I might use if I can figure out how to use it.

Regards to both,
PaPa
 
D

David Mark

[...] In current browsers, even if your document is XHTML, you
can assign what you retrieved from one element's innerHTML
property to another element's innerHTML property without errors.
Of course you cannot.  That is only possible when the XHTML markup is
not regarded XHTML but tag soup in the first place.

Did you actually test that? Then give me a counter example where you get

No need. He is right (at least in the case of several major
browsers.) Don't use innerHTML with an XHTML DOM.
an error when at 'node2.innerHTML = node1.innerHTML'. And yes,

Try it in an XHTML document (a real XHTML document.)

definitely is possible in valid XHTML documents.

Certainly it would have to be a valid XHTML document. You can't even
see invalid ones.
There are a number of caveats, of course: copying content in this way
may lead to duplicate id attributes; setting innerHTML on an img element
isn't going to do anything useful; inserting the innerHTML of a tbody
into a div won't create table rows there; etc. But you get the point.

Those are not the issue at hand.

Did you test that?
I was under the impression that the same parser was used for both HTML
and XHTML, only running in different modes. And you can verify for

Aha! Therein lies the basic misconception.
yourself that using innerHTML as a setter in XHTML documents does in
fact work. Whether you think that's "useful" is up to you.

You only thought you were using XHTML and it isn't useful.
I assume (without having checked the source), that the value returned by

Always a bad move.
innerHTML will never be a "tag soup", but the browser's parsed and
prepared representation of the source (X)HTML. The other way around,

Sort of.
when using innerHTML as a setter, the engine will do its best to convert
whatever it's given to a valid (X)HTML fragment.

More or less. Except when XML parse mode is in use and then the
browser will likely deny your request with an exception.

[snip]
It appears that in current implementations the methods that implement
innerHTML are aware of the document language, and are transparently
converting between HTML and XHTML. At the time when Microsoft created
innerHTML, XHTML was still a few years away from being a standard, which
would explain the name and the way it behaves.

You are lost. In FireFox 3, Tools | Page Info, second item (type.)
What does it say on every page you ever tested with innerHTML?
 
T

Thomas 'PointedEars' Lahn

PaPa said:
Thanks Conrad and Thomas,

You've helped me understand how much work I have to do.

You are welcome.
And thanks for the tip on TagSoup. I had never heard of that and it
looks like a tool that I might use if I can figure out how to use it.

ISTM you are confusing things. AFAICS nobody here recommended TagSoup.

So, JFTR:

"Tag soup" is _not_ a tool, it is Web developer jargon for markup (made up
of tags and normal text in between) that may superficially look like HTML or
XHTML (and may even be Valid), but is not parsed according to SGML or XML
rules by parsers of user agents (in order to facilitate best possible
rendering of markup that is not Valid despite that fact).

With content served with `Content-Type: text/html', tag-soup parsing is many
user agent's default parsing mode (which is why serving XHTML as text/html
is usually pointless and considered harmful; there are known exceptions).

Nevertheless, using Valid markup reduces the effort a UA has to put into
error-correction which results are potentially inconsistent among different
UAs, and it is therefore considered a Good Thing.

<http://en.wikipedia.org/wiki/Tag_soup>


TagSoup, on the other hand, is a SAX-compliant parser written in Java
(_not_: JavaScript) that can parse tag-soup markup. I am not sure how it
could be of help with your problem.

<http://www.ccil.org/~cowan/XML/tagsoup/>


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,756
Messages
2,569,535
Members
45,008
Latest member
obedient dusk

Latest Threads

Top