[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSLT vs. CSS (Re: Indexing)

• To: Michael Day <mikeday@y...>
• Subject: Re: XSLT vs. CSS (Re: Indexing)
• From: Mitch Amiano <mamiano@n...>
• Date: Tue, 08 Jul 2003 09:03:36 -0400
• Cc: mitch.amiano@s..., docbook-apps@l..., xml-dev@l...
• In-reply-to: <Pine.LNX.4.44.0307082054410.16181-100000@l...>
• References: <Pine.LNX.4.44.0307082054410.16181-100000@l...>
• Reply-to: mamiano@n...
• User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

Michael Day wrote:

>>I would say that your conclusion mirrors the rationale for XSLT
>>
>>"This specification defines the syntax and semantics of XSLT, which is a
>>language for transforming XML documents into other XML documents."
>>    
>>
>
>Yes, that is why I believe that XSLT is best used for general
>transformation tasks, rather than for styling documents.
>
>Pipelining is an important addition to XSLT and will certainly be useful
>for some transformation tasks. However I believe that it will not make
>XSLT any more suitable as a styling language, as it will make the
>connection between the input and output documents even vaguer than it is
>at present. Customising complex styling transforms will still be very
>difficult without detailed study of the default templates.
>  
>

That complexity is a trade-off which many apparently feel is well worth it.
Complex styling transforms of the kind enabled by XSLT, aren't plausible 
in CSS AFAIK.

One should use the best tool for the job. Sometimes that does mean 
avoiding XSLT and conveniently attaching CSS styles. Other times it 
means going with a full-bore transformation. The diversity of glitches 
in implementations of both  XSLT and CSS mean that in the general case 
there is rarely a clear-cut path. Both are valuable components in the 
toolkit.

>>IMHO, the language isn't so much at fault. It is the presumption of a
>>limited run-time model. Or simply the lack of maturity in what really is
>>a family of complicated formatting processes.
>>    
>>
>
>Or perhaps an unfortunate choice of styling model. By choosing to
>transform the document structure tree into an entirely separate page
>layout tree, (rather than annotating the document with formatting
>properties as in CSS), the styling becomes harder to specify and to
>customise.
>
Well, it was a deliberate choice based on consideration of the needs of 
a more diverse audience than that served by CSS. Also, since we have CSS 
as a separate Rec, there isn't much point in duplicating it. The 
complexity is a trade-off, but one which is well worth it considering 
the large number of formatting problems which are mitigated through 
transformation.

OTOH, could there be a cascading transform? Would it be more or less 
difficult to understand?

Regards,

Mitch

>Best regards,
>
>Michael Day
>
>  
>

• Follow-Ups:
  • RE: XSLT vs. CSS (Re: Indexing)
    • From: Didier PH Martin <martind@n...>

• References:
  • Re: XSLT vs. CSS (Re: Indexing)
    • From: Michael Day <mikeday@y...>

• Prev by Date: Re: XSLT vs. CSS (Re: Indexing)
• Next by Date: Re: XSLT vs. CSS (Re: Indexing)
• Previous by thread: Re: XSLT vs. CSS (Re: Indexing)
• Next by thread: RE: XSLT vs. CSS (Re: Indexing)
• Index(es):
  • Date
  • Thread