Garry Howze wrote:
Thanks to Jon for the informative overview, and to Lee for the
csszengarden link. Both were very helpful. But I'm still puzzled
about a few things. Please bear with me. I'm just trying to
understand the Lenya approach.
Is it fair to say that xml/xsl/xslt/xsl-fo was conceived as a sort
of "grand solution" to the problem of separation of content, logic
and presentation, with xml for content, xsl for stylesheets, xslt
for transformations and xsl-fo for presentation? If so, it appears
to be a very good solution. XML is touted as probably the best
overall format for content, and is used extensively. XSLT would
transform that content to html/xhtml. That leaves XSL and XSL-FO.
So I'm left wondering why isn't xsl (eXtensionable Stylesheet
Language, it even has stylesheet language in its name!) used for
stylesheets instead of CSS? Then I read that browsers aren't able
to handle xsl-fo. Is that the crux of the problem?
Just a short hint:
XSL comprises
- XSLT (transform XML into something else, e.g. other XML)
- XSL-FO (page layout description language, comparable perhaps to
postscript)
XSLT has a much bigger scope than just presentation issues. It is not
a layout language, it's a processing (transformation) programming
language.
XSLT itself cannot express any layout information.
Why shouldn't XSLT be used for web-based presentation?
A key issue is the separation between semantics and presentation,
which should
even be available at the client side (browser), for instance for
accessibility
reasons. To the user agent, a clean, semantic form of the content
must exist
to allow custom presentation options (like screen readers - JAWS - ,
a print version, ...). Otherwise, all these presentation options
would have
to be provided by the server (CMS) and wouldn't be customizable and
extensible
on the client side.
In your XML-based application, you usually have other structures which
are based on your domain (medicine, mathematics, music, ...). These
structures
are necessary to hold all semantic information of your domain. But
on the
client side, we need a standardized structure which can be
understood by all
user agents (browsers). That's what XHTML is about - it's a
standardized
language to express sequential, structured content.
XSLT is the technology to transform your domain oriented content
into the
standardized XHTML content.
XSLT could also be used for different client-side presentation options
(like print views, multiple or single column layouts, ...), but this
has some drawbacks:
- not all browsers support client-side XSLT
- XSLT is much more complex than CSS (more flexibility is necessary)
- XSLT is much harder to learn
- another complex standardized presentation format would be required,
which would be the target format of the XSLT transformation
(at the moment this is HTML with style markup in most cases)
XSL-FO is the weapon of choice when printable pages are required.
It is extremely powerful, especially in combination with SVG you can
implement amazingly complex designs. It is much more flexible than
CSS for print views, but also much harder to learn and much more
verbose.
CSS is the weapon of choice for styling XML (e.g., XHTML) and SVG
for simple, flexible applications (like web pages).
See also http://www.xml.com/pub/a/2000/03/08/style/
That xml/xsl/xslt/xsl-fo is the optimal solution, but browsers just
aren't ready for it?
And CSS's are used instead because browsers do understand CSS?
No, CSS isn't outdated at all - quite the contrary :)
And finally, if tomorrow all major browsers were able to understand
xml/xsl/xslt/xsl-fo would there be a need for Cocoon,
Sure, there's much more about Cocoon than applying XSLTs to XML
documents.
It is a framework for building web applications.
and would Lenya (without Cocoon) become almost like a front-end for
xml/xsl/xslt/xsl-fo?
I don't think so, Lenya is a framework for building content management
solutions. A "front end for XML" I would call an editor (like BXE or
XMLSpy), which would communicate with Lenya to store content.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
