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

[Justus-bulk@Piater.name]

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.

Oh, here is one, from my previous message:

  <foil>
    <layout master="twocol">
      <itemizedlist/>
      <layout>
        <mediaobject/>
        <mediaobject/>
      <layout>
    </layout>
    <layout master="footer"/>
  </foil>

Perhaps not a very strong argument though.

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

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

Is it? To me, "block" seems overly general. "Layout" is very explicit
in that it says "I'm here for layout (and styling, etc.), not for
semantic structure like all of my peers". Or <style>, as this term is
used for all of this in CSS.  But I don't have a very strong opinion
here.

> ...

I fully agree with the rest.

Justus