forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <>
Subject Re: [RT] Getting rid of the table-based layout
Date Wed, 13 Nov 2002 18:08:39 GMT
Jeff Turner wrote:

>If you "view source" on a CSS page like, you'll see
>there are lots of <div> and <span> tags whose sole purpose is to specify a
>type.  If that's all they do, why not replace them with XML with an associated
>stylesheet (CSS and/or XSLT) describing how to render the XML.  I'm pretty sure
>that IE 6 and Mozilla could handle an XML version of iguanacharlie today.
>Probably no-one cares if Forrest sends <faq> instead of <div id="faq"> when
>they render the same, but it can't hurt to send semantically rich stuff to
>users who want it.
I mostly agree.  While their are some complex operations that cannot be 
done client-side, having a rich semantic document sent instead of a 
somewhat semantic layout-driven document makes sense to me.  Adding the 
processing instruction is a very simple stylesheet in the pipeline and 
detection of XSLT-aware browsers isn't very hard as it's a very short list.

A warning about Mozilla's XSLT support though: it works fine for me 
except for some reason the generated document ignores CSS background 
colors for <body>.  Really annoying when that's your only impediment to 
sending XML to Mozilla.  Everything else seems to work fine.

>>I see XML/XSL as a server-side thing only.
>XSLT stylesheets, yes..
To me, it depends.  XSLT has different roles.  If what you are doing is 
transforming from one utility schema to another utility schema (DB query 
markup to DocBook for example), it has no other role than in server 
side.  If you have an XSLT file that transforms from DocBook to XHTML, 
what is it but a layout stylesheet?  It seems well suited to be sent to 
the browser if it supports it.

>>When you say "apply the stylesheet", i wonder "how" and
>>"to what".
><?xml-stylesheet href="site.css type="text/css"?>
>To the output of site2xml.xsl, a theoretical equivalent of site2xhtml.xsl.
This *can* work, but CSS styling is much less flexible than XSLT.  As 
long as everything is already in the correct structure, you don't need 
to generate a dynamic ToC (for example), items that you want to 
absolutely position on the page aren't constrained within another tag 
and vice versa, etc. you can style XML just with CSS.

>>To what does their browser apply the XSL? The xdocs/faq.xml
>>for example, is raw content. As we know, it undergoes
>>various server-side transformations before the browser sees
>>the final product.
>It would be an interesting experiment to see if client-side XSLT could be made
>to aggregate header, menu, tabs and content XML files.  Perhaps lots of
>document() functions.  If the browser caches files, then it could speed things
>up a bit, because header, tabs and menu are the same for all pages in the same
Are you sure you aren't thinking of XInclude?  It's possible that you 
could use the document() selector with XSLT, but then you have 
duplication of labor as you want to avoid that construct on server-side 
where performance issues become more pronounced in volume.  Two methods 
== (at least) two stylesheets that must be kept in sync.

>>So why would we want to let a browser loose on raw XML?
>Fun, conceptual neatness and lack of better things to do.
The more the client can do, the less the server has to do.  For the same 
reason that most clients can handle HTML so we don't need to pregenerate 
an image of each page for them to layout things correctly, more of the 
work that used to be concentrated on the server can be distributed out 
to the clients.  IE 6.x is a non-trivial number of browsers out there 
and its share will only grow as it takes away from 5.x.  Mozilla can 
take up some of this load as well but unfortunately it's a much smaller 
piece of the pie.

- Miles

View raw message