innerHTML mangles the xhtml

[oopaevah]

When using innerHTML to insert xhtml IE5+ mangles the xhtml completely.
For example it removes the quotes from attributes. It also does other
ridiculous things like on a <div> it will insert the enbedded
style="DISPLAY:BLOCK"! This is a documented feature you can find in
msdn.

Is there a way to disable this quite appalling feature?

[Martin Honnen]

oo******@yahoo.co.uk wrote:

When using innerHTML to insert xhtml IE5+ mangles the xhtml completely.
For example it removes the quotes from attributes. It also does other
ridiculous things like on a <div> it will insert the enbedded
style="DISPLAY:BLOCK"! This is a documented feature you can find in
msdn.

Is there a way to disable this quite appalling feature?

IE is known not to be able to handle XHTML as real XML, all it can do is
treat it as HTML. innerHTML is doing stuff which is allowed in HTML but
not in XHTML so you have just one more reason to avoid using XHTML, see
<http://www.hixie.ch/advocacy/xhtml>

--

Martin Honnen
http://JavaScript.FAQTs.com/

[oopaevah]

IE can render xhtml perfectly, otherwise we wouldn't be having the
welcome surge of web standards compliance, and besides xhtml is just
clean html anyway. Maybe I misunderstand your point can you elaborate?

If I put the same xhtml into the page manually it renders perfectly,
when I put it through innerHTML IE deliberately alters the markup prior
to rendering. Surely IE uses the same engine to display the original
xhtml I send from the server as it does to render innerHTML? Sounds
like innerHTML is useless to me and many web developers who need to use
xhtml.

[oopaevah]

I've done more testing. If I do an alert() on the innerHTML of a div
which contains normal static xhtml then it displays it mangled which
suggests that innerHTML is not the problem but IE's interpretation of
x/html is the problem which is probably what you meant.

If IE parses all structure elements prior to rendering to suit its own
rendering engine then no wonder it is slower than the likes of Firefox.

[Michael Winter]

oo******@yahoo.co.uk wrote:

IE can render xhtml perfectly
No, it can't. It asks users if they want to download XHTML documents. That
can hardly be described as rendering at all.
otherwise we wouldn't be having the welcome surge of web standards
compliance
We are experiencing a surge of authors jumping on the XHTML bandwagon with
no apparent idea that true XHTML is not viable at this time, mainly due to
the lack of support from Microsoft.

There is just as much non-semantic, bloated rubbish being pumped out now as
there always has been. The only difference is that now it might be written
in XHTML, and might pass automated validation. That doesn't necessarily
make it either standards-compliant, or truly valid.
and besides xhtml is just clean html anyway.
Nonsense. My HTML markup is just as 'clean' as anyone else's XHTML. More so
in some cases. HTML authors don't /have/ to quote all attributes, or use
optional opening and closing tags, but there's no reason why they can't.
Yes, XML enforces these things, but so can just a touch of personal
discipline (or a custom DTD, if that is too much to ask).
Maybe I misunderstand your point can you elaborate?
The vast majority of XHTML documents - the result of your 'surge' - are
transmitted incorrectly as HTML. Either the Content-Type header, or a META
element, will indicate text/html instead of application/xhtml+xml. User
agents dutifully respect what they're told and parse the markup as really
badly written HTML, not XHTML. This is why IE is seen to parse it, when in
reality, it doesn't at all; it just performs a lot of error correction.

A Google search will tell you all of this. Searching for application/xhtm
+xml will also probably raise some useful discussions.
If I put the same xhtml into the page manually it renders perfectly,
when I put it through innerHTML IE deliberately alters the markup prior
to rendering.
I would expect all user agents to perform some form of normalisation on
markup before attempting to run it through a parser. It might do things
like collapse white space, add or strip quotes, etc. Anything to make life
easier for the parser.
Surely IE uses the same engine to display the original
xhtml I send from the server as it does to render innerHTML?
IE doesn't understand XHTML so when it performs the preprocessing above, it
does things contrary to XML syntax rules.
Sounds like innerHTML is useless to me
Didn't Martin say that?
and many web developers who need to use xhtml.

I doubt that many Web developers /need/ to use XHTML at all.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[phil_gg04]

> It might do things like collapse white space,

Yes. IE does this even when you're changing the innerHTML of a <pre>
element, which is a disaster.

--Phil.

[Jim Ley]

On 18 May 2005 01:40:17 -0700, oo******@yahoo.co.uk wrote:

IE can render xhtml perfectly, otherwise we wouldn't be having the
welcome surge of web standards compliance, and besides xhtml is just
clean html anyway.
XHTML is not just clean HTML, it's built on completely different
foundations.
If I put the same xhtml into the page manually it renders perfectly,
when I put it through innerHTML IE deliberately alters the markup prior
to rendering.
no, all mark-up languages are simply a representation of a particular
infoset, you can serialise that infoset in lots of ways, in html, or
xhtml, or ... the innerHTML etc. properties are serialisations in
IE's format, that format is basically an HTML one - it is not an XHTML
one, and there is no reason why it should serialise its normalised
version of the infoset as XHTML.
Surely IE uses the same engine to display the original
xhtml I send from the server as it does to render innerHTML? Sounds
like innerHTML is useless to me and many web developers who need to use
xhtml.

You've yet to adequately explain why you, or anyone else would need to
use xhtml, and you've also failed to explain why you need the
normalised serialisation of the infoset in a particuly format -
neither of these things are ever likely to be a good idea, I've never
come across a situation without a better solution.

What's you situation?

Jim.

[Thomas 'PointedEars' Lahn]

<oo******@yahoo.co.uk> wrote [...]

IE can render xhtml perfectly,

No, it can *not*. What in fact is rendered is falsely error-corrected
HTML. A strong indication that IE does not support XHTML to date is
that it does not support (tries to download as file rather than
rendering it) the standardized MIME type for *plain* XHTML 1.0 (optional,
although that allowance is based on the same flawed compatility
guidelines as the error correction) and XHTML 1.1 (mandatory, i.e. MUST
NOT be served otherwise), application/xhtml+xml, while e.g. Gecko-based
UAs do.
PointedEars

[oopaevah]

Thanks for the replies everyone.. I learned a lot from what you've said
and it's spurred a load of research on my part..

IE is worse than I thought..

The reason I need to use xhtml is because of web standards. Some of our
customers are demanding web standards for good reason, and our
competitors provide web standards solutions so xhtml (and other web
standards aspects of development) makes business sense, faster
rendering in modern browsers, future proof markup etc.. As long as I
provide xhtml I am doing all I can and can only wait until ie catches
up.

[Michael Winter]

oo******@yahoo.co.uk wrote:

The reason I need to use xhtml is because of web standards.
When did HTML stop being a standardised Web technology? As I wrote in a
previous post, nothing makes HTML a lesser language. Nothing stops an
author from writing compact, semantic, and accessible markup in HTML. I
think you're just listening to hype.
[...] faster rendering in modern browsers,
Rendering XHTML as HTML is undoubtably slower in /any/ user agent as they
will all have to perform error correction. Yes, even Opera and Mozilla
perform error correction as you told them they're receiving HTML.

If you were serving XHTML as XHTML, then your argument is valid as an XHTML
parser can make certain assumptions about form that tag soup parsers
cannot. But, you're not.
future proof markup
HTML isn't going anywhere for a very long time.
[...] wait until ie catches up.

Even if Microsoft implements an XHTML parser in some future version, XHTML
will still fail to be viable as most of the user agents in use will still
only parse HTML.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[oopaevah]

You go your way I'll go mine.