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

[Stefan Seefeld <seefeld@sympatico.ca>]

Justus-bulk@Piater.name wrote:
>
> 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?)
>   

OK, this would work. I see two main differences between our two proposals:

* Your layout element may nest (it may appear wherever block-level 
elements are expected).

  This is certainly more flexible than my proposal, I just didn't have 
the boldness to go this far. :-)

* 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.

Also, with that semantic simplification in mind, I like the name 'block' 
better than 'layout', as it better captures the elements intent. (You 
can apply a specific layout to it, as much as you can style it. That's 
capabilities typically associated with blocks in general.)
> - 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.
>   

For HTML, I think the mapping is trivial: blocks / layouts map to divs 
(the name attribute to 'class'), and for the foil's 'master' attribute 
gets mapped to 'class', too. Everything else is then up to the CSS 
author. Similarly for xsl-fo: As the new elements provide hooks to 
better control layout and style, but doesn't define specific semantics, 
it is up to docbook-xsl customization layers to provide XSL template 
specializations to produce the desired output.

> - 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:
>   

I agree. However, due to the desired flexibility there can't be any 
non-custom processing expectations associated with blocks / layouts 
(other than the generic mapping to 'divs' in case of HTML), so any such 
extensions have to be provided by users, and can't be incorporated into 
the stock docbook-xsl stylesheets.

Regards,
       Stefan

-- 

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