Lists Home |
Date Index |
Paul Prescod wrote:
> The real problem is that there is a
>person interested in the "style" of the output who doesn't want to
>XSLT. Fine. They already know CSS. That's fine too. But it doesn't
>that they never have to learn anything OUTSIDE of CSS.
Agreed, although I think the real problem is more succinctly that it is
more efficient if the person writing "styles" does not have to know too
much about xslt, a division of labor. They may in fact be interested in
the subject, great we teach them something, but here at least they have
to produce styles that work in very little time.
>In other words, you define the customization parameters that will be
>input to your stylesheet (you could also use XSLT
>params/variables/inclusions for the same thing). Then the person who is
>afraid of XSLT does not use XSLT.
Indeed and this is what I've done for my solution.
>Now there is a need for constant communciation between the XSLT
>developer and the end-user in order to set up elements that map to
Either that or the system is strong enough that you don't have to be
continually adding new elements to build style-tweaks.
> But this communication is necessary even if XSL-FO could work
>with CSS because only through communication could the XSLT creator know
>what class names to work into the output as CSS hooks.
Certainly at solution build, but from my experience after some time one
does not have to have this close communication for solution
maintainence, or for building new styles. At worst when a new document
type is added to the system one sends out documentation as to what this
styles pertain specifically to this document type.