innerHTML

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>
<pnow 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.

Oct 12 '08 #1

Follow Post Reply

3996

Conrad Lender

On 2008-10-12 17:05, PaPa wrote:

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 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 <divwill include the implicit <tbodyelement as
well the closing tags for <tdand <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.

Can someone tell my why this is happening and if there is a way to get
around 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

Oct 12 '08 #2

Thomas 'PointedEars' Lahn

PaPa wrote:

On Oct 12, 11:47 am, Conrad Lender <crlen...@yahoo.comwrote:
>[...] 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.

>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.

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.

<http://jibbering.com/faq/#FAQ2_3>

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>>'), 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
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

Oct 12 '08 #3

Conrad Lender

On 2008-10-12 19:03, Thomas 'PointedEars' Lahn wrote:

>>[...] 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
an error when at 'node2.innerHTML = node1.innerHTML'. And yes,
definitely is possible in valid XHTML documents.
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.

>>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.

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 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
yourself that using innerHTML as a setter in XHTML documents does in
fact work. Whether you think that's "useful" is up to you.

I assume (without having checked the source), that the value returned by
innerHTML will never be a "tag soup", but the browser's parsed and
prepared representation of the source (X)HTML. The other way around,
when using innerHTML as a setter, the engine will do its best to convert
whatever it's given to a valid (X)HTML fragment.

>>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.

How?

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>>') [..]

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.
- Conrad

Oct 12 '08 #4

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

Oct 12 '08 #5

David Mark

On Oct 12, 3:50*pm, Conrad Lender <crlen...@yahoo.comwrote:

On 2008-10-12 19:03, Thomas 'PointedEars' Lahn wrote:

>[...] 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.

>

>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.

Did you test that?

>
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 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?

Oct 13 '08 #6

Conrad Lender

On 2008-10-12 21:50, Conrad Lender wrote:

>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
an error when at 'node2.innerHTML = node1.innerHTML'. And yes,
definitely is possible in valid XHTML documents.

Yikes, did I really write that? I did some more testing with other
implementations, and there will in fact be errors. That makes three
mistakes in a single paragraph, two grammatical and one factual, so...

....please disregard the whole post. Using innerHTML as a setter in XML
documents is not a good idea.
- Conrad

Oct 13 '08 #7

This discussion thread is closed

Similar topics