Martin Honnen wrote:
> With IE the problem is that IE itself implements the HTML DOM and the
> XML DOM is implemented by MSXML and script simply uses MSXML as an
> ActiveX component, there is no importNode to move nodes from one DOM
> implementation to the other, and even if you use the proper XHTML
> namespace then in MSXML's XML DOM you simply have some Element nodes but
> not HTMLElement or HTMLOptionElement nodes. So with IE you would need to
> write some importNode yourself which traverses the XML DOM and creates
> the necessary HTML DOM nodes or you could consider to treat the input as
> a markup string which you assign the innerHTML of the select. But the
> latter does strange things here for me with IE 6 on Windows XP SP 2, it
> does not look like setting innerHTML on the select is a working approach
> to get any options to show up.
The problem is that IE implements rather strict databinding scheme.
With a normal XMLData/XMLTemplate scheme there is no problem:
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:template match="/">
<HTML>
<BODY>
...
<xsl:for-each select="portfolio/stock">
<SELECT NAME="Portfolio">
<OPTION><xsl:value-of select="name"/></OPTION>
</SELECT>
</xsl:for-each>
...
</xsl:template>
</xsl:stylesheet>
(Actually it already works in FF too)
And for all kind of tabular data (anyhow delimited fields' set) they
have full set databound elements populating automatically upon new data
arrival.
As many browsers do not stay even close to that, users need so far to
make an equivalend of a stomach surgery through the nostrils (to not
mention other place :-) Thus they load XML to a static HTML page and
then manually place each peace of info to the right spot.
If Co & Co hopes to win corporate customers this way, they are sorry
mistaken. :-(
Received on Tue Oct 18 02:57:51 2005