Adding XML from an XMLHttpRequest to current document in IE

[Ian Collins]

Is there a way to do this in IE?

In Firefox, one can simply append a node from an XML return to the
current document. IE whinges about 'No such interface supported'

--
Ian Collins.

[Martin Honnen]

Ian Collins wrote:

Is there a way to do this in IE?

In Firefox, one can simply append a node from an XML return to the
current document. IE whinges about 'No such interface supported'

Note that according to the W3C DOM you should not simply move nodes from
one document to the other but rather use importNode e.g.
someNode.append Child(
someNode.ownerD ocument.importN ode(
nodeFromSecondD ocument,
true
)
)
Mozilla allows you to get away without using importNode but Opera
requires that and is closer to the W3C specification that way.

As for IE, no, the XML DOM in IE is not implemented by IE itself but
rather the COM component MSXML and you can't move or import nodes
between the HTML DOM that IE (or internally MSHTML) implements and the
XML DOM that MSXML implements.

You would have to write your own importNode that walks the XML DOM tree
and then recreates nodes in the HTML DOM using document.create Element
and other node creating methods.

Or you let the HTML parser of IE do its work by feeding responseText to
innerHTML of an HTML element for instance.


--

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

[Duncan Booth]

Martin Honnen wrote:

You would have to write your own importNode that walks the XML DOM tree
and then recreates nodes in the HTML DOM using document.create Element
and other node creating methods.

Or you let the HTML parser of IE do its work by feeding responseText to
innerHTML of an HTML element for instance.

Or use Sarissa which already has a working implementation of importNode for
IE.

Interestingly the author of Sarissa (Manos Batsis) found that using
document.create Element was much slower than using innerHTML, so he
serializes the XML DOM node and feeds that to innerHTML.

[Ian Collins]

Martin Honnen wrote:

Ian Collins wrote:

Is there a way to do this in IE?

In Firefox, one can simply append a node from an XML return to the
current document. IE whinges about 'No such interface supported'

Note that according to the W3C DOM you should not simply move nodes from
one document to the other but rather use importNode e.g.
someNode.append Child(
someNode.ownerD ocument.importN ode(
nodeFromSecondD ocument,
true
)
)
Mozilla allows you to get away without using importNode but Opera
requires that and is closer to the W3C specification that way.

Thanks, I hadn't looked at the Opera implementation. I had tried
importNode with FF and found it to work.
As for IE, no, the XML DOM in IE is not implemented by IE itself but
rather the COM component MSXML and you can't move or import nodes
between the HTML DOM that IE (or internally MSHTML) implements and the
XML DOM that MSXML implements.
Yuck, what a waste. Kind of makes XML data redundant.
You would have to write your own importNode that walks the XML DOM tree
and then recreates nodes in the HTML DOM using document.create Element
and other node creating methods.
I'd been doing this when realised what a waste of time it was.
Or you let the HTML parser of IE do its work by feeding responseText to
innerHTML of an HTML element for instance.

I think I'll stick with JSON.
--
Ian Collins.

[Ian Collins]

Duncan Booth wrote:

Martin Honnen wrote:

You would have to write your own importNode that walks the XML DOM tree
and then recreates nodes in the HTML DOM using document.create Element
and other node creating methods.

Or you let the HTML parser of IE do its work by feeding responseText to
innerHTML of an HTML element for instance.

Or use Sarissa which already has a working implementation of importNode for
IE.

Interestingly the author of Sarissa (Manos Batsis) found that using
document.create Element was much slower than using innerHTML, so he
serializes the XML DOM node and feeds that to innerHTML.

Thanks Duncan, I'll look at that.

I wonder how performance compares with JSON, or simply receiving the XML
as text to avoid the serialisation.

--
Ian Collins.

[Ian Collins]

Duncan Booth wrote:

Interestingly the author of Sarissa (Manos Batsis) found that using
document.create Element was much slower than using innerHTML, so he
serializes the XML DOM node and feeds that to innerHTML.

