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

[Justus-bulk@Piater.name]

Stefan Seefeld <seefeld@sympatico.ca> wrote on Fri, 23 Jan 2009
12:33:35 -0500:

> Justus-bulk@Piater.name wrote:
>
>> Oh. Really? Like, change the title font, slide background color, slide
>> number position?
>
> No, but switch to a different layout. (Example: use a two-column
> layout in general, but switch to one-column layout for a particular
> slide containing a big graph. Etc.).

OK, so we're after the same objective, for which I don't see a need to
change anything at the <foil> level. All can be done with <block>s,
and quite intuitively, as I think my previous examples show.

OOo Impress and friends use "slide layouts", which correspond to <foil
layout="...">, but I've always found this concept inappropriate.
They're really just predefined arrangements of bulleted lists,
graphics etc. in various combinations, while I would find it much more
natural to simply insert such blocks individually, as I see fit.

With something like this:

  <foil>
    <block layout="left">
      <itemizedlist/>
    </block>
    <block layout="right">
      <mediaobject/>
    </block>
  </foil>

you get the best of both worlds: A <foil> is always a <foil>, with all
its default elements (title, navigation, footer, etc.). Its content is
arranged in <block>s that can be laid out and styled in predefined or
individual ways.

This is essentially your original example, but without the "template"
attribute of <foil>. Why would that be needed?

Moreover, limiting layout semantics to <block>s makes it easy to allow
nested <block>s one day.

> whenever I want to display two images next to each other, the only way
> to achieve this is by stuffing them into a table. Being able to wrap
> both into a two-column layout slide makes the use of tables obsolete.

Absolutely; this is what much of this thread has been about.

>> <block> is a good name after all... One might use a "layout" or
>> "style" attribute instead of "name" to make its function explicit.
>
> Yes, but such an attribute name would convey specific semantics, when
> all I want is identify the block so I can attach semantics (such as
> styling) externally (via CSS, for example).

To me, attribute names that convey specific semantics are highly
desirable. But besides the naming we're in full agreement here.

Justus