Re: [docbook-apps] slides: how to balance presentation and content

[Stefan Seefeld <seefeld@sympatico.ca>]

Justus-bulk@Piater.name wrote:
> Stefan Seefeld <seefeld@sympatico.ca> wrote on Thu, 22 Jan 2009
> 09:52:58 -0500:
>
>   
>> * Your layout element may nest (it may appear wherever block-level
>> elements are expected).
>>     
>
> Yes, but I'm not sure this is necessary. For simplicity, we should
> perhaps allow it only as a child of <foil>, without nesting, until
> somebody comes up with a well-motivated use case for nested <layout>s.
>   
Fine with me.


>> * Your layout element plays two roles at once:
>>
>>    - It provides a handle to specify layout (as my 'blocks'), by means
>> of the 'name' attribute.
>>    - It provides a handle to associate a template with it, by means of
>> the 'master' attribute.
>>
>>  I'm not sure whether mixing the two is really necessary. It might be
>> clearer to only have them use 'name', but add the optional 'master'
>> attribute to the top-level foil (or foilgroup) element.
>>     
>
> I also think we need only the one equivalent to CSS classes.
>
> I'm no longer sure "master" is a good name for this attribute because
> of its analogy to page masters, because I would not want them to be
> "slide" masters but rather "slide body" masters. I don't need to
> switch slide masters half-way through a presentation; do you?

Yes.

>  "name"
> is good I guess. <layout name="twocol"> is very suggestive.
>
> This is also why I would steer clear from making "master" an attribute
> of "foil"; this would require a user to customize the foil template,
> or to use obscure XPath to react to ../@master or even
> ancestor::foil/@master.  I think layout specifications belong inside
> the foil, not the a foil as such.
>   

So far I haven't done any XSLT customization in this context. But I did 
use CSS, where it's trivial:

.two-colum left { float: left;}

etc.  I don't think having to mess with the foil XSLT template directly 
is a good idea. But I don't find the above XPath syntax involving 
ancestor-based selectors obscure at all, so this doesn't really seem 
necessary either.

Regards,
       Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...