[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] slides: how to balance presentation and content
Stefan Seefeld <seefeld@sympatico.ca> wrote on Wed, 21 Jan 2009 13:43:37 -0500: > My expectation was that each slide models a given template, and a > flexible and minimal way to achieve that through markup was to > associate a template (by-name) with the foil, and then simply name the > blocks, such that the stylesheets (CSS, in my case) would attach > layout processing instructions to them. Yes. I like this, even though it covers only 90% of my needs. How about the following proposal, which builds on your ideas and accommodates both of our use cases: With respect to current docbook-slides, - Introduce a single new element called <layout> with (all optional) attributes "master" (in analogy to FO page-master, corresponding to a CSS class) "name" (corresponding to a CSS ID selector; is this really needed? Or use the XML "id" attribute instead of "name"?) and some layout attributes that are inspired by CSS property names. - Change the docbook-slides content model such that <layout> can be a child of <foil>. More generally, <layout> should probably be allowed in many other places where block-level elements are allowed. - Allow <layout> and existing block-level docbook elements as children of <layout>. (Or perhaps there is no need for nested <layout>s?) I think this is not very invasive, easy to understand, but extremely flexible: - The stock stylesheets might come with a default template for <layout> that does nothing in particular, and translates any layout attributes present into appropriate CSS, XSL-FO etc. One might also provide several default templates for commonly-used layouts (<layout master="twocol">), which would require reserving master names. - It would be easy to write custom XSLT templates (and associated CSS for XHTML output) for recurring layouts selected via the "master" attribute. Your custom XSLT template for two-column layout might expect exactly two children of the <layout> element, which the template puts into the left and right columns, e.g. by generating appropriate <div>s and CSS: <foil> <layout master="twocol"> <itemizedlist/> <layout> <mediaobject/> <mediaobject/> <layout> </layout> <layout master="footer"/> </foil> The same layout might be achieved more directly (and verbosely) in the following way, which for XHTML output would not require any custom XSLT (but would still require custom CSS) because the "left" and "right" could simply be passed through by the stock templates to the output XHTML as CSS class names: <foil> <layout master="left"> <itemizedlist/> </layout> <layout master="right"> <mediaobject/> <mediaobject/> </layout> <layout master="footer"/> </foil> - It would be easy to layout individual slides, without requiring any custom XSLT or CSS at all: <foil> <layout top="2ex" left="10%"> ... </layout> <layout bottom="10ex" right="10em" width="30%"> ... </layout> </foil> - Master and layout attributes might be combined, in which case the layout attributes would override the master style attributes, e.g. to achieve an asymmetric two-column layout. - Nested <layout>s would behave as nested HTML elements and cascaded styles do in CSS. Comments? Justus
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]