I can see why, if you call document.create Element() in IE, the resulting
element has 79 attributes with a value of 'null'. Must be creating an
attribute node for each of these...

--
Ian Collins.

[Duncan Booth]

Ian Collins wrote:

Duncan Booth wrote:

Interestingly the author of Sarissa (Manos Batsis) found that using
document.create Element was much slower than using innerHTML, so he
serializes the XML DOM node and feeds that to innerHTML.

I can see why, if you call document.create Element() in IE, the resulting
element has 79 attributes with a value of 'null'. Must be creating an
attribute node for each of these...

Not quite. When you create an element in IE it doesn't create all those
empty attributes until you access the 'attributes' collection. If you stick
to getAttribute/setAttribute and avoid accessing 'attributes' you can get
big performance improvements.

Kupu used to do content filtering by iterating over the attributes
collection on each node when you saved, and only keeping those attributes
which weren't banned and were non-null. I changed it to have a whitelist of
valid attributes for each tagname, and testing each of those attributes for
existence using getAttribute(). I expected a speedup of maybe 10-fold since
the whitelist meant it was only processing about 10th as many attributes,
but in fact it was closer to 100 times faster, I think because IE was no
longer creating the attributes object at all.

What I think it does show is that although IE exposes a DOM interface,
internally it does everything with totally different data structures. There
are plenty of other indications of this: create an HTML page with a <base>
tag followed by the <body> tag, then have a look at the base element's
firstChild and nextSibling: they will both be the body element.

Another fun one is the sequence <font><p>text </font></p>: the <p> element
is both firstChild and nextSibling of the <font> element. You might not
think it matters (after all the HTML was invalid in the first place), but
if you paste into a contentEditable area some text copied from Microsoft
Works (or some other MS applications), the rich text on the clipboard gets
converted to exactly that 'HTML' by IE, so an editor based on
contentEditable has to be able to handle (and ideally clean-up) such
situations.

Both of these indicate that the internal structure used by IE is pretty
close to the unparsed HTML and the DOM nodes are simply providing a view
onto the much less structured HTML.

[Ian Collins]

Duncan Booth wrote:

Ian Collins wrote:

Duncan Booth wrote:

Interestingl y the author of Sarissa (Manos Batsis) found that using
document.cre ateElement was much slower than using innerHTML, so he
serializes the XML DOM node and feeds that to innerHTML.

I can see why, if you call document.create Element() in IE, the resulting
element has 79 attributes with a value of 'null'. Must be creating an
attribute node for each of these...

Not quite. When you create an element in IE it doesn't create all those
empty attributes until you access the 'attributes' collection. If you stick
to getAttribute/setAttribute and avoid accessing 'attributes' you can get
big performance improvements.

I see, I was using node.attributes .length rather than
node.hasAttribu tes() (missing in IE?), so I guess I was making a rod for
my own back. Kind of hard to tell if an element has attributes without
invoking this behaviour though.

--
Ian Collins.

[Duncan Booth]

Ian Collins wrote:

Duncan Booth wrote:

Not quite. When you create an element in IE it doesn't create all
those empty attributes until you access the 'attributes' collection.
If you stick to getAttribute/setAttribute and avoid accessing
'attributes' you can get big performance improvements.

I see, I was using node.attributes .length rather than
node.hasAttribu tes() (missing in IE?), so I guess I was making a rod
for my own back. Kind of hard to tell if an element has attributes
without invoking this behaviour though.

If you know what attributes you expect you can call getAttribute and
skip the ones which are null or the default value for the attribute, but if
you've been setting attributes with arbitrary and unknown names there is
nothing for it but to use the attributes collection and take the penalty.

I'm pretty sure that once you've access the attributes collection on a node
once it doesn't recreate it for subsequent accesses, so this only really
bites if you need to iterate through the entire DOM.