Applying CSS to client-side transformed pages

[Simon Brooke]

I've been doing XSL transforms, converting XML to HTML, server side since
2000. In those days, clients which could do the transformation client
side didn't exist, so whether to transform client-side or server-side
wasn't an issue.

Recently I've been overhauling the code in order to pass transform to the
client wherever possible, and I've hit two problems

(i) How do I know whether the client can do transforms? Currently I'm
only passing the transform to the client if the client sends an
'Accepts' header which contains either 'application/xml' or
'text/xml'. However, Internet Explorer 6, which apparently can do
transforms client side, doesn't send either of these.

(ii) When the transforms transform XML to HTML which includes a link to a
CSS stylesheet, the visual appearance (in Firefox, anyway) which
results from a client-side transform is quite different from that
which results from a server-side transform, and it appears that the
CSS styling is being applied before the XSL transform is complete.
How can I ensure that the CSS is applied to the completed page?

--
si***@jasmine.o rg.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/

;; when in the shit, the wise man plants courgettes

[Martin Honnen]

Simon Brooke wrote:

(i) How do I know whether the client can do transforms? Currently I'm
only passing the transform to the client if the client sends an
'Accepts' header which contains either 'application/xml' or
'text/xml'. However, Internet Explorer 6, which apparently can do
transforms client side, doesn't send either of these.
I don't think the HTTP Accept header helps. In the end there is nothing
very reliably that you could do, sniffing the user agent to try to
identify the browser and compare against a list of XSLT capable browsers
you keep is one approach but for various reasons user agent strings are
changed to spoof certain browsers.

And if someone installs e.g. MSXML 3 with IE 5 or IE 5.5 then those
browser support client-side XSLT but their user agent string will not be
different from the original installation of IE 5 or 5.5 not supporting XSLT.

What you could try is to only rely on client-side XSLT run by script and
not run by <?xml-stylesheet?>, with client-side JavaScript you can
nicely check whether certain objects (e.g. XSLTProcessor) are exposed in
the current user agent.

But as IE/MSXML's API to run XSLT transformations is much different from
the API Mozilla provides writing script for both is tedious and
cumbersome (Mozilla allows you to transform to DOM nodes to be inserted
with W3C DOM methods, MSXML allows you to transform to string only to be
inserted with e.g. innerHTML IE's proprietary DOM).

Furthermore I think Safari supports client-side XSLT with
<?xml-stylesheet?> but so far does not expose an API to script to run
transformations .

As you are starting with a working solution doing XSLT on the server and
the way to client-side XSLT is difficult I would rather stay on the server.
(ii) When the transforms transform XML to HTML which includes a link to a
CSS stylesheet, the visual appearance (in Firefox, anyway) which
results from a client-side transform is quite different from that
which results from a server-side transform, and it appears that the
CSS styling is being applied before the XSL transform is complete.
How can I ensure that the CSS is applied to the completed page?

That sounds odd, do you have a simple test case where that fails? Of
couse it could be simply CSS differences depending on whether Firefox
renders in quirks mode or in standard compliants mode (where there are
differences whether the HTML html element or the body element are the
canvas). Thus if you have e.g.
body { background-color: green; }
doing
html, body { background-color: green; }
could help.

--

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

[Peter Flynn]

Simon Brooke wrote:

I've been doing XSL transforms, converting XML to HTML, server side since
2000. In those days, clients which could do the transformation client
side didn't exist, so whether to transform client-side or server-side
wasn't an issue.

Recently I've been overhauling the code in order to pass transform to the
client wherever possible, and I've hit two problems
Right. Client-side XML isn't worth it unless you can control the browser
version. For some unexplained reason, browser-makers simply haven't put
any effort into fixing client-side transformation yet.
(i) How do I know whether the client can do transforms? Currently I'm
only passing the transform to the client if the client sends an
'Accepts' header which contains either 'application/xml' or
'text/xml'. However, Internet Explorer 6, which apparently can do
transforms client side, doesn't send either of these.
See http://xml.silmaril.ie/users/browsers/
(ii) When the transforms transform XML to HTML which includes a link to a
CSS stylesheet, the visual appearance (in Firefox, anyway) which
results from a client-side transform is quite different from that
which results from a server-side transform, and it appears that the
CSS styling is being applied before the XSL transform is complete.
That sounds unlikely. XSLT transformation undergoes serialisation only
as the last stage (in the applications I have seen) so it ought to apply
CSS only once the output HTML hits the browser's parser. But I guess
it's possible that it works differently internally -- yet another reason
why client-side transformation simply isn't worth it yet.
How can I ensure that the CSS is applied to the completed page?

You can't. IE is hopelessly broken. Firefox is better, but still
incomplete. Opera is slightly better still, but all three do a number
of things differently, and some of them are just plain wrong.

///Peter
--
XML FAQ: http://xml.silmaril.ie/

[Andy Dingley]

Simon Brooke wrote:

I've been doing XSL transforms, converting XML to HTML, server side since
2000. In those days, clients which could do the transformation client
side didn't exist,
Well they certainly did exist, because I had production code doing this
throughout '99.
so whether to transform client-side or server-side wasn't an issue.
It was a horrible issue - very few clients supported it. Even for IE
you had to be careful just which version of MSXML was available. I had
client-side JScript that could tell, but I had to report this back to
the server with an explicit flag, there wasn't anything in the standard
HTTP headers.

I mainly did it by IP address, or by login credentials. I was doing
AJAX-like downloads of huge browse trees into user controls. Although
it was a useful feature, I just couldn't expect it to work outside our
intranet and some carefully installed IEs with the latest MSXML
deployed to them. The extranet users had to lump it with a server-side
version (fortunately they were just read-only query users, not data
entry).

I also disliked doing pure client-side transforms of the whole page.
Users saw a blank screen while the transform was going on, and if
anything failed they were left with nothing. I much preferred a "data
island" approach where they had a basic no-data page and a "loading... "
message, which then filled out a <div> with ther transform's result.
The "data island" could either by synch (with the <XML> tag) or asynch
(XmlHttpRequest ), because it was all IE-only code anyway.

Recently I've been overhauling the code in order to pass transform to the
client wherever possible, and I've hit two problems

I now do it by looking at the HTTP headers for some explicit request
that I add from client-side AJAX code. I (still) just don't bother with
client-side XSLT for "traditiona l" request-serve HTTP processing. If
you need this transform, then it's for some sophisticated asynchronous
"not quite so thin" client. Basic "do a GET and return HTML" processing
can stick with it server-side.

OK, so I'm not getting the reduced server load and bandwidth shrinkage
of a client-side transform. But servers are fast and pipes are fat
these days. I still get the extra functionality when I want it.

If I do use client-side from a simple GET, it's flagged in the session
state and I've already identified the capability by more sophisticated
means. The flag also goes into the URL, to support re-visiting future
bookmarks. These break if you exchange bookmarks between capable and
non-capable clients, but I have enough basic nav to allow recovery from
this that's only slightly ugly.