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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--