XSLT transform of XHTML page content in Internet Explorer

[Pete Verdon]

Summary: Can I do an XSLT transform, in the client, of a tree of nodes
taken from the displayed page DOM in IE? This works in Firefox.

Hi,

I'm just starting the process of rewriting part of a "database frontend"
type of intranet application. The existing table-display code consists
of a mountain of very clever but extremely brittle spaghetti-javascript,
which I'm planning to replace with XSLT transformations. At present I'm
still prototyping things to make sure that everything I want to do is at
least possible.

The display part of the problem is essentially solved (just a Simple
Matter of (XSLT) Programming(tm)), but editing is a little trickier. The
existing app has in-place editing in all the tables - click a button and
the text in the cells is replaced with (filled) textboxes which can be
edited. This I've done less prototyping on, but believe to be fairly
simple - just run the original XML through a different stylesheet to
produce editing widgets instead of text. The problem comes with saving
the data.

At present, the save can be fairly glitchy, as everything that's changed
has to be kept track of in Javascript. This technique would only get
worse with my plans for new and more sophisticated ways of editing the
data in the page. So what I want to do instead is to generate the "save"
message (already exists, currently generated as an XML string by the
Javascript(!)) by comparing, in XSLT, the original data XML and the
current in-page DOM. Thus any and all changes, whether made by hand
editing or by arbitrarily-complicated Javascript DOM updates, will be
captured, and there is no backing store to get out of sync with what the
user can see. Put the data in the page -> change it -> find the
differences -> transmit them.

As a first stage of prototyping, I've tried putting part of the page DOM
(the contents of a div, originally generated by XSLT as it would be in
the scheme above) through a trivial XSLT transform. This works perfectly
in Firefox (well, except that my XSLT-fu is still a little weak, but
that'll improve ) but fails in IE. As far as I can see, this is
because as far as IE is concerned the contents of the page are not XML
(though they're marked as XHTML; not certain the whole thing is valid
but it's mostly generated by Javascript DOM methods). I tried getting
the innerHTML of the div and using DOMDocument.loadXML to create an XML
document, but even though the div was created by writing to innerHTML
with the results of an XSLT transform in the first place, it seems that
the string is no longer valid when read back out of innerHTML. In
particular (and what kills the parser), attributes are no longer
surrounded by double quotes - nice :-/ . I get the impression that the
MSXML suite is pretty sane and compliant, but any attempt to involve
IE-specific stuff is going to be painful.

So, does anyone know if this scheme is possible in IE? Does anyone know
of a more appropriate place to ask this (my (work) server doesn't seem
to carry MS groups)? And does anyone have a suggestion for a better way
of accomplishing the whole task - this is why I've included so much
background information on what I'm doing. Thanks for any help.

Pete

 

[Bjoern Hoehrmann]

* Pete Verdon wrote in comp.text.xml:

Summary: Can I do an XSLT transform, in the client, of a tree of nodes
taken from the displayed page DOM in IE? This works in Firefox.

Yes, if you use a XSLT implementation designed to do just that (e.g.,
one of the Javascript-based XSLT implementations that work in IE), or
if serialize the DOM into an XML document and load that into the MSXML
engine. Otherwise no.

 

[Pete Verdon]

* Pete Verdon wrote in comp.text.xml:

Yes, if you use a XSLT implementation designed to do just that (e.g.,
one of the Javascript-based XSLT implementations that work in IE), or

Thanks for the suggestion; I wasn't aware of such things. Do you have an
example? Also, how do they compare for speed - one of the ways my team
leader is justifying my time spent on this is faster table rendering
(since it's an easier thing for non-developers to understand than the
actually-more-important refactoring angle). The prototype rendering (as
opposed to editing) using MSXML is nice and speedy.

if serialize the DOM into an XML document and load that into the MSXML
engine.

This sounds a little like one of the approaches I tried, if one takes
reading innerHTML to be a form of serialising. Clearly you're referring
to a different way of serialising the IE DOM that I'm not aware of;
could you explain?

Thanks for the quick response.

Pete

 

[Martin Honnen]

Bjoern Hoehrmann wrote:

This sounds a little like one of the approaches I tried, if one takes
reading innerHTML to be a form of serialising. Clearly you're referring
to a different way of serialising the IE DOM that I'm not aware of;
could you explain?

innerHTML does not serialize according to XML rules but rather SGML
rules so you would have to write your own serialization code (e.g. with
JavaScript) that serializes the IE HTML DOM tree according to XML rules,
then you can feed that result to MSXML and an XML DOMDocument of MSXML.

 

[Pete Verdon]

innerHTML does not serialize according to XML rules but rather SGML
rules so you would have to write your own serialization code (e.g. with
JavaScript) that serializes the IE HTML DOM tree according to XML rules,
then you can feed that result to MSXML and an XML DOMDocument of MSXML.

I was afraid someone was going to say that. There's really no way to
treat XHTML (which by definition is XML) as XML?

Pete

 

[Martin Honnen]

I was afraid someone was going to say that. There's really no way to
treat XHTML (which by definition is XML) as XML?

IE can only render XHTML when treating it as text/html so in your case
the result of the XSLT transformation might be XHTML which is
well-formed XML but IE parses it as text/html with its HTML tag soup
parser and the DOM built is IE's HTML DOM and properties like outerHTML
or innerHTML in that DOM are following SGML rules and not XML rules.

The only XML properties in that DOM are
document.XMLDocument
and
document.XSLDocument
which point to the original XML input respectively the XSLT stylesheet
and are MSXML DOM documents.

 

[Pete Verdon]

Pete Verdon wrote:

IE can only render XHTML when treating it as text/html so in your
case the result of the XSLT transformation might be XHTML which is
well-formed XML but IE parses it as text/html with its HTML tag soup
parser and the DOM built is IE's HTML DOM

Well, that's me buggered then.

and properties like outerHTML or innerHTML in that DOM are following
SGML rules and not XML rules.

That I expected; trying to read from innerHTML was a bit of a hack that
I thought might just work, after the DOMish ways failed.

The only XML properties in that DOM are document.XMLDocument and
document.XSLDocument which point to the original XML input
respectively the XSLT stylesheet and are MSXML DOM documents.

OK, that's interesting in itself. Obviously it's not useful in this
situation, but it would have saved me keeping my own copy around for the
comparison on the save.

I guess my only options if I want to carry on with this route are
Bjoern's original suggestions - use a non-native XML/XSLT system or
write a Javascript HTML-DOM -> XML-string serialiser. Anyone got any
comments on those avenues?

Pete