Hermann Stamm-Wilbrandt wrote:
>
> Eric,
> 
> > http://charger.bisonsystems.net/xmltest/problem.xht
> The link seems to work for FF and Opera on Linux as well as
> for FF, Safari, Opera, Chrome on Windows.
> 
> It does not work on IE6 or IE8 on Windows for me.
> (It asks "Do you want to open or save this file?
> Name:problem.xht ....)
> 

Thanks for the feedback.  At this time, my demo is XHTML 1.1 served as
application/xhtml+xml, so it isn't expected to work with IE.  Although
there is reason to believe that IE 9 will finally support this media
type, earlier versions will always ask to download the file.

I am working on an XHTML 1.0 variant, which will probably be served as
application/xml, to serve my XSLT code to IE < 9 browsers.  I intend to
employ content negotiation in production, to send client-side XSLT to
compatible browsers, as either an IE variant or a non-IE variant.

The server will perform the XSLT transformation and send the resulting
variant to incompatible browsers.  Ideally, using the same stylesheet.
(Well, almost -- there will be no DOCTYPE and the media type will be
text/html.  Although I may abandon DOCTYPE altogether.)  This is the
attraction to using XSLT to meet my goal of client-side inclusion,
instead of Javascript.

But I'm still in the proof-of-concept phase.  The next hurdle is IE.  I
already know that the XSLT output will need to be different, as my CSS
layout will break in IE 6 unless I add a wrapper <div> around some
floated elements.  IE 6 will also require more @id and @class markup,
plus a short CSS stylesheet to conditionally include, and some
Javascript to make the hover effects go, etc.

So as best as I can see in my crystal ball, my XSLT here is what I go
with...

http://charger.bisonsystems.net/xmltest/test.xht

...while keeping my fingers crossed that IE 9 will support it as-is.
This is the most efficient and standards-compliant method of serving my
application.

This approach requires IE < 9 browsers to be treated as the not-quite-
standards-compliant aberrations they are, complete with "conditional
comments" and other IE-specific code -- which gets hidden from other
clients through content negotiation.  My hope is, that using XSLT will
make the permanent burden imposed by supporting the still-shipping IE 6
much easier to manage over time.

IOW, I ought to be able to write some XSLT to transform my all-purpose
XSLT into IE-specific XSLT.  I'm figuring that sort of thing out as I
go along -- but I don't have the details worked out yet.  Perhaps my IE
< 9 XSLT code will be a separate stylesheet that's imported (or not)
by the all-purpose XSLT code, based on the XSLT processor string...

-Eric